Several months ago I published a letter to upper management about improving software processes. In that post I laid out what our team needed to do to be more effective at our jobs. Since that letter nearly five months ago, I have been promoted to management myself and now manage the team. While some might say I’ve gone to the dark side, I would vehemently disagree. The role certainly has changed me but I like my role because I still am a developer and know that high quality solutions do mean dollars in our pockets because we’re able to adjust/react more quickly.
I just got done reading an article over my lunch break and it caused me to shake my head in one key spot (emphasis mine):
It’s very difficult, if not impossible, to build and maintain a dynamic web site that works flawlessly every moment of every day for every customer. Between implementing new content, changing technology, managing internal stakeholders, and designing for customers who have different objectives, learning styles, and backgrounds, you could never produce a 100 percent error-free site. After all, to err is human.
Have we really set the bar that low with quality in software? I think we need to raise the bar. A few months ago I took a stand with my letter to management, here is a similar email I wrote to my team recently which works to combat the thought process and acceptance of poor quality so rampant in our industry:
As a developer I've worked on systems and rarely, if ever, have we set the bar so high as to have zero known bugs in the system. I think often this is looked at as "too lofty" or "impossible". Well, the development team here currently has one bug and is fast approaching zero. It IS possible.
In our department we often talk of "demonstrating competency and expertise". The flip-side of setting such high expectation is that we can shatter our reputation quickly with even a few small issues or bugs. Chris has said that developers are like airline pilots and that you only hear about them when something goes wrong. There's a lot of truth in that. You expect a pilot to get you somewhere safely - people expect our software to work.
I think we should not shy away from holding ourselves to an excessively high standard. Frankly, I'm more familiar with how to do it as a developer having years of building software to gain knowledge and experience from. I don't have all the answers on how do this from the other aspects but I don't think this means we stop trying. I think quality should be the first and highest goal. Speed should follow quality. If you're keeping a high quality standard and feel overwhelmed that the work is backing up behind you and you can't ensure the highest quality, please don't hesitate to talk to me about it and we'll see if priorities can be reworked.
As a team we're setting a positive direction for our department and its future. As we continue to refine our processes and expectations within each subgroup be aware of the lasting impact of the work we do. Be vigilant about improvements in the process we can make. If you see areas where you see quality slipping, pull the "red cord" and stop the process from going further until the quality is fixed. We want anything that leaves this department to be of the highest quality, whether a proofing round or a final product build. Don’t rely on other departments to back us up. If we operate in this manner we'll only build further credibility and reputation within the company.
What about you? What’s your stance towards bugs? Think zero defect is too lofty?
08-26-2009 1:04 PM