Software Development

Summary: Wartime Software to Win the War

The vast majority of software development is organized to deliver software that meets a set of requirements on time and on budget. In other words, it’s organized to meet expectations.

What if you don’t have the time or money to do this? What if you’re focused on a need unmet by existing software and you’re driven to create software to meet that need? This is wartime software – get it done or lose the war. It’s optimized for speed, with customer satisfaction and unfailing quality as a given.

In this summary, we’ll cover relevant blog posts and books.

No matter how you do it, there are things about the software development process that are common.

How do you measure success in software development? Agreeing on the measure of success is crucial to achieving it.

Why is so much software so bad? there are multiple reasons.

Peacetime Software Development

Peacetime software optimizes for predictability, i.e., delivering the requirements on time and budget. Wartime software optimizes for speed.

Being on time and budget means making an estimate, which experienced people know is nearly impossible.

Estimates are also hard because software productivity is hard to measure.

Whatever the productivity is, doubling the amount of work to be done using popular peace-time development techniques is sure to make it worse.

Peacetime development involves loads of activities that aren’t programming.

Project Management is supposed to assure that software development is “under control.” It’s actually a method to assure that programmers spend as little time as possible programming.

The vast majority of software development bears a striking resemblance to the meticulous planning and building of Frankenstein’s monster.

You get to near the end of a software project that has been “going well” and you suddenly discover the disaster.

With the usual measures, standard methods deliver terrible results.

The normal methods make common sense, like planning and making a Thanksgiving meal – and usually yield the classic mess you have after the meal.

Most peacetime software managers know they should act like they’re modern, criticizing old-fashioned waterfall and embracing Agile. Little change in results.

Classic software development efforts focus on process instead of the substance of the software itself.

Most important decisions about software aren’t made by programmers, which is a big factor in things going wrong.

Standard development embraces the metaphor of “building” software like a house, imagining that there’s a time when it’s done.

Another factor in building software is “just” having competent people who do their jobs.

Why do all the experts cling to the expectation-based approach to software? The history of scurvy is a close parallel to software development diseases.

A major issue with expectation-based software is incentives. Among other things, when you’re judged on expectations, you’re incented to make huge estimates of the amount of work.

You might think that because software is related to math that it’s precise. There are huge factors like the exponential growth of computer power that are ignored in Computer Science and peacetime development.

There are many paths people take to feel better about software development; they may sell well at the beginning but make things worse.

Wartime Software Development

The essence of wartime software development is that everything is optimized for speed of development.

Great software development resembles growing a baby.

Just like with growing a baby, wartime software can’t be allowed to die.

A good way to see the contrast between the mainstream way of software development and the method used by software ninjas is to compare building bridges in peacetime and war time.

When you focus on speed, there is a simple concept that explains how it’s better.

Is wartime software development like regular development only faster with fewer distractions? No. There are also essential differences in method and code standards.

If software is always being changed, you want to make change easy. It’s what the average lay person wants from software.

Here’s the idea of code without redundancies.

While the software world may not have caught on to the value of no redundancy, the ordinary world of machine design is all over it.

Here’s a broader exploration of focusing on redundancy.

Technical debt should mostly mean too much redundancy.

Technically, the way to eliminate redundancy is to move concepts from code to metadata.

More about how to make quickly-changeable code.

Code without redundancy is simple. It’s an ancient idea.

Here’s a summary of the method and techniques.

Here's an example of how one group evolved from trying to improve quality and availability to wartime software:

Of course, following good business and product strategies is an essential aspect of wartime software -- among other things, carefully selecting customer focus is key, Like conquering Europe in World War 2 by landing on a small number of beaches in Normandy instead of invading the whole coastline.

Wartime Software Book

Here is a brief introduction with links to my book on Wartime Software.