| This happens a lot with non-technical founders hiring contractors or employees. At first, the goal is “build a prototype,” then it’s “make this an MVP,” and then finally “what’s left to get this to production?” I don’t blame founders for this; I blame the programmers, especially if they’re consultants. This is a symptom of failure to manage expectations of stakeholders. As a developer, your job is to show the stakeholders what the tradeoffs of different decisions are, both in terms of immediate time to results, and technical debt. If you hear “make a prototype,” you better ask for a projected lifetime of the prototype, and discuss with the stakeholders the tradeoffs of quickly building a prototype, making sure they understand it could mean more work later to productionize it, in exchange for less work up front. Also as a developer, you should realize that nothing is ever a prototype. Don’t use “it’s a prototype” as an excuse for writing unmaintanable and insecure code, because eventually someone is going to want to add some features to it. Good luck telling the stakeholders after three months of building a prototype that you need to start from scratch because the code is awful. This is especially difficult if the prototype looks like a fully functioning product (with minimal features) to the stakeholders, but you as a developer know that under the hood it’s completelty unmaintainable. It’s better to take the time up front to put in place whatever you need to write quality code, than it is to take shortcuts and write bad code. A good developer will be able to explain this to a stakeholder, instead of caving under pressure to rush a prototype. |