Communications of the ACM

• Stakeholders identified
• Priorities understood and documented
• Effective development team
• Effective development tooling
• Effective end-to-end testing patterns
• High code quality
• Effective code deployment patterns
• High deployment velocity
• Effective operational tooling
• Happy users

It's a good list, right? So, do it. Seriously, just do that.

The hardest part of development is prioritization, and that is because humans are irrational and unpredictable. No development methodology will solve that. It's even more complex with multiple stakeholders, and especially multiple groups of stakeholders. The only way through is documenting needs with a forced-ranked priority and continually reminding people about what they are and what the corresponding statuses. Tools are helpful, but it's more about the communication and understanding around the tooling. The fanciest tool doesn't help if nobody believes what it's telling them.

Someone will inevitably cry, "but we need to be flexible!" And that's fine. It's ok to change priorities from time to time. But the relative priorities have to change too, and likewise the previous expectations that have been set. That is the hard part. No fair getting the previous expectations and the revised expectations; that's crazy talk. And again, that's a human problem. Don't forget that pulling the emergency brake on a software release train arbitrarily in the middle of a trip can land a development effort in a frozen, desolate location. Metaphorically speaking, of course.

Next, design software for the immediate prioritized use cases for the targeted timelines. There are a lot of important qualifiers in the prior sentence, such as "immediate", "prioritized", and "targeted timelines." Software designs always have context because software engineering is the art of tradeoffs. There are always tradeoffs. A tank isn't a sedan which isn't a racecar which isn't a truck, but they are all valid and effective forms of vehicles. We know from the classics such as Design Patterns (Gamma, et al.) and Refactoring (Fowler) that clean software design, configurability, and extensibility are important, but we also frequently forget that utilizing every single design pattern isn't the point. Guessing on use-cases — both functional and technical — almost always makes the outcome worse. Remember Knuth's famous quote: "premature optimization is the root of all evil." He figured that out a long time ago, and the software world has only gotten more complicated since then. Temptations and distractions are everywhere.

Pentagon Wars is an under-rated 1998 dramedy which depicted a fictionalized and satirized development of the Bradley Fighting Vehicle that was trying to be everything to everybody. This is loosely based on the very real and serious book Pentagon Wars by James Burton about weapons design and procurement. It's completely reasonable and expected to make design tradeoffs within what I would call "targeted use cases." Just be aware of when the tradeoffs become so big, they compromise the integrity and efficacy of said case. Engineering is both science and art, and no development methodology can solve that.

I was once at a company where somebody was a huge proponent of the Inversion Of Control pattern. This person was so in love with the pattern that the resulting code was difficult to understand and impossible to test. In fact, the unit tests were all configured to mock implementations to the point where nothing but fake code was being tested. This seems too ridiculous to be true, but it actually happened, and once the actual code was deployed to real customers, it was a disaster. I got pulled in to clean this up because each release required scads of emergency hotfixes. Don't become so enamored with a technical pattern or framework that it obscures one's vision from the real problems that were supposed to be addressed in the first place.

Then automate, automate, automate. Everything from the lowly build process, to unit tests, to environment setup, to deployment, to all forms of monitoring and metric collection. This is as obvious as the "the code should always work and be in a deployable state" mantra. Obvious, but not necessarily easy because it requires discipline to dedicate resources to automation — again, a human factor. The good news is that there have been many improvements and advances in frameworks and techniques in this area in the past few decades that can help. Pick up the Google SRE books for starters.

Figure out the most frequent release cycle that works with the user-base. This can vary by industry, and often technical aspects aren't the gating factor. Be able to release as quickly and easily as possible, with high quality.

Lastly, iterate. Keep going. Delivery velocity is life. The worst thing that can happen to any software product is a feast and famine cycle, and no development methodology can solve that. Maintaining momentum is arguably the hardest aspect, as continuous forward progress is utterly dependent on human factors such as portfolio priorities, resources, budgets, and other things such as how well your software is doing in the market. The difficulties of managing humans and money are as old as time. But it's not hopeless, just hard. So get on it.

I heard this at Strata Data Conference years ago: "if your software is successful, you are never done." Sage advice. Similarly, one can practically ensure a software solution not being successful with erratic delivery.

I've seen too many people effectively throw themselves in front of metaphorical trains for the love of a particular development methodology at the cost of overall project success. But a development methodology is just a "how" - it's not the goal. While no software success can ever be guaranteed, the best chances for development team happiness are to focus on common human factors such as stakeholder alignment, priorities, communication, and the discipline to keep driving forward. And the humility to accept that mistakes will inevitably be made and addressed in a future release, as soon as humanly possible.