Comments on: Prototype Driven Development http://www.socialstartups.com/2008/09/25/prototype-driven-development/ All that's new in the social computing space. Tue, 06 Jan 2009 01:08:49 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Damian Watson http://www.socialstartups.com/2008/09/25/prototype-driven-development/comment-page-1/#comment-992 Damian Watson Fri, 26 Sep 2008 15:37:47 +0000 http://www.socialstartups.com/?p=57#comment-992 Some great ideas here and I can see it working very nicely in an internal development team, however, I fear that as a supplier to an external client, the needs of delivering to their requirement need a more managed approach unless they have come to you because they intrinsically trust your design. Here's an interesting related article: http://www.theregister.co.uk/2008/09/26/dev_workshop_week1_roundup/ Some great ideas here and I can see it working very nicely in an internal development team, however, I fear that as a supplier to an external client, the needs of delivering to their requirement need a more managed approach unless they have come to you because they intrinsically trust your design.

Here’s an interesting related article: http://www.theregister.co.uk/2008/09/26/dev_workshop_week1_roundup/

]]> By: Andrew Clay Shafer http://www.socialstartups.com/2008/09/25/prototype-driven-development/comment-page-1/#comment-991 Andrew Clay Shafer Thu, 25 Sep 2008 22:43:36 +0000 http://www.socialstartups.com/?p=57#comment-991 IMHO, this is very close to what XP advocates with the following principles: Make frequent small releases. No functionality is added early. The customer is always available. I don't think you really understand Test Driven Development, but that's ok most people don't. Your ideas are not incongruous with TDD, it's just that developers write the tests to drive the process. The end result is usually well tested code that is easier to maintain. (developing this way is a skill and a culture, and it can take some getting used to) I like your thought process, but there are definitely times when the development tasks are going to require some deeper diving and the prototype might not reflect those changes for the next day. I think you also need to consider how to apply this to an existing product/code base. Prototypes can be rapidly created in the greenfield phase, but an established product that needs new features can take much longer to change. Thoughts? IMHO, this is very close to what XP advocates with the following principles:
Make frequent small releases.
No functionality is added early.
The customer is always available.

I don’t think you really understand Test Driven Development, but that’s ok most people don’t. Your ideas are not incongruous with TDD, it’s just that developers write the tests to drive the process. The end result is usually well tested code that is easier to maintain. (developing this way is a skill and a culture, and it can take some getting used to)

I like your thought process, but there are definitely times when the development tasks are going to require some deeper diving and the prototype might not reflect those changes for the next day. I think you also need to consider how to apply this to an existing product/code base. Prototypes can be rapidly created in the greenfield phase, but an established product that needs new features can take much longer to change.

Thoughts?

]]> By: dondo http://www.socialstartups.com/2008/09/25/prototype-driven-development/comment-page-1/#comment-990 dondo Thu, 25 Sep 2008 19:20:30 +0000 http://www.socialstartups.com/?p=57#comment-990 This is the beginnings of a great idea -- although I suspect SCRUM advocates would suggest that it's "exactly" what SCRUM tries to accomplish (you do sweep a pretty important component under the carpet by ignoring prioritization: "if you don't know where you're going, you're lost." Also, and equally, "Plans are easy. Execution is hard.") OTOH, if you want to see what this idea would look like if it was pretty fully fleshed out, take a look at: From: http://gettingreal.37signals.com/ <blockquote> Done. Start to think of it as a magical word. When you get to done it means something's been accomplished. A decision has been made and you can move on. Done means you're building momentum. But wait, what if you screw up and make the wrong call? It's ok. This isn't brain surgery, it's a web app. As we keep saying, you'll likely have to revisit features and ideas multiple times during the process anyway. No matter how much you plan you're likely to get half wrong anyway. So don't do the "paralyis through analysis" thing. That only slows progress and saps morale. Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn't work out. Accept that decisions are temporary. Accept that mistakes will happen and realize it's no big deal as long as you can correct them quickly. Execute, build momentum, and move on. </blockquote> This is the beginnings of a great idea — although I suspect SCRUM advocates would suggest that it’s “exactly” what SCRUM tries to accomplish (you do sweep a pretty important component under the carpet by ignoring prioritization: “if you don’t know where you’re going, you’re lost.” Also, and equally, “Plans are easy. Execution is hard.”)

OTOH, if you want to see what this idea would look like if it was pretty fully fleshed out, take a look at:
From: http://gettingreal.37signals.com/

Done. Start to think of it as a magical word. When you get to done it means something’s been accomplished. A decision has been made and you can move on. Done means you’re building momentum.

But wait, what if you screw up and make the wrong call? It’s ok. This isn’t brain surgery, it’s a web app. As we keep saying, you’ll likely have to revisit features and ideas multiple times during the process anyway. No matter how much you plan you’re likely to get half wrong anyway. So don’t do the “paralyis through analysis” thing. That only slows progress and saps morale.

Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.

Accept that decisions are temporary. Accept that mistakes will happen and realize it’s no big deal as long as you can correct them quickly. Execute, build momentum, and move on.

]]> By: Lenny http://www.socialstartups.com/2008/09/25/prototype-driven-development/comment-page-1/#comment-989 Lenny Thu, 25 Sep 2008 16:58:41 +0000 http://www.socialstartups.com/?p=57#comment-989 This is definitely an interesting idea. What I am really curious about is the process that is needed for the "drive to launch". From my experience in writing code, a daily prototype use doesn't leave time to fully develop out feature sets. This will likely leave you with stubbed code throughout this iterative process leaving the amount of productionalization at the end to be very substantial. I have experienced what you mention here (html and css) in a very iterative environment with a designer. The results were fantastic for the polish of the experience, but it still left a lot of things that needed to be worked out in code and some that just were not scalable or time to glass was impacted. An as for increased quality, it just means that you have correct fallback for failure cases which will occur. Another criticism I have is that you are flaunting the no silos. This is great but there still needs to be a single owner. If dev 2 recommends a visual trick, and the UI designer nixes it. That is it. It should be that way as you still need signoff for launch and features. All the criticism aside, I think there is a place for this type of process and it is a good stab at formalizing what I think many small teams already execute. This is definitely an interesting idea. What I am really curious about is the process that is needed for the “drive to launch”. From my experience in writing code, a daily prototype use doesn’t leave time to fully develop out feature sets. This will likely leave you with stubbed code throughout this iterative process leaving the amount of productionalization at the end to be very substantial.

I have experienced what you mention here (html and css) in a very iterative environment with a designer. The results were fantastic for the polish of the experience, but it still left a lot of things that needed to be worked out in code and some that just were not scalable or time to glass was impacted.

An as for increased quality, it just means that you have correct fallback for failure cases which will occur.

Another criticism I have is that you are flaunting the no silos. This is great but there still needs to be a single owner. If dev 2 recommends a visual trick, and the UI designer nixes it. That is it. It should be that way as you still need signoff for launch and features.

All the criticism aside, I think there is a place for this type of process and it is a good stab at formalizing what I think many small teams already execute.

]]> By: Kristi Colvin http://www.socialstartups.com/2008/09/25/prototype-driven-development/comment-page-1/#comment-988 Kristi Colvin Thu, 25 Sep 2008 16:16:22 +0000 http://www.socialstartups.com/?p=57#comment-988 I do need to add, a "standards" guide is essential, in my opinion, for developing from prototypes. The prototypes themselves (one would think) communicate details, but the reality is there are so many small design details for charts, reports, screen layouts, interaction functions, etc. that you need a separate standards guide always present for developers so they know to implement things correctly and consistently. So in that regard, I do have additional documentation that goes with the prototypes. I do need to add, a “standards” guide is essential, in my opinion, for developing from prototypes. The prototypes themselves (one would think) communicate details, but the reality is there are so many small design details for charts, reports, screen layouts, interaction functions, etc. that you need a separate standards guide always present for developers so they know to implement things correctly and consistently. So in that regard, I do have additional documentation that goes with the prototypes.

]]> By: Kristi Colvin http://www.socialstartups.com/2008/09/25/prototype-driven-development/comment-page-1/#comment-987 Kristi Colvin Thu, 25 Sep 2008 16:04:44 +0000 http://www.socialstartups.com/?p=57#comment-987 This approach definitely works. I have done this for years - not that in a larger company we didn't also have all the typical software dev specs you would expect, but my design prototypes have driven virtually all the software I've worked on since about 2000. At my own startup, we always start with prototypes as a way to "think out loud" about what we're doing, and tools like Balsamiq's Mockups make doing quick prototyping easier. I've worked with design prototypes in every format imaginable, including Excel spreadsheets! (Not my favorite.) It is true that you have to reiterate the prototypes often, because of issues discovered during development. But this is my preferred way of doing software design & development... it makes it so much easier for teams of people to brainstorm and reach agreement when they can SEE what they are creating. This approach definitely works. I have done this for years - not that in a larger company we didn’t also have all the typical software dev specs you would expect, but my design prototypes have driven virtually all the software I’ve worked on since about 2000. At my own startup, we always start with prototypes as a way to “think out loud” about what we’re doing, and tools like Balsamiq’s Mockups make doing quick prototyping easier. I’ve worked with design prototypes in every format imaginable, including Excel spreadsheets! (Not my favorite.) It is true that you have to reiterate the prototypes often, because of issues discovered during development. But this is my preferred way of doing software design & development… it makes it so much easier for teams of people to brainstorm and reach agreement when they can SEE what they are creating.

]]> By: Brett Witt http://www.socialstartups.com/2008/09/25/prototype-driven-development/comment-page-1/#comment-986 Brett Witt Thu, 25 Sep 2008 15:39:07 +0000 http://www.socialstartups.com/?p=57#comment-986 Definitely not a bad idea. It's extremely similar to eXtreme programming (at least most flavors of it) in that you attempt to present an application to the user/customer/whatever as soon as possible and then iterate on it on a regular schedule. http://en.wikipedia.org/wiki/Extreme_Programming Personally for me I always follow something similar to this as I'm not skilled enough to write a ton of code, execute/compile it, and expect anything usable to come out! Nice post. ^_^ Definitely not a bad idea. It’s extremely similar to eXtreme programming (at least most flavors of it) in that you attempt to present an application to the user/customer/whatever as soon as possible and then iterate on it on a regular schedule.

http://en.wikipedia.org/wiki/Extreme_Programming

Personally for me I always follow something similar to this as I’m not skilled enough to write a ton of code, execute/compile it, and expect anything usable to come out! Nice post. ^_^

]]>