The Boring Software Manifesto
I noticed that I didn’t have a copy of the Boring Software Manifesto on my own site, so here’s the original version from 2007 (yikes!) and a video version from 2013.
Several years ago, I coined the phrase The Boring Software Development Process, in response to a former employer where project management really didn’t think anything was happening unless we were trying to solve seven crises simultaneously.
The manifesto goes like this:
Boring software projects favor tacking exciting problems, and focusing our energy on the most interesting and valuable parts by avoiding wasting time on avoidable problems.
Boring software projects favor automated test suites over the excitement doing all your testing at the last minute and finding bugs after the project is “done”.
Boring software projects favor frequently integrating work from the whole team as opposed to the excitement of finding out whether you changes work well with the rest of the team after you have been working on them for six weeks.
Boring software projects favor always having a working, if incomplete, system over crossing our fingers and guessing whether the newest build would compile.
Boring software projects favor incremental design rather than spending six months crafting a UML document that is thrown out after one week of development. (I’m not exaggerating on this one, I reviewed a project that happened on)
Boring software projects favor understanding that requirements change over being “surprised” when late change requests come.
Boring software projects favor putting working, if incomplete, systems in customer hands early to get feedback as early in the cycle as possible rather than finding misunderstandings after the project is done.