« Naming Conventions | Main | Everything You Know is Wrong »

September 26, 2005

No, No; It's Worse Than That

Francis Porretto talks about the necessity of supporting software after the product is released, and the concomitant effects on the programmers caused by managers' failure to understand that necessity beforehand — or often afterwards. But it's actually worse than that. Consider the proper way to design and release software, the Holy Grail of the software engineering movement (in contrast to programming, which is an art):

  1. Gather business requirements.

    This is the process of getting the information from the people making money for the company, or doing the organization's business, as to what their problem is and what would constitute a suitable solution to that problem. These requirements are ideally listed in a set form including several methods of organization (requirement type, originator, urgency, and so forth), and should include a concrete use case (that is, a statement of what a user would be doing to cause the requirement to come about, and how the software should react in that case). This is how you understand the organization's — your customer's — goal.

  2. Develop technical requirements.

    This is the process of determining how to meet the customer's business requirements. Technical requirements are the things that must be done to create a system that fulfills the customer's business requirements. In particular, this requires that each technical requirement note which business requirements caused it to come into existence, and whether the technical requirement is necessary, sufficient or both to meet that requirement. Each technical requirement must include a test case, that is, a list of instructions of things to do in the completed program, and what result should be found from doing so. This is your strategy for meeting the customer's needs. These should be reviewed by the customer and signed off as valid prior to beginning any development.

  3. Develop a project plan.

    This is your plan for implementing your strategy in code or system (usually some mix) form. It should include a detailed list of tasks, each of which notes which tasks must be complete before that task can be begun and/or completed, whether those tasks are milestones (significant events to be reported to the customer, usually triggering further review and approvals processes), what resources (including money, people, hardware, building space and so forth) are necessary to begin and/or complete that task, and the anticipated duration of the task. The development of the plan is what allows you to set a budget and an estimated completion date, along with known or estimated error probabilities so that projects contingent on the completion of this project can plan for contingencies. All of your time estimates should be very conservative, or you will be blindsided by events (like when an employee wins the lottery and the project gets set back because you have to find a replacement, or if a backup fails at a critical time).

  4. Develop the product

    This is the process of executing tasks to complete the plan. This process is managed by a project manager, usually the same one who developed the plan, whose job includes doing whatever is necessary to complete the project on time and on budget with the committed resources. This also includes, in any reasonably complex project, numerous project reviews and sometimes in-line changes to the business requirements, and the associated adaptation of the strategy and plan.

  5. Testing the product to requirements.

    This is the process of putting the product through each test case of each technical requirement, and then through each use case of each business requirement, to ensure that the project's goals have been met. There are different types of testing, but all of them come down to verification that the project is complete and correct.


This is how projects should work. All too often, this is how projects actually work:
  • The IT director has a budget set in advance of the current year, usually based on a vague notion of what projects will need to be done. Many of the projects only have a name, with no actual description beyond that.
  • The IT director talks to someone in the business, or sometimes just gets a notion into his head, and kicks off an IT project in response. The initial email and perhaps a few follow-up meetings between the IT directory and an IT manager constitute the "business requirements".
  • The IT manager goes to the project manager and architect, and tells them what technology base to implement on, what final date (and frequently intermediate dates) to hit, and what resources they have to use.
  • The project manager and architect scramble to fit a project into that schedule that meets the requirements, such as they are, as best they can manage. This usually involves cutting functionality, misunderstandings, shortcuts, bad programming practices, failure to document and many other problems.
  • The software is delivered, generally on time or close to it, and the business once again wonders what the point of an IT department is, after all. Outsourcing decisions are often made at this point.

If you find yourself on an IT project where the deadlines and budget were made before the project was designed, the odds are that the project is going to be a failure — often an expensive failure — even if it delivers on time and on budget, because the odds of such a project meeting the business requirements, performance expectations and being maintainable and having many reusable components are vanishingly small at that point.

Oh, and another tip, embrace the use of open source software, people, for infrastructural bits of code like logging, database access and so on. For that matter, embrace open source applications where they are useful and have large enough user communities to ensure their future development. It will save a lot of time and money spent reimplementing things that are already solved problems.

Posted by jeff at September 26, 2005 11:57 PM

Trackback Pings

TrackBack URL for this entry:
http://www.caerdroia.org/MT/mt-tb.cgi/483

Comments

One of my favorite parts of Babylon 5 was watching Mr. Morden ask people "What do you want?" and get a true and complete answer. Morden would be great for gathering requirements.

Posted by: Karl Gallagher at September 27, 2005 9:13 AM

No kidding. And sometimes the whole "your head on a pike" thing applies to requirements gathering, too.

Posted by: Jeff Medcalf [TypeKey Profile Page] at September 27, 2005 9:36 AM

Jeff, that ain't the half of it. My observation has been that the business requirements for most projects are developed by someone who has never seen a customer if in fact there is a customer. In particular most vertical market applications begin life as a custom development for a specific customer in which the business requirements are developed by someone who knows little about customer requirements, the technical requirements are developed by someone who knows little about the development process, and the project plan is done by someone who's never done it before.

And, of course, there's a fundamental reality of IT development today: no project that takes longer than a Microsoft O/S development cycle is likely ever to be completed (unless it is not expected to work in a Microsoft environment).

Posted by: Dave Schuler [TypeKey Profile Page] at September 27, 2005 3:59 PM