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.

‍

Working with Mechanical Orchard

Phase 1

• Replacing vintage applications with digital twins–applications
• Exhibiting exactly the same behavior but built with automated tests
• With careful design
• With recent technologies

‍

Phase 2

• MO operating the newly developed applications
• Improving the overall design (merging old applications or separating out new ones, changing data stores, moving applications to new hosts)
• Adding features & fixing defects

‍

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.

‍

‍

Compounding Risk

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.)

‍

Why Not Both?

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.

‍