The Burger Development Paradigm...

A burger cook at a fast-food restaurant's job is to make burgers to both the restaurant's quality standard and the customer's request for the duration of his shift. If this cook is unavailable during the lunch-time rush or if this cook does not produce quality burgers, there is a problem.

Some managers of software projects operate under the same ideals. A programmer's job is to produce code to the company's quality standard and on budget. If a programmer is not programming, well, we have an issue. (This is one of the reasons that I prefer to use the word "Software Developer" (or "Software Engineer") to programmer, as intuitively, a programmer is one who codes; a developer does not only imply coding; in my opinion, it involves the code creation using software engineering techniques.)

If you note in the above description, the customer's request is not necessarily part of the vision. This is because, as Alan Cooper's The Inmates Are Running the Asylum discusses, software is produced by two things: a feature list and deadlines.

A feature list is a list of deliverables for a given version of software. A feature list should list those features that the customers need and would like to have, and these are generally created by either a software analyst or a developer. One common flaw in this is that the analyst or developer is not a domain expert, and therefore, the selected feature set could be based on the customers requests, but, as Alan Cooper points out, part of the feature list is things that the development team thinks would be "cool" to develop, which does not usually map a user need. The feature list (not yet analyzed in detail) is changed to be deliverable by a deadline.

We obviously need deadlines. What if when you hired a painter to paint your house that he was abstract as to when he would start and when he would complete; you generally need to know these things, so you can plan things like when you are moving into the house, when do you move the furniture around, and when can you invite people over.

If the painter said that it would be ready by the end of this week, and he realizes in the middle of the project that this job will certainly take longer than that because he underestimated the height of the building or you decided to change your colour choice, then there is a decision to be made. The painter could decide to get some help, extend the deadline, or work more hours (which could bring up the price); (s)he could rush the job by only putting a single coat of paint on some walls (which compromises the quality, both in terms of superiority and in terms of the desire of having your walls look good); or the painter could discuss this with you, letting you decide (which could be an uncomfortable situation).

The same is true for software. In the case of custom software, your customers need to know when the new product is coming it, possibly to coordinate when new hardware is coming, testing of the software, installation of the software, and training its employees to use the new software. Custom software is most closely related to the painter analogy above. The feature list is more or less fixed, so you either have to hire more developers, work overtime, or ask for an extension (price); the feature list could be compressed by providing skimpier features than originally planned (quality and desirability); or you could let the customer decide (uncomfortable).

In the case of either direct marketing or off-the-shelf software, there's many more people involved. Marketing needs to initiate some advertising, sales people need to sell their customers the new versions (providing them some time to plan their budget accordingly), store fronts need to plan shelf space and advertising, and this is only the start. Even with the most experienced developers, it still takes developers around six months to be productive at a new job and other developers need to help them come up to speed, taking them away from some of their responsibilities. This coupled with the cost factor will usually not make change the aspect of the project. Overtime is an option, although not good for long periods of time, where the project can turn into a Death March (Mentioned here also). An extension is generally not an option, as the organization probably requires the financial income and there are simply too many people involved to highlight this issue (has anyone not heard of Longhorn slipping, again?).

As aforementioned, the feature list is mostly created by developers, and only a portion of these are shared with key customers. The idea is to let your customers know what you are doing, but also give them some surprise features, increasing the punch when they install the software. As such, features can be dropped completely, unless some customers know about it, in which case the feature can either be skimped down or deal with the few customers that mention it one-on-one (the old "Oh, that's in the next version"). Either way, this can compromise quality; the feature list is generally developed with a theme, and removing features from this list will definitely effect the continuity of this theme. More critical, however, is choosing the right features to drop; the customer's needs must prevail over features that are "cool". This directly relates to the quality and desirability of the software. Leaving the customer decide is not an option, as there are simply too many customers, each with their own agendas.

In other words, developers are building software and the sales team is selling software that frequently does not meet the customers needs (think about the adoption rate of the new versions of Microsoft Office). This is a very real problem, but how do we fix it?

Larry Keeley has created a conceptual model of quality high-technology businesses (see Tetrahedral Model of Business for an extension of this model).

In the above discussion, I have focused primarily on the developers and sales organizations, and to rectify the problem, we simply need another group. Alan Cooper refers to this group as the Designers, and this group of people knowledgeable in the domain essentially goes out to current customers and potential customers to learn what the clients want (not need), which when the software is delivered, this process ensures that there is desirability, Larry Keeley's first characteristic, in the product. It is important to distinguish between what your customers need and what they want, because customers do not always know what software can do. A product that meets the customer's needs is simply just used, however, a product that has captured a user's desires has customer loyalty (think Apple and Mozilla).

It is nice to know what customers want, however, some desires are impossible to produce. Developers generally know what can and cannot be produced, and so Larry Keeley's second characteristic is the capability to produce the product.

Even if customers want it, it does not mean that people will buy it, or buy enough of it, and so Larry's third characteristic is viability of being able to sell the product.

These qualities will produce a product that can be developed, can make money, and that people actually want. This is a really simple concept.

When introducing this tripod, I started by discussing the designers. This is not a requirement of the model, but there are some advantages to this, especially when your customers will be telling the designers why your competition is not desirable. If the designers are not at the beginning, they may not have the ability to adapt the product in the current version.

Once that you have customer loyalty and maintain this loyalty with them, the time to market is not as important. When features are the primary focus, there is this faux sense that the company that brings out a feature X to market first will win big against its competitors. In turn, the next version of most of their competitors will likely have a similar feature. In the rush to be first to market, however, the stability and quality of the software is generally compromised; to me, it is more important to be slightly late and have a stable and quality product, than to be early and have a product that is not stable or of quality. But the main flaw with the feature/deadline-based development pattern is that the features are not necessarily needed, and therefore, users have no desire to have them. When your users have no desire for your product, when something better comes along, they will consider migrating to that product.

The three areas of the triangle are not required, but certainly having developer create features that do not solve user's issues is not the way to go. The businesses may appear to be successful, but to truly succeed, consistent effort is needed in these three directions.