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.

https://www.blackliszt.com/2013/03/software-development-process-simple-terms.html

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

https://www.blackliszt.com/2013/03/software-postulate-the-measure-of-success.html

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

https://www.blackliszt.com/2011/06/why-computer-software-is-so-bad.html

https://www.blackliszt.com/2022/04/how-to-fix-software-development-and-security-a-brief-history.html

Peacetime Software Development

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

https://www.blackliszt.com/2010/10/software-project-management-dates-are-evil.html

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

https://www.blackliszt.com/2012/06/the-nightmare-of-software-estimation.html

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

https://www.blackliszt.com/2012/09/what-is-software-productivity.html

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

https://www.blackliszt.com/2012/09/software-productivity-divisors.html

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

https://www.blackliszt.com/2012/09/software-productivity-the-abp-factor.html

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.

https://www.blackliszt.com/2012/10/software-project-management-book.html

https://www.blackliszt.com/2012/10/the-disease-of-software-project-management.html

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

https://www.blackliszt.com/2012/04/the-dirty-secret-of-peace-time-software-development.html

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

https://www.blackliszt.com/2014/06/building-software-the-bad-old-way-and-the-good-new-way.html

With the usual measures, standard methods deliver terrible results.

https://www.blackliszt.com/2011/07/software-quality-theory-and-reality.html

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

https://www.blackliszt.com/2011/11/thanksgiving-meals-and-software-turkeys.html

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

https://www.blackliszt.com/2013/03/software-comparing-waterfall-and-agile.html

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

https://www.blackliszt.com/2013/03/process-and-substance-in-software-development.html

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

https://www.blackliszt.com/2014/01/who-makes-the-software-decisions.html

https://www.blackliszt.com/2014/10/joe-torre-and-software-development.html

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

https://www.blackliszt.com/2013/10/when-is-software-development-done.html

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

https://www.blackliszt.com/2014/04/delivering-software-is-a-nightmare.html

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.

https://www.blackliszt.com/2014/02/lessons-for-software-from-the-history-of-scurvy.html

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.

https://www.blackliszt.com/2015/04/software-problems-the-role-of-incentives.html

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.

https://www.blackliszt.com/2015/05/math-and-computer-science-vs-software-development.html

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

https://www.blackliszt.com/2015/06/software-problems.html

Wartime Software Development

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

https://www.blackliszt.com/2013/05/wartime-software-optimizing-for-speed.html

Great software development resembles growing a baby.

https://www.blackliszt.com/2011/06/software-how-to-move-quickly-while-not-breaking-anything.html

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

https://www.blackliszt.com/2012/04/field-tested-software.html

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.

https://www.blackliszt.com/2012/03/bridges-and-software-in-peace-and-war.html

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

https://www.blackliszt.com/2015/12/the-fundamentals-of-speed-optimized-software-development.html

https://www.blackliszt.com/2015/10/building-better-software-more-quickly.html

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

https://www.blackliszt.com/2020/02/how-to-build-applications-that-can-be-changed-quickly.html

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

https://www.blackliszt.com/2022/10/how-to-improve-software-productivity-and-quality-common-sense-approach.html

Here’s the idea of code without redundancies.

https://www.blackliszt.com/2020/06/the-map-for-building-optimal-software.html

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.

https://www.blackliszt.com/2020/05/lessons-for-better-software-from-washing-machine-design.html

Here’s a broader exploration of focusing on redundancy.

https://www.blackliszt.com/2014/03/how-to-evaluate-programming-languages.html

Technical debt should mostly mean too much redundancy.

https://www.blackliszt.com/2020/03/how-to-pay-down-technical-debt.html

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

https://www.blackliszt.com/2022/10/how-to-improve-software-productivity-and-quality-code-and-metadata.html

More about how to make quickly-changeable code.

https://www.blackliszt.com/2022/05/how-to-improve-software-productivity-and-quality-schema-enhancements.html

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

https://www.blackliszt.com/2020/03/william-occam-inventor-method-for-building-optimal-software.html

Here’s a summary of the method and techniques.

https://www.blackliszt.com/2022/09/better-software-and-happier-customers-with-post-hoc-design.html

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.

https://www.blackliszt.com/2023/07/summary-software-innovation.html

Wartime Software Book

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

https://www.blackliszt.com/2013/05/wartime-software-book-available.html

 


Categories