I love it when ideas spread out. I have been working on a book on software design for four years. One of the central ideas is separating investment in the behavior of the system–the features–from investment in the structure of the system–its design.
Investment flows every which way in this diagram. When you have an idea for a feature, sometimes you just implement it. However, maybe the current structure makes implementing it difficult, so your best bet is to first fix the structure. Sometimes when you finish a feature you realize it’s time to improve the structure. And so on.
The “spreading” I mentioned earlier came about because I first applied this diagram to what an individual programmer does many times a day. As I began working at Mechanical Orchard I realized that the same diagram describes our philosophy in the large as well.
The reasons not to mix are as un-intuitive as they are compelling.
The temptation is strong for a programmer to mix a few changes to the behavior with a few changes to the structure. After all, you’d rather just touch the code once, right? The same argument applies to Mechanical Orchard projects, and the reasons not to mix are as un-intuitive as they are compelling.
Contrast this with the Big Consulting style of modernizing applications–sweeping the table clean & reimplementing all the applications from scratch with new technologies, new behavior, new teams, new organization structure. Such projects sometimes work, but never smoothly, and often they fail spectacularly. However, the appeal of such a project structure is clear–we’re going to fix all our problems at once. When we’re done the whole thing is going to be shiny & new.
Why do “fix all the problems at once” projects have such a track record of ten and hundred million dollar craters? Compounding risk. The more problems you try to solve at once, the more things can (and will) go wrong. Chances are that eventually the risks are going to catch up with you. You can only dodge snake eyes so long.
The more problems you try to solve at once, the more things can (and will) go wrong.
For all its faults, your current system (people & computers together) works. Mechanical Orchard’s style preserves that one vital fact. The first phase keeps the system working, exactly as it does today, until we have replaced the foundation with material we can confidently change. With that foundation laid, we can decide together what to do next to create more value.
(Some day I’ll tell the story of social security numbers that were reported as 999-99-9999 in certain rare cases, the downstream programs that depended on this behavior, & how those downstream programs broke when the correct numbers began to be reported.)
Because if there are too many risks, too many cow pats in the field, you’re bound to step in one of them. Better to change one thing at a time & make certain progress with clean shoes.