This is an interesting perspective! A web application, or native application where you push updates, perhaps has more freedom to live in this kind of eternal now: version control (at least for the active deployment) is redundant because there is a single canonical version. I find that appealing in a similar way to some perspectives found in various “patching from scratch” discussions. In more fixed deployments where there are lots of versions in the field, like traditional desktop apps or, say, Eurorack module firmwares, or any software that makes calculations that must be reproducible across revisions, I find precise version information incredibly important, and version control is a very effective and convenient way of managing this.
I’m quite fond of continuous integration as a lightweight (sometimes…) process, and this is what’s pursued by lots of projects (incl. code for monome devices) on modern social-coding type sites, which typically make it relatively easy to set up. This is orthogonal to scrum but definitely in keeping with the goal to “deliver working software frequently”. The idea here is to do a basic automated screening to find changes that would/could cause a problem: does it compile? does the program run, or crash immediately? does it pass this set of automatic checks that smaller pieces of the code are producing the right output? did two people make different changes to the same line of code at once that will need to be resolved? It’s not perfect, and it’s no substitute for a human firing up the program and trying to use it, but it filters out plenty of little and big mistakes or oversights that are made by people with lots of different levels of experience. I have no idea how you would do this, and make use of its ability to tell you what’s wrong, without version control software, and this kind of tool in addition to the “safety net” of plain ol’ source control certainly lowers the amount of stress involved in my programming workflow(s).
Manual testing also benefits a lot from having a reliable change log, which many people are good at keeping by hand, and I am not without machine assistance. Distributed version control and the issue / discussion / PR / review and run CI type of simple process that is typical of Github projects suits my scatterbrain. Scrum doesn’t quite, in particular I kind of dread assigning story points or even delineating self-contained tasks sometimes: I want to write down the code that’s in my head, I may need to change some stuff along the way, this sprint I will commit to another sum $ fix ((0:) . scanl (+) 1) points of getting shit done; in this mindset I can definitely resonate with the freedom to identify and pursue what needs to happen. Some type of quick daily check-in makes a ton of sense to me though, 5-15 mins a day dedicated to getting on the same page with one’s team doesn’t strike me as onerous as some complaints I have heard about scrum would suggest. As an internal structure adopted by teams for breaking off actionable work, I think scrum is a pretty reasonable tool. It is nice to have a pattern to follow. As an implement of micromanagement, I am of course less of a fan.
3 Likes
