Rapid prototyping can be a wonderful thing for involving the end customer in the design and development process; it can make them happy (it shows progress) which makes you money; however, if you have the wrong kind of customer, your life as a developer can becoming a living nightmare. The horror is increased by several orders of magnitude if you have the requirement to produce fully functional prototypes.
What Is Rapid Prototyping?
It’s a software development process that involves creating incomplete prototypes of an application that either helps build or build toward the ideal of the final design of the application.
There are several different methods of rapid prototyping as listed on the Wikipedia article:
- Throwaway – none of the actual code developed will be used in the final product (FAST)
- Evolutionary – iterative design and development of functional prototypes (and the code used isn’t thrown away)
- Incremental – piecemeal construction of a larger prototype using smaller prototypes
- Extreme – like everything else but has a period where mock-data is used
Advantages of Rapid Prototyping (via Wikipedia article)
- Lowered development time and costs
- Less process to get in the way of defining; the customer can see requested changes fast
- Increased customer involvement in design and development
- User’s can give immediate and incremental feedback on the prototypes so they end up with a much happier, better functioning product
Why Is It So Bad Then?
If you have a customer that would like something, but they don’t know what they want, and they tend to get stuck on telling you how to implement their something instead of real concrete requirements. RUN!!!
Let’s just take a quick look at the disadvantages…
Disadvantages of Rapid Prototyping (via Wikipedia article)
- Poor/insufficient analysis
- Since you were busy coding your life away on a feature that’s not really “production-ready” and you only have a week or two to finish, you might not have had enough time to sit back and really think about your design. You could make some dumb mistakes that could have been fixed by thinking about the problem from a different angle or using more time.Now imagine every other developer working on the same project but on different parts! You may have a functional prototype, but it may well easily be a big ball of hack
- Customers don’t tend realize that the prototype is a “prototype“
- This one can be really bad. If you give a customer a prototype release with the GUI features working but the data is not really connected to the real data (so that you could ask them if this new GUI feature was what they wanted), they will always try to use it as a final product and ask instead, “where’s my data?“
- Rapid prototyping tends to allow the customer to foucs more on the minute volatile details rather than the larger picture or the workflows.
- Another problem, once the customer sees a feature, they tend to stick with that feature even though it may evolve. They have been trying to imagine the solution to their problem, and you give them a half-arse solution; the next release you give them something better or it changes and they will want to stick with the old and poorer features (i.e. once you’ve laid the track around the mountain, they won’t like it if you decide to tunnel the track through the mountain even though it might have been shorter/cheaper/better/whatever)
- Clouding of the developer’s goals and mission as compared to the customer
- The customers will ask for features sometimes, and everyone thought they knew what the customer meant by those features/requirements; however, what they wanted and what was interpreted can become skewed and misaligned. To help you out, make sure to ask them for the business case for everything they are requiring! Ask, ask ask! They need to know why they are asking for the new feature.
- Developers are too attached to their creations
- Developers might spend 40+ engineer hours each on a feature, and when the prototype iteration is released, the customer might say to throw the feature out. Developers will try to persuade the customer that it’s a viable feature (even though it may not); developers really don’t like wasting their coding time; however, it is a prototype so developers should be ready for features (especially those with a lot of sweat and blood in them) to be thrown out or never used.
- Way too much development time of a prototype
- This is where the paradox of rapid prototyping exists because RP boats faster time to market. Developers tend to over-architect and spend way too much time on the features of a prototype for efficiency or whatever reason, and a change in the requirements or features totally negates the time spent on the architecture. When it comes down to it, development teams really need to make their deadlines, so don’t over-architect a feature that the customer isn’t completely gang-ho for; just put enough design in to mitigate medium-level risks until the feature is solidified.
- There also exists a big balance issue here: do you sacrifice design for lowered development time? or do you extend the development time for better analysis and design? It’s all dependent on what type of prototyping you want to do; throwaway-prototyping makes it much easier to hack away and come back later for better analysis and design
What does it all mean?
It means that developers tend to work a ton of time (just to make the release deadlines) on over-architected features that the customer may or may not want.
How satisfactory is it for a developer when the stuff they create is destroyed?
Case Study: IT Asset Adhoc Reporting
Our customer has a contract with another very large company to audit the IT assets that the customer has. The original requirements for that large company were to produce quite a few reports of the IT asset audit status.
The customer then asked this contractor to produce a queryable form for all the IT assets, so the large contractor gave them a MS Access database with very elementary MS Access query Form.
We had the job to migrate the MS Access database into Oracle for reporting purposes, which stunk because there were no primary-key or foreign-key constraints enforced (replicated data was in the Access DB)
Adhoc Reports (ranting…)
The customer wanted us to create a mechanism for adhoc query reporting, but they didn’t know what they wanted, so we researched for a week on the industry standards of adhoc query reporting like JReport or some other type of business intelligence suites that had lots of features like pivot tables, drag-and-drop report generation, and drill-down capabilities.
We presented the idea to them and they said that they just wanted something that functioned like the MS Access query form, so we did that. Then they complained that the form looked like the MS Access query form!!!
We then needed to glean the report generation workflow from them and gave them working prototypes of each workflow. Their comments back were, “the form is missing these fields“, “the font is too big“, and “I want a green popup when I hover over this thing” instead of “we like workflow option 2″ or whatever.
We have been asking questions constantly about the requirements and the answers come back in the form of more questions!!! It’s just the way this customer is. Moreover, since we constantly ask them questions about the prototypes for feedback, they decided to take that as an offense and they complained to their higher ups that we weren’t doing anything. So what did we do? Make prototypes in closer release intervals! BAH!
Moreover, they told use that we can’t warehouse the data to normalize it, but yet they complain that they see null’s and replicated fields.
Since we aren’t a bunch of dumb developers, we like making good quality products, and when the requirements change as much as they do, it’s sad to see your stuff that you created just go to waste. I can’t tell you how many lines of code were just thrown away. I know that some of the readers will be saying, “well, you should have designed it better”. Well yeah, we know!!! However, with two week release cycles it’s pretty hard to do that when the requirements end up changing the design dramatically; moreover, I don’t want to work 80 hours a week on design that might change anyway.
However, they do pay the bills, so we must do as we are told. Enough of my complaining. This wasn’t as much of a case study as it was a rant I guess, and I do apologize.
The point of this is that it takes a lot of sweat and blood to make these prototypes, and the customer is just never happy; therefore, we aren’t happy.
Moral of the Story: If you are going to chose a prototyping method, use throwaway!!! It will be the best for everyone, and you won’t deliver a ball of hack as your final product.
Has Anyone Else Experienced As Much Trouble with Rapid Prototyping?
[poll id="9"] [poll id="10"]
What are Your Comments on RP?
Please leave a comment on your expieriences and thoughts of rapid prototyping!!