I've written quite a bit about software quality over the years. In addition to quite a number of posts on this blog, I've written a short book about it. Currently, I just distribute it in PDF form to work-related people, but I'm thinking about releasing it on Kindle as an e-book.
Anyone involved in software who's, like, alive, gets real involved with software quality. Many years ago, I discovered it was useful to follow up meetings I had with software groups with an e-mail summarizing the ideas. As common themes emerged, I found myself with a small library of e-mails, cutting and pasting them. Then the collection turned into a document, since the ideas were so inter-related.
I started giving the document to groups before meeting with them. I got feedback during and after meetings, everything from mistakes I'd made to important issues I had ignored. So the document grew as it went through at least 15 revisions.
The document/paper/book is pretty long and comprehensive, and I haven't been discovering new things to add to it recently. So it must be "done." I've even taken the time to throw together a crappy-looking cover:
There are literally hundreds of books on software quality. There are tools. There are certifications. There's a huge body of work out there. Why did I put this book together? Does the world really need another book on software quality? What more can there possibly be to be said?
First of all, let's notice that in spite of all the books, methods, quality software and certifications, software quality still stinks. It stinks in big, process-laiden corporations. It stinks in cool young web start-ups. It stinks all over this land!
So what's the problem? Do people simply ignore best practice? Do they not understand it? Do they try to apply it but screw up?
The answer is pretty simple: mainstream software quality methods are no good. They cost a lot, take a lot of time, slow down development and modification, and don't improve quality much to speak of. What's more, most people in the industry who aren't completely asleep at the wheel know it -- which is the origin of the typical complaint of quality groups, that they're understaffed, underfunded, and never given enough time to do their job the "right" way. This complaint is generally justified! And it's likely to stay that way, because whenever those groups get what they want, cost and time goes up and quality stays roughly the same.
So that's why I wrote what I wrote -- I wrote what you couldn't read elsewhere, about ideas and methods that were ignored by the mainstream. Who knows why? I've stopping caring.
Validating the ideas
I'm only comfortable talking about stuff I know personally. The origin of the book was a large software project, comprising over 7 million lines of code. It processed credit card transactions. I was CTO, and Y2K was rapidly approaching. It was too late to do things the "right" way. We couldn't afford it anyway. Doing nothing was not an option.
So I dredged up some methods I had used in systems software testing that I realized no one knew about in applications. Because there was no other option, everyone rallied to this one. We got the job done and passed Y2K with flying colors.
Later, as I became more involved with Oak companies, I noticed that the short cycle times of web development forced small groups of desperate programmers to re-invent a subset of the ideas I was beginning to systematize. When things were really bad in companies not already using the methods, I could sometimes get them to try them, and the ones that really shifted to the new methods found success. By "success" here I mean simply that they got higher quality software with less time and effort and shorter cycle times, with less "tax" on development.
For a few years, I thought it was important to keep this magic bullet secret. Hah! Glaciers will melt before most software development groups try anything that challenges the way they've done them for years.
The Down Side
There's a down side to pretty much everything. Down side to publishing the book? Can't think of one. Down side to using the methods? Definitely. Here are two big, fat problems that emerge when using the new methods, quoting from the book:
With no big, formless, unproductive but “necessary” QA group, there is no place to put weird new hires in hopes that they’ll get bored and leave. There’s also no place to send people who are just too stupid or lazy or socially skilled to make it as programmers, but you don’t have the heart to fire them.
There are no big, fire-breathing, invective-filled meetings populated exclusively with overhead jobs (managers and marketing) who argue about “pulling things in” and “risks” and what happened last time and “competitive pressures” and elaborate project management charts in 4 point type that someone made up last night but everyone makes believe actually have a relation to reality other than “not.” Meetings like this raise everyone’s heart rate way more than hours in the gym and supply anecdotes providing amusement and smarmy edification for weeks. They would be missed.
Will I push the "publish" button? Probably. I'm thinking about it. Update: I've thought about it. The button has been pushed. The book is here.