Home » Software Development » Prototype Driven Development

About Arieh Bibliowicz

Arieh is a longtime programmer with more than 10 years of experience in enterprise grade software projects. He has worked as server-size programmer, team leader and system architect in a mission-critical high-availability systems. Arieh is currently a Program Manager (PM) in the Microsoft ILDC R&D center for the Azure Active Directory Application Proxy, and also a PhD student at the Technion where he is developing a Visual Programming Language based on the graphical language of the Object-Process Methodology, using Java and the Eclipse platform.

Prototype Driven Development

When starting a new software project, the number of unknowns is huge. We have learned the hard way that one of the most costly problems in software development is getting our requirements wrong, and by using Agile, MVP, and similar techniques, we have improved this somewhat in that at least we know think we know what our customer wants and are willing to change/improve/redefine this as we go a along.

But in the way, we still have to solve technical problems that are not known to us…

 
 
 
 
tasks

And what is the best way to counter this problems? by building prototypes.

Let’s say you are now developing a new messaging application that lets users share videos in real-time, with the option to embed annotations in those videos (just popped up in my head… is there an app already out there that does this? Do you think it is a good idea?). Anyway, leaving the detailed user experience problems (which are many), this app also has a number of technical challenges that can’t be neglected. For example, we are doing streaming editing of video… this needs a lot of computer power. I actually don’t really know if this is possible. But as developers, we take the challenge and say “no problem, just decode the video on the fly, add a new layer, encode it again, and voila!”. Yea right. You will probably start writing this code and get into so many rabbit holes that you will never get out of them.

So what I propose is that for features that have a high level of risk (i.e. there are too many unknowns, technology is new, having no knowledge of technology, etc), the first sprint of development be used to create a prototype that proves the technical feasibility of the feature. This prototype should be clearly bound to test ONLY the technical problems that we think will block us during development, without doing anything else that is not related to this technical problem.

Once the prototype is done, we can go on to develop the feature in the regular Agile method. What we have earned here is a new level of certainty not only in the feasibility of the feature, but also in how much time the feature will take to develop, how many people can work on the feature in parallel (many times constrained by the technology being used). This in turn gives a sense of security to the team that lets them feel that they are in charge and reduces the chance that things will start slipping from sprint to sprint, reducing team confidence, agility and performance.

Reference: Prototype Driven Development from our JCG partner Arieh Bibliowicz at the Vainolo’s Blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

 

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

 

and many more ....

 

Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions

 

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Alex Beggs
Alex Beggs
7 years ago

I agree with you and so does the Agile. Those are called spikes in Agile. This isn’t a new concept.

http://scaledagileframework.com/spikes/
http://agiledictionary.com/209/spike/

Also could you please do a grammar check before posting your article. I have found that the quality of the writing has deteriorated on this site.