I have written in the past about using previous versions of a project as the requirements for a new and better product as being an exercise in futility. Without requirements, you don’t know where your are or when you are done.
Today I want to talk about another process that is somewhat similar. That is where you have inadequate requirements for a product and are not willing to accept the cost for additional time needed to produce a final product. Here is an example.
In want you to build a widget. It will have a XAML implementation front end to make it run. Here is the data domain, so go ahead and start working on the application. You know quite a bit about what the application is supposed to do, so get started with this project.
You start with first building a model of the data domain. You send a copy of it for validation and are confirmed to continue. You begin building the XAML screens to maintain the data to find out that the intention was to use a command line to execute everything. There was no need for XAML and you wasted a week putting that together.
You get the picture. The whole project suffers from a lack of requirements and input from the project owner. You’re pulling requirements out of the air, and when you don’t anticipate what the other person has in mind it causes friction.
The moral of the story is, working without requirements isn’t fun or efficient for anyone. You may not have the option to not do it. However, if you are in that situation, work very hard to become the owner of the requirements.
Cheers,
Ben