In no particular order, here are the four essential parts of a successful, modern software development strategy.
The first two are pretty much uncontroversial, but we’ll go over those first just to make sure that we’re talking about the same thing. The third one is an obvious but often unspoken truth, and the last is the culmination of a long-brewing idea that I think makes perfect sense once you see it.
Let’s take a look.
No matter how skilled you are at working with your users, inventing awesome new interfaces, coming up with great ideas, elegant designs and architecture and more – if you can’t reliably build and deploy the software you might as well not bother writing it at all.
Teams, executives, users. We all have to figure out a way to work together, and that can be hard as all these groups have different agendas, different requirements, different skill sets, different values, and different viewpoints.
So let’s start at the top. Regardless of the details of any disagreement on technology, schedule, staffing, etc., the first question to ask is some variation of, “what’s the point?”
In other words, what is the ultimate corporate vision we are trying to serve?
The only defense against constant change is constant learning.
And yes, it’s constant. Never ends. It’s not restricted to just new and emerging technologies, either. Change can come from everywhere:
The growth of Functional Programming languages and approaches at the moment is heartening; FP represents yet another fundamental way of thinking and reasoning about software design and construction. As with the shift from Procedural to Object-Oriented Programming Systems (OOPS), the shift from either of those to FP is pretty fundamental.
OOP sounded like a great idea at the time, and perhaps implemented purely it might have been, but as commonly adopted we did a very bad thing.
Mutable state, temporally coupled and diffused throughout the system, in a tangled, spaghetti bowl of mud. With OO meatballs.
Instead, FP can be thought of looking at a program as a series of transforms on data. Like a pipeline.
-> O -> O -> O -> O
Each step – each function – is stateless, with no hidden timebombs or surprises. In contrast, in many OO programs, each object is sitting out there with a a hidden grudge against the system, ready to pounce and wreak havoc when you least expect it.
WIth a series of transforms, like a pipeline, it becomes much easier to test and reason about what the software is doing, and more importantly, what’s up when something goes wrong. Its much easier to pinpoint the location of the problem and solve it.
But it’s not just testing, it’s about replaceability. It’s about disposable software.
When a component – a step of a pipeline, a function – is suddenly and unexpected made out of date, it should be easy to rip out and replace with something else. The pipeline approach lets you do that easily.
tracer bullet development, which we’ve suggested ever since TPP, fits in nicely to this idea.
Made the initial TBD a pipeline – stateless, immutable.
Graduate from their to immutable infrastructure.
Now you can replace anything that needs replacing easily, and onfidentally, backed up by some tests, with no time bombs or surprises.