Dev Corner - Prototyping Apologies
Posted on Thursday February 24, 2011 by Betsy Weber
Tagged as:
It's Thursday and that means it's time for another Dev Corner blog post. This week's post is from Matt Mercieca. Enjoy!
The start of a new year is a good time for confession and apologies. I have wronged prototypes. Sometimes negligent, sometimes well intentioned, and other times not, I have found several creative ways to misuse this tool. I'd like to correct that now.
The first of my wrongs is using something that I call a prototype to increase a feature's priority. The conversation goes like this:
ME: Hey, product manager, here's a feature I prototyped. Isn't it cool?PRODUCT MANAGER: Yes. When can we get it in the product?
ME: Oh, it shouldn't take long. About a week, I'd guess.
It sounds harmless enough. Those using Captain Subtext's Truth Seeking Helmet would have heard this, however:
ME: Hey, product manager. Here's a feature I couldn't work in to your process or wasn't a priority. Instead of waiting I just wrote it in some spare time. Isn't it cool?PRODUCT MANAGER: Yes. When can we get it in the product?
ME: It's ready for a code review and QA now. I won't admit that though. Instead I'll say a week.
It doesn't matter if the work was done in spare time. If code is ready for release then it is not a prototype. It was production code developed in spare time. Prototypes are useful experiments: they allow developers to cheaply explore alternatives or devise a plan. If quality practices are rigorously used then the development isn't cheap and a prototype isn't the result. Further if prototyping is a problem solving strategy used later, then the product manager and other developers are set up to be disappointed with the results, the process, or both.
The second offence is using prototype as a weasel word. That conversation goes something like this:
ME: I've been working on that feature and I think I have a prototype.OTHER DEVELOPER: It seems to work. But I noticed this over here...
ME: Well, it's just a prototype.
OTHER DEVELOPER: Oh, right. We'll fix that before it goes in to production.
As deadlines approach the conversation is forgotten--- or worse, ignored--- and the prototype is released in to production. There the price of cheap development is paid in maintenance: when a bug shows up; when the feature needs to be extended; or when the original developer is transferred to another team. The suffering usually outweighs the pain of doing it right the first time. That is clear in hindsight but difficult to recognize that in the moment.
My last transgression is the easiest to hide: "Maybe we should spend some time prototyping that," I'll say. I might even be using prototype correctly here--- one of the few times that I do.
More likely I was hiding something. "That's a really big, important feature and I have no idea how to start," I could have said. That is so easily covered by the keyword prototype. Covering leads to time wasted which could have been dedicated to working with my team to break down the problem into manageable increments.
Prototypes don't deserve the bad reputation I am helping to create. They are core agile tools: low cost experiments that can be used to quickly add value to the end product. The software industry is one of the few places where significant value can be added in the design phase. We don't have to use cheap parts to bring the end cost down. Instead we can conduct cheap experiments and deliver a higher quality product at the end.
From now on I will use prototypes to answer a specific question like:
- What are the risks of this approach?
- How will this approach perform with live data?
- Can different technologies do this better?
- How will this fit in with the rest of the system?
This is not an exhaustive list. Most questions, like these, are similar to the ones I use when planning research. That's a fair guide as prototypes are a great research tools.
I will not:
- Write prototypes in the production codebase. I will use a local branch or create a new project.
- Prototype a large unknown. I will break the problem down into small units which may then be prototyped.
If I follow those two rules then I won't commit any of the above sins. I hope prototypes will one day forgive me for the damage I caused.
Matt Mercieca started at TechSmith as an intern in 2002. After graduating from nearby Michigan State University with degrees in Computer Science and English, he started working full time as a software engineer. He has contributed to: UserVue.com, Screencast.com, and is currently working on supporting TechSmith's growing ecommerce needs.
