As a developer, you've heard this advice before: "Use the right technology to solve the problem at hand." It's probably one of the most sensible, but most confounding, pieces of wisdom I've encountered. Although it makes perfect sense to NOT make the WRONG technology choice, applying this advice in practice can be challenging for a number of reasons; tight project timelines and the current state of your technical skills toolkit, for example, can be limiting factors. While the decision has to be made sooner or later, I believe there's wisdom in not rushing this particular choice.
The "right technology" short list can, indeed, sometimes be very short. If the client will eventually take responsibility for maintaining a project, there may be only one option. But in the case where the client looks to you for guidance on making the right pick, as our clients often do, we rely on a liberal amount of technical experience mixed with a healthy dose of due diligence. Which ingredient is more important can be debated but one thing is certain; you'll rarely get it right if you have an inadequate understanding of the problem that you're solving.
There are many ways to develop this understanding but one of my favourite techniques, especially in the early stages, is to quickly build a prototype or a proof-of-concept. This process usually doesn't end up producing reusable code and that's ok. Often, the prototype isn't even built using the final programming language or technology stack and that's ok too. But the process of quickly banging out a real working thing to share with your client provides a tool around which to frame a discussion. And these tools can be invaluable for getting on the right track early and staying there throughout the project life cycle. And because prototypes help to facilitate the process of discovery, they're often fun to build because the task can be approached with a certain sense of unencumbered freedom.
In building my prototype, I aim to:
- Write it as quickly as possible.
- Maintain a tight focus that revolves around addressing a single, discrete challenge.
- Possibly write it a number of times to demonstrate X different options or approaches.
On the other hand, I purposely avoid trying to:
- Think about code re-use. The point is not to write clean, check-in ready code.
- Produce a fully built out solution; if the UI is the focus, I'll just mock up some data; if the focus is the back-end, the UI gets ignored.
Projects don't get into trouble entirely because of the technology choices that were made. But troubled projects are certainly more challenging when the "hammer" isn't well suited to the "nail". For me, prototyping lets me quickly discover the true nature of that problem I'm faced with. Is it a simple four-inch nail or one of those odd ball fasteners from IKEA? Armed with the answer to that question, I can properly stock my toolbox for the job at hand.
If you've been in the software industry for a significant period of time, you can likely recall a story that starts with "I wish I had...". With the software industry's speed of change, stories about how choosing the "wrong" technology led to trouble can be all too easy to find. I'd love to hear about your opinion on the value of prototypes. Don't be shy and drop us a line in the comments.