The importance of throw away prototype

We often become attached to the codes we write. But sometimes, the best thing to do is to throw the work and start new with better insight, experience and idea of the problem.

Why this post?

I stumbled on this post during the weekend. After reading a few comments, I realised how accurate many of them were. The central argument was that reading codes is more difficult than writing codes. That's why many developers prefer rewriting old apps using more recent technologies. The other side argued that - there are plenty of rewrites because of the nature of software development. The first iterations should be considered as throw away prototypes because of the required learning phase.

When did I realise this?

By coding an internal project in my free time, I realised I started the project four times before working on a fifth version, which have also been subjected to change.

The reasons for that:

• I forgot the basics of SQL having worked so long with NoSQL, which is quite different from relational databases; I therefore started thinking differently - for example using arrays vs records when designing the schema
• my first database attempts were unnormalised, which is what I was used to with MongoDB
• I followed tutorials online blindly just to get a working prototype - therefore, most of the materials was irrelevant such as devise
• not until I coded well enough in the project, I understood how to group the data (I should maybe have selected MongoID instead of ActiveRecord)

What are the PROS with this approach?

The codebase remains concise with little to no unnecessary parts that are usually inserted when following tutorials or learning by experimentation.

Moreover, I don't start from complete scratch. I reuse plenty of existing codes from the throw away prototypes, for example the model schema and pieces of relevant codes.

Real Life obstacles

In the real life however many Project Managers, Product Owners or Customers have no idea of the importance of throw away prototypes. They want their products to be rapidly developed and deployed for use. No wonder software applications are riddled with bugs.

Taken from the mystical man month:

“Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.”

“In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three.”

“The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.”

“The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.”

“Hence plan to throw one away; you will, anyhow.”

Indeed, from my personal experience, most of projects I've worked on have actually been rewrites, from previous technologies such as VB6 and JAVA. Some of them became too bloated to continue add new features requested by existing customers.