Build Prototypes and Proofs of Concept Early

Leaving Hardest Part Till the End Might Result in a Puzzle Piece that Doesn’t FitIn any challenging software development project, there are always areas of special concern. These are generally areas that are new and unfamiliar to the team. It could be new AJAX techniques, a new Database backend, Web Services, Javascript, a new UI element, performance issues or a combination of all.But these areas of high risk are often treated just like any other part of the project for estimating and scheduling. Furthermore, the concerns then get shelved until a developer eventually gets to the assigned tasks.

That’s the worst time to fully realize that a planned feature is far more difficult than anybody had anticipated. Sometimes, it’s found that the feature in question isn’t even possible with the current skill set of the team or maybe it becomes obvious that it will affect five other areas of the project (which are now near completion, of course). This will usually cause major scheduling delays and can give the software a non-cohesive feel when it’s finally released.

To demonstrate the importance of the order in which things are done, lets assume you want to build a car. Your team will be building the entirety of the car, including the engine, dashboard, brakes, body, everything! Members of your team have previously built all parts of a car and there’s a ton of experience on board, so you feel confident that the new project will be a success. But, the engine is of particular concern because, except for a few small engines, nobody on the team has built anything even close to the 300HP motor you’re planning for this particular car.If that was your project where would you start? Would you start with the parts that your team are comfortable with or would you start with the engine?

I hope in this example it’s obvious that building a prototype and proof of concept of the engine is the highest priority. If the engine’s size is different than what is expected, it could drastically alter the dimensions of the car, the styling, cabin room, the weight of the car, possibly require different brakes, etc. If the engine runs hotter than you had expected, you might need a different kind of cooling system, larger air intakes causing a different body design or changes in cabin space and overall dimensions again. There’s a lot that depends on the characteristics of the engine. Starting with the engine is essential to the overall success of the project! Furthermore, it’s not possible to estimate the time frame of this project accurately until the proof of concept of the engine is complete.

Now, if your teams biggest strength is engines, you might start elsewhere, confident that your team could reconfigure the engine to conform to limitations imposed on it by other aspects of the project.In software though, most development teams don’t start with the hardest component of the project, which often has the most dependencies. Instead all parts are treated equally. Developers are asked to estimate the project requirements and they simply start development in the order that’s most convenient. Sometimes the order in which things are done is the order in which Microsoft Project’s resource leveling algorithm suggests to get the most bang for the buck. This can leave critical elements of the project for the final weeks or months. By then, the equivalent to the engine might be too big to fit into the body that was designed or it runs so hot that it will melt the surrounding equipment.

To make things work, the top notch quick-thinking team-members generally build additional work-arounds to “make things work” and have the least impact on the project schedule. The end result is software that, at best, is late and doesn’t feel right to end users.

The alternative method of development is to identify key, critical areas of the project that are areas of concern and build those components first. Build prototypes. Create proofs of concept. Test out the team’s theories before committing to a project schedule. If you are committing to a tight schedule for a collection of components that your team has never built before, you’re committing to failure. Don’t leave it to chance, if you want to ship your software on time.

  • Stew

    Hamid,

    I’m a prospective customer and I have a problem taking a company’s website seriously when it has misspellings on it. Overall I haven’t noticed many typos on your site, but I was surprised that the first word in this post has one (should be “Let’s”). We’re both in the software business, but I think our descriptive writing should be as precise as our code, where a comma in the wrong place separates right from wrong.

    Feel free to delete this comment.

    Best,

    Stew

  • http://www.jalen.com John Seguin

    Stew,

    Perhaps if typos were frequent, or in the main marketing areas, but this is a blog. It’s akin to a diary. One typo in a blog isn’t a reason for shame or doubt.

    - john.

  • http://www.iainmagee.co.uk Iain

    Stew,

    Get a grip! I can’t believe you felt this was important enough to comment on in the way you have.

    Hamid is adding a valuable contribution to the general discussion on how we develop software. Underachievement in terms of budget and schedule slip is a huge problem in our industry. I don’t agree with everything he says by any means, but this blog does provoke me to think again about how we do things – and stimulates discussion around an important issue.

    As John says, this is not marketing material, it’s not directly company related, it’s a blog! I would hate to think that people like Hamid will be discouraged from presenting their “raw thoughts” just in case it may have a negative impact on their business.

    Iain