My last two posts described a project that I took from conception to working prototype.

Post 1     Post 2

Finding it in my garage gave me the chance to reflect on the design process through the lens of historical recollection. While historical recollection isn’t the most accurate process, given how memory works (or doesn’t), the self-timer I found in the garage is really just an artifact to focus my reflection.

Reflection

The first thing I realized was what I didn’t realize at the time. What I recall at the time was how each subsequent step (Idea, design, working demo, prototype, and beyond) seemed to require about an order of magnitude more effort.

1. The idea? About 5 seconds.
2. The sketch? 5 minutes.
3. The design? 5-8 hours.
4. The working demo? A couple of days.
5. The prototype in the photo? About another week.

That ratio has been reinforced in my subsequent experience as a software developer and even as a writer. What I didn’t appreciate at the time (or for a long time after this project) is how often I would try to be convinced that this wasn’t going to the case in this project (whatever this project was at the time).

Only experience would reveal that.

Lessons

Looking back on this project as a way to learn the lessons I listed in the earlier posts, I wonder if I could have learned those lessons at the time–while building the project. Maybe. What I realize now is that I didn’t recognize the significance of what I learned during the project.

Feature creep? Happens all the time and requires a constant vigilance and focus on the goal to avoid.

The illusion of a prototype/demo being the final project? Another element that has profound impact on the perception of the project–one that can work for or against you, depending on the circumstances.

“…but it looked good on paper…” Definitely a lesson on the importance of understanding how implementation details can pull the finished project away from the original design.

The problem with these lessons is that their impact is often felt long after the pivotal event. Feature creep? It always looks like a good idea when nothing costs anything (i.e. it’s just another line on the drawing or another bullet point in the spec). However, when release is delayed due to integration issues that result from the extra bullet point, the fingers point to implementation, testing, etc. everywhere but back to that moment in the conference room in which the bullet point was added–further masking its effect.

Agile methodologies

Since this project, I’ve learned a lot more about projects and project management. Looking back on this, now, gives me the perspective to appreciate how Agile methodologies do a lot to shorten the distance between events of each of the effects listed above and their effects.

Maybe that’s the lesson to take away from the reflection?