Devise->Realise

Projects lacking proper functional requirements (or how I learned to be creative)

Rapid Prototyping
Requirement elicitation is a key component of the initial phase of project planning. However, there are times when your clients will be unable to give details information. This may means that they cannot yet envisioned the final product. How do you make them happy when they don't know what they want?

Rapid prototyping plays an important role in this situation. Your first step is to take the information you have, and to design the system as you see it. Do not get caught up on the minute details, focus on the overall behavior of the software. Your goal is not to achieve a fully functional application, it is to create the programs shell. After your client examines the product, you can continue the requirements discussion.

Some developer dismiss this technique due to it's potentially pitfalls. The most severe of these is a developer keeping a poorly designed component simply because it is now available. The key is to keep algorithms, and not designs. No matter what, you should go back to the drawing board once you've solidified the requirements. It is guaranteed that either your client will request a modification or that you will discover information unknown during the original planning.

3rd Party Libraries
To get a project off the ground in a reasonable timeframe, you often have to rely on software written by sources external to your company. Proprietary 3rd party software and open source implementations play a role in most large scale projects. There is no point in re-inventing the wheel when you can save time and money.

It is vital that this software is wrapped in an appropriate abstraction layer. None of its code should become part of your codebase. If they should cross paths, wasted weeks/months and a perpetual headache may ensue.

"But we can easily code it into this component, and that system, why bother with the abstraction layer?" What if the 3rd party developer decides to change their pricing plan? What if they drop support? What if they change their licensing for the next version? Any of these scenarios would require a change of libraries, either to another provider or a custom implementation.

With a proper level of abstraction, changing utilities/libraries can be achieved achievable in a relatively short timeframe (relative to cleansing an infected codebase). Open source software may seem immune to this type of problem, but you may one day discover a better alternative and decide on a switch. Remembers kids, BSD and Apache are your friend.