How to move beyond requirements.

Software developers create code based on requirements, which usually are a subset of features. This is great for getting work done, but if we look at it in a broader sense, it can also be very limiting.

Consider this example:

A client has hired your company to write a new application for them. The application is really snazzy, and by simply running it, it will print "Hello World" for all to see. As a developer, it is your responsibility to code this application. What do you do?

I know, silly example, but you can replace the actual requirement for any that makes sense to you. Most developers at this point, would sit down and crank out an application that when run would write "Hello World" in perhaps a window or a command-prompt. For arguments sake, say it would take them half an hour.

As the developer is almost done, the client returns, now asking for a change. The application should write "Goodbye world" (The financial crisis hit them hard). Again, for arguments sake, the developer spends 15 minutes changing the application to write "Goodbye World".

Quickly upon delivery, the client returns again. He wants it shown in red. Again, the developer spends 15 minutes updating the application. After 10 minutes another change... The application should be able to print anything. Another 30 minutes of work.

After much back and forth, the developer and your company has spent 2 hours, and the client is finally happy.

Now, consider this: How long would it have taken to write the final application, had you know all these requirements up front? While this varies from product to product, it is safe to say it would have been a LOT faster had we known all the final requirements from the start. Maybe half the time.

It's time to put on our Software Architecture hat:

1. We didn't know all the requirements up front you may say?
   Yes, but we also never asked. As a software architect, it is your responsibility to ask, ask, ask until as much as you can is learned and uncovered. Understand you must, why the requirements are what they are.
2. Ah, but even if we asked, the client may not have known what they wanted you say?
   True, and often this is the case. However, that is not a reason not to think. That's right, I said think. With a minimum of effort, you can probably predict the next 75% of features a customer will ask for. Color the text, make it variable, etc.
3. No way, how can I possibly know what my client want next?
   Because you are smart. You know the system, you know the technical subject area, you know the market. Guess. Brainstorm. Talk to your colleagues. Get together and think !

I call this "Think Crazy, act sanely".

When you have to implement a requirement, think about what is next. How can you make it flexible, extensible, modular and configurable. How can you prepare the code to get additions later? How can you enable the software to be easily expandable?

Well, stay tuned, more on this in later postings...

Happy new year, and remember to think !