Read on Twitter
The game, in professional software development, is responding to and initiating change.
It& #39;s loopy: We change continuously because that& #39;s how we get harvestable value, and we use that value to sustain our ability to change continuously.
It& #39;s loopy: We change continuously because that& #39;s how we get harvestable value, and we use that value to sustain our ability to change continuously.
I want to make this case all up and down and around professional software development. It& #39;s what we want at the code level, the maker level, the team level, and the host level. But for the moment, I want to restrict myself to just the code and its maker.
My wife is the manly-man in our family. She does all the -- almost all of the *everything*. She& #39;s the one who works on the house, the cars, the yard, the farm, the tractor. I am, of course, a classic trophy husband, with my fabulous good looks and extraordinary helplessness.
Some 40-odd years ago, she was a single mom with 2 kids, a teacher in alternative hippie schools, and possessed of pretty much zero money. ("I started out with nothing, and I still have most of it!" h/t Tim)
But someone gave her a VW bug.
But someone gave her a VW bug.
And being broke and tired and possessed of a car that was in such a bad state it was *given* to her, she started her career as a car mechanic. She bought a book and she learned how to fix cars, or, at least one car.
Much of her omni-competence begins here, with Muir& #39;s "How to Keep Your Volkswagen Alive: A Manual of Step-by-Step Procedures for the Compleat Idiot" https://www.amazon.com/Keep-Volkswagen-Alive-Step-Step/dp/1566913101">https://www.amazon.com/Keep-Volk...
Not her, then our, only junker. We& #39;re not car-buying people. I& #39;ve spent many an hour standing helplessly by as she repaired the car we were supposed to be driving in. I am good with handing beer and tools and commiserating, so that tended to be my role.
We don& #39;t do it much anymore. Partly that& #39;s age, partly it& #39;s modest success, but another *huge* part of it is the difference between a 1970 VW bug and any car made in the last 20 years.
The differences are twofold. 1) the VW is a far simpler beast than my 2006 Honda Civic Hybrid. 2) the VW was made at a time and a place where solo amateurs with ordinary tools could and would do deep maintenance on their own cars.
Modern cars are extremely difficult for an amateur to work on, to *change*.
And the reason is straightforward: it& #39;s because they were not built to be changed in that old way.
And the reason is straightforward: it& #39;s because they were not built to be changed in that old way.
Modern cars are simply not intended to enable easy frequent reliable change.
They aren& #39;t made with that in mind.
They aren& #39;t made with that in mind.
This is not a knock: the modern car is vastly more capable and efficient and stable than that bug was. It achieves all of that in roughly the same form factor, too. Look under your hood, it& #39;s hard to find 100 cc& #39;s a free space anywhere in there.
Could you *build* a far more changeable car? Sure. But not in that form factor, no way. It has thousands more parts than the bug, hundreds more connections, and fitting it all in there is in and of itself a substantial feat of design and engineering.
Let& #39;s turn back to professional software development.
1) Changing software is far more central to the value of having a software company or department than changing the engine is central to the value of having a car.
2) Software has, at least by comparison with cars, almost *no* form factor constraints. You can& #39;t "spread out" a modern car& #39;s engine, but you can "spread out" software almost as much as you like.
3) The connections between software parts have, again comparatively, nothing like the constraints of the connections between engine parts. Nothing like the tolerances, nothing like the routing, nothing like the permeability.
4) With all that "space", we are capable of introducing any variety of monitoring or testing of the individual parts, too. With so little room under the hood, modern cars are under severe constraint about what and when they can sense.
5) "Pluggability", the idea of replacing one part with a completely different one, is also a far greater possibility in a program than it is in a car.
All of that adds up, for me, to this:
You can& #39;t build a modern car to enable change, but you can build software to enable it.
You can& #39;t build a modern car to enable change, but you can build software to enable it.
The reason a modern car can& #39;t be changed is because it wasn& #39;t *made* to be changeable.
And that& #39;s the reason modern software can& #39;t be changed, too.
And that& #39;s the reason modern software can& #39;t be changed, too.
So if change is so important to the trade, we need to optimize for it.
The optimizations require attitude, technique, and path.
The optimizations require attitude, technique, and path.
Attitude: It will change, and we don& #39;t fear that, we embrace it. Every line we write we write *on* *the* *assumption* that we will write it, again, soon.
Technique: Elements of the modern synthesis, working by story, TDD, merciless refactoring, CI and CD, obsessing over mental bandwidth usage, these are the techniques we have to learn to enable rapid and easy change.
Path: It does no good to describe the next "way" of making software if we can& #39;t also find a path that will take us there. Those elements of attitude and technique won& #39;t just "turn on" like a switch. They need to be inched towards.
I say that I frame all of my notions about professional software development around "ubiquitous ongoing change value-harvested continuously".
And from there, for each recommendation or advisory or just plain musing like this one, what I& #39;m thinking is how to get to attitude, technique, and path.
The game is responding to and initiating change, from bottom to top in our trade.
I want to raise our game.
I want to raise our game.
Thanks for reading this form-factor-less beast, it& #39;ll be a blogcast sometime soon, check http://geepawhill.org"> http://geepawhill.org for that.
Meanwhile, it& #39;s a sunny Monday, Va& #39;s off fixing fences, and I gotta record the *last* five blogcasts. Have fun, and I& #39;ll harangue y& #39;all more later!
Meanwhile, it& #39;s a sunny Monday, Va& #39;s off fixing fences, and I gotta record the *last* five blogcasts. Have fun, and I& #39;ll harangue y& #39;all more later!
