As recently discussed with two friends and colleagues, Raman and Darko, Proofs of Concept (PoC) or Minimum Viable Product (MVP) implementations can be a double-edged sword.
By building something without fully knowing the end-game, you are potentially building tech-debt that may be very difficult to work around without massive (or complete) overhaul of what you’ve built.
The alternative is to go through a process of discovery to build a detailed document showing what you think the end product might look like.
I’m all for leaving important documentation behind for those who come after us, for those who maintain the solutions we create or for those who build upon our solutions. But you’ll notice the past-tense in the sentence above.
There are pros and cons with each approach, but I tend to believe in documentation in the “as-built” sense. However, there is a definite need for some up-front diagrams/docs too (eg inspiring vision statements, use cases, architecture diagrams, GUI/UX designs, etc).
The two biggest reasons I find for conducting PoCs are:
- Your PoC delivers something tangible, something that stakeholders far and wide can interact with to test assumptions, usefulness, usability, boundary cases, etc. The creation of a doc can devolve into an almost endless set of “what-if” scenarios and opinions, especially when there are large groups of (sometimes militant) stakeholders
- You’ve already built something – your PoC establishes the momentum that is oh-so-vital on OSS projects. Even if you incur tech-debt, or completely overhaul what you’ve worked on, you’re still further into the delivery cycle than if you spend months documenting. Often OSS change management can be a bigger obstacle than the technical challenge and momentum is one of change management’s strongest tools
I’m all for deep, reflective thinking but that can happen during the PoC process too. To paraphrase John Kennedy, “Don’t think, don’t hope, (don’t document), DO!” 🙂