Signing Off on a Release

If I was ever a product manager, the one who was ultimately responsible for shipping the product, I'd have everyone on the team sign off on each release, stating that they're happy with the condition of the product and are okay with it being shipped.  It would be pretty simple, something like the following:

"I, _____________, approve of the level of quality, the functional and design decisions made, the amount of technical debt incurred, and the tradeoffs made for this release, version ________."

Everyone that worked on the product would be required to sign such a form – programmers, business analysts, testers, technical writers, managers, etc., etc. – and the product would not be released without everyone's signature.  So yes, the lowliest programmer could prevent a product from being shipped if he or she isn't happy with it.  And people couldn't be pressured or coerced into signing off, either. 

This may sound drastic, but if the entire team isn't proud (well, at least approving) of the product, then it is not acceptable to release.  If someone is hesitant to sign off, then he or she must really have some strong, valid concerns that should be heard.  Once heard, the concerns must then be addressed, or a compromise must be reached, or the hesitant person must be convinced of the value of a business or design decision.  But in the end, the product only ships if everybody says it’s okay to do so – because if a product isn't good enough for the people who made it, how could it possibly be good enough for anyone else? 

My hope is that something like this would:

• increase the level of quality in the product;
• strengthen each team member's sense of pride and ownership in the product;
• ensure everyone's opinions are heard and sincerely considered; and
• address any major problem in a timely manner, so that customers wouldn't experience the problem and the team wouldn't be saddled with significant outstanding issues at the onset of a future release.

But what do you think?  Is signing off on a release useful or just plain silly?

Why Bother With Quality?

I take pride in the quality of work I put forward, and I'm greatly concerned about the overall quality of the product I help to create.  Most of my past and current coworkers also share this same concern.  However, some developers don't.  And though management claims quality is important, they'll quickly disregard it if it impairs deadlines or budgets.  The same goes for customers; though they'll complain about a lack of quality, they don't want to have to wait longer or pay more for it.

So aside from pure professionalism, why should I bother with striving for a high level of quality if other developers, management, and customers aren't as concerned about it?  Am I being too much of a perfectionist or being naive about the realities of getting a product out the door?  Is a lower level of quality routinely acceptable?

From time-to-time I ask myself these questions, and my gut keeps telling me that the highest levels of quality are indeed essential.  However, when budget and deadline pressures start to mount, I haven't been that great at providing compelling reasons for tolerating only the highest quality.  "Close-enough" quality usually wins out.

Then I found the following comments by DeMarco and Lister on pages 151-152 of their book Peopleware: Productive Projects and Teams (emphasis mine):

"The judgment that a still imperfect product is 'close enough' is the death knell for a jelling team.  There can be no impetus to bind together with your cohorts for the joint satisfaction gained from delivering mediocre work.  The opposite attitude, of 'only perfect is close-enough for us,' gives the team a real chance.  This cult of quality is the strongest catalyst for team formation.

It binds the team together because it sets them apart from the rest of the world.  The rest of the world, remember, doesn't give a hoot for quality.  Oh, it talks a good game, but if quality costs a nickel extra, you quickly see the true colors of those who would have to shell out the nickel.

... Your market, your product consumers, your clients, and your upper management are never going to make the case for high quality.  Extraordinary quality doesn't make good short-term economic success.  When team members develop a cult of quality, they always turn out something that's better than what their market is asking for.  They can do this, but only when protected from short-term economics.  In the long run, this always pays off.  People get high on quality and out-do themselves to protect it."

So developing a cult of quality results in a close-knit, successful team that creates products that exceed customer and market expectations.  To me, this is a very compelling reason for adopting high standards of quality.  The above passage doesn't give a concrete example, so it still requires a leap of faith from a manager.  But identifying the cult of quality as an essential component to a successful team seems like a good argument to use when advocating for more quality, as opposed to simply arguing for more quality for quality's sake.  I'll definitely keep it in mind during my ongoing battles for more quality.

Some Handy Apps for a Windows Machine

Here’s a few applications I put on a Windows machine that I'll be using for development.  This list isn't complete; it's just some things that you might not be aware of:

• Sysinternals - An awesome collection of system utilities.  I download the whole suite, though I particularly like the Process Explorer.
• WinDirStat - A disk usage visualizer.  I have a knack for filling up hard drives, so this tool helps me target my disk-cleaning efforts.
• EyeDefender - An application that reminds me to take a break from looking at my monitor.  You might think this app sounds silly, but there's times when I really get into something, staring intently at the monitor and only later realizing that a few hours have passed and I now have slightly blurry vision.
• Notepad2 - A lightweight text editor for when you don't want to open an IDE, and a great replacement to Windows’s Notepad.
• Mouse gestures for browsers – I really don’t use that many gestures, mostly just ones for navigating within a page and from page-to-page.  Nonetheless, they’re a requirement for any browser I’ll be using.  I use FireGestures for Firefox and IE7Pro for Internet Explorer
• An application launcher - A definite must-have for quickly opening applications, navigating to often-used directories, opening web pages, executing command line arguments, etc., etc.  SlickRun isn't the fanciest or most feature-rich launcher, but it does most of the things I need to do.  I also like its integrated Jot application for recording quick notes.
• Consolas Font Pack - Amy turned me on to this font, and I find it easier on my eyes than other fonts.  I use it in all of my editors (not just Visual Studio).
• CLCL - I can not say enough about this little clipboard caching application.  I mean, who couldn't benefit from a universal clipboard that stores multiple things and is easy to use?  It has undoubtedly boosted my productivity.  Highly recommended.

Defining Success for Applications That Aren't Sold

Jim has a good post stressing that developers need to know how well the products they made are selling, so that their goals and interests are aligned with the company's ultimate goal of making money.  This is a good point that, in my experience, often goes overlooked or is underemphasized by a software team.  Things like quality and release dates are closely monitored and used as indicators of success, but whether the product is actually profitable isn't tracked as rigorously by the team.  (It is, of course, monitored closely by other areas of the company).

However, a question popped in my head when reading the article: what about when you're working on an application that merely serves a support role within the company? The application itself isn't sold; it's just an in-house tool used to improve existing business processes.  So how do you define success for these applications?

Since you can't really directly translate these types of applications into actual dollars, you need to find other metrics to use for objectively determining the application's value to the company.  Devising these metrics, however, is where I start to struggle.  You need something that shows that a task or process was really difficult or time-consuming, and the application made it easier or faster.  Or something was really expensive to do, and the application somehow made it less costly.  But it's not enough just to say the application is easier, safer, faster, or cheaper; you need to be able to state that it's x percent easier or y dollars cheaper in order to gather some objective insight into the application's success.

Yet people aren't always translating these time-consuming, laborious, and/or risky tasks into metrics, let alone actual dollars.  They just know that they have a situation that could be better solved by software.  Then software is implemented to address these problems, but you're not sure how successful the software was at solving the problems because there was nothing concrete to measure it against.  When talking to Jim about this, he mentioned that with in-house applications, you're often closer to the clients, thus allowing you to gather information like customer satisfaction scores that can be used to gauge success.  I think this information is useful, but as Phil Haack recently opined, customer satisfaction can be tricky to measure.  Plus I still want to see how the application objectively, concretely contributes value to the company - and particularly to the bottom line.

As of now, I can think of a few things to help measure the success of applications that aren't sold: hours saved, money saved, increased accuracy, decreased risk, and improved access to information.  But I'm not sure how to measure these things or how well they translate to the bottom line, so let me know your opinions on measuring the success of these types of applications.