| Great article. The one that hit home for me "One lone engineer on a big project silo’ed away". Was on a project where we had multiple applications. The team had a new employee code an entire system as a prototype but then it was decided to put it into production. Nobody ever reviewed this code, and that engineer told me himself that the code was crap. He left the project to get away from this code and I inherited a mess, with nobody to ask questions from. To make matters worse, the entire company relied on this system and there were about 20 regular users of this system. I was responsible for handling all of their feature requests and support which was often. Many bugs I fixed were extremely challenging edge cases, and there was zero appreciation for the complexity of many of these. My manager was telling others at the company the code was solid, and it's "just python code" which can be figured out. I notified the company I was leaving and they begged me to stay. Even offered to "release" me and hire me at a higher salary under another manager. The only issue was I would be required to support this same project. My manager refused to give me a release date so I had to call HR and tell them I needed to leave at any cost. Pretty sure it's a disaster there since I left. |
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.