… I am convinced that the quality of the product can never be established afterwards. Whether the correctness of a piece of software can be guaranteed or not depends greatly on the structure of the thing made. This means that the ability to convince users, or yourself, that the product is good, is closely intertwined with the design process itself.
Edsger Dijkstra
We don’t get quality by having a week, or even a two or four week, “quality sprint” at the end. We don’t get quality by just talking about quality. We don’t get quality by putting up motivational posters (although we did get a lot of laughs out of the wonderfully cynical graffiti that was added within 24 hours of their appearance).
We get quality by wanting it and engineering for it and caring about it at every stage in the process. We get quality by being prepared to admit that we’re doing something (or everything) wrong and finding a way to do it better. Quality software is bloody difficult to obtain even when we care about it deeply, follow all the industry best practices and invent a few best practices of our own. Quality software is impossible to obtain if we’re not doing everything we possibly can.
Dijkstra talks about the “ability to convince users, or yourself, that the product is good”. One of my first questions to a team is “does your software work”? The vast majority of teams will answer “yes”. Some of them might admit to a qualified “yes”. The next question is “how do you know your software works”? The answer to that question should be wide and deep. It should encompass testing of many flavours – unit, automated, user, white box, black box, integration, system. It should encompass development practices, communication structures, requirements gathering, change management and the attitude of everyone on the team.
The best team I was ever on had a white box QE who looked at every decision with a testing and quality mindset. Whenever we came up with a design for a component he asked how it was going to be tested, how we would know whether it worked or not (the definition of “works” can be surprisingly subtle) and what additional integration tests would be necessary because that component interacted with other components. There were times where that QE was the least popular person in the room. These were also the times when it was incredibly important to keep him in the room and make sure we were all listening to him. That in turn demanded a certain attitude from the rest of us.
For lack of better words: “hear, hear!”
Marjan has a great post about quality on her blog here.
The whole post is worth reading, but I particularly liked these two sentences:
(off topic)
I started reading this when Eric Lippert linked here, and I love the content, but I can’t find any reference to who you (the blog writer) are. What’s your name?
Hi Alex,
I keep meaning to put up an “about me” page, but have failed to turn “meaning to” into “actually doing”. My name is Bob Archer, I live in Seattle. I am currently between jobs, but was fortunate enough to work with Eric for a year, and he was generous enough to advertise my blog. For some reason, C++ “clicked” with me as a language. To paraphrase Winston Churchill – C++ is the worst language there is apart from all the others.
Much of my career has been spent developing reasonably large (millions of lines of code), cross platform, high performance software. C++ is still the only game in town for this use case (unless someone knows better. I know there’s Rust and Go and D and some other interesting things out there, but I haven’t seen anything that is mature and genuinely cross platform).
Having said that C++ “clicked” with me, it still has many flaws. Recently I have been exploring the many different ways to use algorithms to achieve a desired goal. Many of the posts on this blog are my write ups of the discovery process I have gone through. I am fascinated about the work that it takes to develop high quality software, and I hope that in 20 years time we’ll be looking back on this era and laughing (or crying) at the terrible things we did. Although we don’t know everything about developing high quality software, we do have some current best practices that are vastly better than nothing. This blog post was written as a rant (polite as rants go, but still a rant) about teams that willfully ignore these best practices – and sadly there are still plenty of teams and individuals who ignore them, or in some cases don’t know that the practices even exist.
This is in danger of turning into another rant. I’ll just say that I do computer support for my father, my sister and a few friends. They are all smart people and are regularly baffled by their computers. As an industry we need to get our act together on all levels. My interest tends towards a low-ish level, not usually in assembler but definitely C and C++ style bit twiddling. I want to see an industry where we are working hard for quality at every level.
I have some thoroughly out of date, 1995-style web pages here:
http://www.bobarcher.org
At some point I’ll write a blog post about the include guard optimization because it still comes up from time to time. Spoiler alert – your compile speed is probably not being significantly affected by the include guards.
Thank you for asking, and I apologise for not getting an “about me” page up. I’ll cut and paste some of this comment when I have worked out the requisite WordPress magic.
Thanks for such a detailed reply! I love the quotes of the week, especially the detailed commentary that you provide. Thanks for blogging, and for sharing part of your story.
Mentor Graphics top management said that we would all use Continuous Improvement (a different phrase, “ceaseless improvement” or something, was rejected because it sounded like commitment). But there was no discussion of this at the worker level, and no activity I could see that resembled it. The only time I heard the word “quality” was when the manager wanted to accuse somebody of not having it.
Except, of course, we had Quality Assurance teams who ran regression tests.