Rules are meant to be broken, and sometimes there is a reason for veering from standards. We often do this to build a one-off or maybe a proof-of-concept. These are situations where we have a form of excuse to try out a new language or create something quickly instead of “correctly.” The rules are different for these projects, so what should we include in our planning?
Avoiding POC Problems
A critical flaw in some proof-of-concepts projects is that it is too good. There are times where the powers that be want to move forward quickly and build on that POC. While that may be feasible, it is often a wrong decision. There are short cuts taken for a POC that need to be addressed before moving to production. Therefore, it is often cleaner to start from scratch and use the POC as a reference instead of source code.
This need is where doing a POC in a different tech stack can be a plus. When you are a specific tech stack shop, it is going to be difficult to change gears to another one. That means a POC in another stack has a built-in excuse for being done from scratch rather than extending it. This approach may seem a bit sneaky, but sometimes you need to provide a little insurance against an overzealous sales or marketing group.
A Shorter Solution Path
Some technologies are best suited for larger projects. We have looked at tools like scripting languages that can be a way to produce a result quickly. When you need a solution fast and will only need it briefly, it is a perfect opportunity for veering from standards. We often see this occur with migrations and upgrades. By definition, you are not going to migrate or upgrade more than once (or maybe a few times), so the tools for that are throw away. The shortest route to building those tools will usually be the best.
The MVP As Pivot
A POC has some good reasons for a different tech stack. An MVP is not the same. One of the essential features of an MVP is that it is a starting point for the product. When you build an MVP and do not extend it, you are not creating a proper MVP. Thus, creating an MVP by veering from standards may cause an unintentional pivot from your tech stack. I have seen this happen when a consulting group is brought in to jumpstart a new product. They build an MVP but do so with their core competencies. The end result is an organization that is forced to support multiple tech stacks. While that is feasible in some situations, it is rarely recommended.
Episode Challenge: Consider the last time you did a POC or one-off. Did you stick to the normal tech stack or use it as an opportunity for something different?
