Throwaway Prototypes vs Evolutionary - Justifying their use to the business, and preventing their misuse

Question

I didn't find an exact answer to my question but this one is somewhat similar.

In my current project we don't know alot about the problem domain. This includes not only the problem we'd like to solve, but what tools and technologies are a good fit for solving it.

I proposed a 'throwaway prototype'. I was greeted with "You don't throw away code - its a waste of resources". Everyone seemed to agree on that.

However - from a project we completed last year - we used evolutionary prototyping, and the result was a total disaster. No-one could understand why we needed to go back and rewrite (read: refactor) sections of code that 'already worked'.

Indeed we have a long history of producing demos and then turning them into products in such a way that even 10 years later - the products contain code from the original demos. This is not a bad thing in and of itself - but it can be.

So - the question is. How do you explain to the business the pro's and con's of each approach - and what examples should you give?

As an aside - are there any alternatives that you have found that side-step this touchy subject when dealing with other individuals in the company.

Answer 1

Tell the suits it's evolutionary, and then throw the first one away anyway. No, I'm serious. In my experience suits do not seem to understand the difference between a protoype system and a production system (even though the exact same people have no trouble grasping this idea when it comes to hardware). This seems odd for a while...

...then you begin to see this as what it is. A deliberate attempt to game the system when faced with the high costs of software production. Middle management try to reduce costs by skipping decent quality production, and the easiest way to do this is by getting software departments to produce a protoype, which you then sell. Quality control people should catch this, but most of the time (in my experience), they can't be bothered. I suspect that a lot of the time they're in on the game.

Ultimately it's self-defeating, because either (a) softies insist on engineering prototypes to production level just in case some idiot in a suit tries to sell them, or (b) the company gets hit by the massive support costs associated with shipping half-finished prototype code.

Of course, if you try tactic (a) you get managers beating you down on the estimates because they don't look like prototype estimates any more. And you will get the blame for those extra support costs anyway, so the manager wins. As they nearly always do.

It's things like this that make me look forward to retirement...

Answer 2

You need to provide a business case for refactoring or rewriting code - justify how rewriting the code in question will make or save money. As programmers we all tend to be perfectionists, and often I find myself wanting to rewrite code old code simply because I see it as being messy. The business however want to weigh up the cost vs advantages of that rewrite and rightly so.

You need to approximate the cost of development (in man-hours) of the rewrite, and weigh that against the benefits - would customer(s) be willing to fork out extra money for the features and benefits provided? Would the rewrite significantly reduce maintenance costs?)

Answer 3

While sometimes throwing something away may be necessary, I personally have never had a need for this.

With refactoring and helped by modern tools, I find it is usually possible (and easier) to evolve the prototype to the final product. Of course this means that you need time for refactoring.

But no matter how you do it, this seems more a social than a technical problem. I believe it is important that decisions are made by the people who can best judge the situation. So marketing should make marketing decisions, and dev should make technical decisions (based on input from others of course). Obviously decisions can be questioned and discussed, but if you feel your technical decisions are being overridden without good reason, you have a much more fundamental problem you should address.

Answer 4

you might find this paper by Brian Foote and Joseph Yoder interesting

Answer 5

No-one could understand why we needed to go back and rewrite (read: refactor) sections of code that 'already worked'

If it works and if it's architecture does not prevent you from implementing the remainder of your requirements, then neither do I.

I've never worked anywhere where giving a list of features a prototype doesn't do and are required in a product doesn't work. Some of those features will require refactoring. The will also require other programming techniques, which will have a cost in time. There's nothing special about refactoring.

For technical systems, I also am in the habit of making small spikes rather than prototype systems, which only do one function and have no pretty UI. It's never ambiguous what they are.

Answer 6

I have been using and observing different flavours of prototyping techniques for over 15 years, both as a practitioner and a consultant, and I can't recall a single instance where so-called evolutionary prototyping was successful.

In my experience, most customers (and some developers) tend to believe that, since prototypes and the "real thing" are both made of the same stuff (namely, code), one can evolve into the other. This is simply not true. Well, it hasn't been true in my experience, at least. In other disciplines such as architecture, everybody can clearly see that the work and materials spent in building models is thrown away and then the real building is created. Something similar happens with medical appliances, civil engineering, etc. In software we seem unable to go that way.

I strongly suggest using throwaway prototypes. Call them models, visual sketches, mock-ups or whatever you like. But make sure that all the stakeholders understand that the prototypes will not evolve into useable stuff. Your initial question mentions that "everybody seemed to agree that throwing away code is waste of resources". Well, I disagree. That is a very short-sighted perception of reality. It may be true if you only measure immediate cost, but the cost/benefit ratio changes a lot if you take into account what you will gain (by throwing away some code) in the long run. I think your experience has given you glimpses of that too.

If you want a reference, Steve McConnell describes the two techniques extensively in "Rapid Development". It's a great book too.

Answer 7

I proposed a 'throwaway prototype'. I was greeted with "You don't throw away code - its a waste of resources". Everyone seemed to agree on that.

One answer to this is to ask someone how long it would take them to rewrite something they have recently completed. Compare this to how long it actually took them to create in the first place. If there was any uncertainty in what the end product was going to be the numbers will be different, the point is that some of the time spent on the prototype wasn't spent on code but on exploring the solutions to the problem at hand.

I strongly disagree with anyone telling you to hide what you're doing from management, possibly it could come to this but hopefully you can get better results taking on the admittedly hard task of convincing people to do what you know is right but which they don't yet understand. This is basically a management skill and is useful for anyone to develop.

Try to identify problems with previous projects which everyone understands or can be made to understand and everyone agrees that they are issues worth solving. Then, if you can identify a practice (prototyping, etc) which sounds like it could solve that problem for future projects you should be able to get some buy in. Possibly you can take on some small subset of your current ideas, possibly it's some completely unrelated practice which you'll decide would have helped. The important thing right now is probably to pick something you've got a high chance of success with, in future your previous success may mean people more freely go along with your ideas and you can introduce larger changes. Also, try talking to individuals before proposing this to the group, you can iron out issues in your proposal and get a few people on side before suggesting it to everyone.

If you can identify a way to prototype without writing code possibly you can get people over the idea that it's a waste of time. Writing a spec is almost a form of prototyping looked at like this. Again, find a problem which needs to be solved and suggest trying something which could solve it. One example I've seen recently is the user interface not being usable but it being too late in the project to fix it because we already spent (wasted) a load of developer time creating the GUI. One thing I may try to solve it is creating paper prototypes to walk users through the interactions and fix bugs in the user interface before anyone writes a line of code. Anyone not wanting to write code twice can hopefully get behind this.

I agree with @CesarGon that Steve McConnell's book Rapid Development is excellent and covers a tonne of development methodologies and their pros and cons. This might be useful to get some of your ideas straight in your own head, but I still think you'll need to explain your ideas in terms of benefits others can understand to get them across.

Good Luck.

Answer 8

Check out Agile Methodologies

I'm not saying you make your team follow this, but check out how agile projects work. It consists of a bit of design, possible prototype then testing and feedback. It's the best of both worlds.

I follow Extreme Programming. It has prototyping which is known as a spike solution.

I've found that such solutions are easier and better the second time you do something. This is not just programming related but anything. No matter how good your plans and design a retrospective or evaluation will always crop up with things like given more time I would have done this better and so on.

I'd advise prototyping but at the same time treat it just as the name suggests. A fake, or test solution to gain further understanding. It should be rough and ready, meaning you don't spend much time on it. Then you produce the actual product. If you follow this, you should be able to convince any nay sayers.

Answer 9

You can explain that without knowing the problem domain, you cannot make an informed decision on the technologies to use for the project, the architecture and the overall costs. If you build a trow-away prototype the team gets hands-on experience with solving some of the common problems that they may encounter. Also the prototype would likely be built pretty fast, doing the minimum required to get an idea about how the final product would look like, it's architecture will not be the most suited to the needs of the project and the costs would be pretty low.

Once you have a working prototype you and the client can work trough the feature list, changing, removing or adding features, because you cannot anticipate every need correctly on the first try. This way you save time and work in the long run.

Having first hand experience with the problem domain, the team can make better decisions about the technologies used, the project's architecture and even give a more accurate estimate about the time and cost of implementing the product.

In the end you waste a little time and money at first, but overall you save time and money by implementing a better, more maintainable architecture and the right features. Thus the client will be happier and feel that he is involved with the development process of his product (this is always a good thing).

That's how I would explain the whole thing to my boss, and I used similar approaches in the past.

Answer 10

Most important point all management needs to understand: Writing code is NOT building a bridge!

I am a qualified Project Management Professional within the Project management Institute, as well as being a coder, and I can assure you that there is a huge, prevalant, and FALSE assumption that the build phase of a software project is somehow similar to the build phase of a bridge, highway, skyscraper or other project.

If that were the case, then throwing away code would indeed be a waste.

Instead, I propose that software development is fundamentally more like a research project, or like the design phase of the PMBOK. All you are throwing away is some drafts of your blueprints, so that you can make neat, tidy and efficient blueprints. Code is blueprints that have been mabe with such excrutiating, intricate detail that the exact positiion, size and thread count of every nut, bolt and bolt hole is precicely specified to such an incredible degree that even the most literal and stupid device known ot man (the computer) can follow it. Then you press compile, and that, if anything, is the build phase.

Those are the fundamentals of my standard lecture to management. They are also the fundamentals of a pitch for proper Agile development, but that's another story. :-)

Answer 11

Prototypes should exist for very specific purposes, and not be a fully-functioning version of your application (or even a subset of the application). They should be written, generally, to answer specific questions about the feasibility of a given approach, and should be scoped to the minimum work necessary to determine that information. Since they are information-gathering tools, adding the 'proper' level of structure is almost certainly overkill, and will result in it taking longer to get the answer to the question you're answering with the prototype.

OTOH, if you have a version of the app running beyond asking such questions, it's a good idea to evolve that rather than just scrapping it. But in doing so, you'll need to make sure that you have strong boundaries/seams in code with well-defined interactions. Failure to have these will result in an unmaintainable mess. The best hint I can give for this is to avoid modeling your application as a set of state modifications to the greatest extent possible. For instance, instead of setting a value that some other code will use to determine what it should just do, just call the code directly and eliminate that piece of state in the middle.

I've found that, in general, modeling your application as commponents that communicate via passing data back and forth can greatly assist with maintainability over time, as well as giving you better abilities to define components and responsibilities.

Answer 12

For UI prototypes, in the right situation, mocking up a prototype which clearly does NOT function may help the business understand that the prototype is clearly throw-away. I have used Balsamiq (http://www.balsamiq.com/products/mockups) in the past - its simple to use, and has a free on-line version.

Answer 13

My team usually uses the evolutionary approach. What I have found works the best when trying to explain the creation process is to relate it to writing. Every person I have worked with is familiar with the writing process and the software creation process is quite similar. I describe the prototype phase as the rough draft. The refactoring and further development process are the editing process. By explaining the prototype as a rough draft I find it helps to communicate that further work will need to be done.

This approach has worked well for me when working with non technical customers.