[rampage101]

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.

[chatmasta]

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.

[s73v3r_]

No, I completely and fully blame the managers/founders for this. No matter how much you try to drill into their heads that this is throwaway code, once they see something, they get excited, and say "Ship it!"

[mnm1]

Unless you're paying top dollar for contractors, what you describe is way beyond the job duty of typical contractors brought in by non-technical founders who have no idea what they're doing. Even technical founders with a lot of experience make this same mistake. If you're not paying seriously high money, you might think that this is something you're paying for, but it's not. Someone at an overseas sweatshop isn't going to push back on a request for a prototype. It's not part of their job and it sure as hell is not in their own interest. People get what they pay for and most of the time, people who hire contractors without proper oversight are just burning money and have no idea what they even want to pay for, let alone what they've actually bought. Intelligence cannot be contracted for by stupid people.

[wolco]

Always write quality code or when bugs occur or new feature requests come up, they will call you. If you wrote something awful now you have to support it.

But you cannot blame the developer. Many app are prototypes to get them over a certain point to get funding. What happens is the technical debt is never paid and you are forced to scale the prototype while adding new features.