I enjoyed this article and I think it's helpful for technical leaders in early stage startups. I feel like a lot of these companies will continue having problems mostly because the people that are attracted to smaller/early-early companies are the same kinds of people that don't want to work in structured (more corporate/deliberate) environments.
My experience is a bit more on the agency side where technical debt is caused by developers/project managers not really caring about the longevity of an application. The idea of going back and fixing anything that isn't specifically called out and invoiced for is so far away from the priorities of these businesses.
> My experience is a bit more on the agency side where technical debt is caused by developers/project managers not really caring about the longevity of an application. The idea of going back and fixing anything that isn't specifically called out and invoiced for is so far away from the priorities of these businesses.
This resonates with me. I consider myself a better fit for product focus vs project focus, preferring to find something meaningful and nurture it in terms of value to customer, and value to developers (code quality).
Recently I accepted a job at an Agency, which a coworker described as a "chop shop". I became depressed. The app I would work on, got frenzy activity from Oct - March. It had to be released in March no matter what. Between that time there was no activity, no refactoring, no addressing tech debt. In fact, one week in December the client was unable to pay for some technical budgeting reason and we all just sat around for that week despite looming deadline.
Well, over the years this thing accumulated tech debt. Even though it was a cash cow for the agency: reliable income at reliable times from a good customer. One would think the health of the product would somehow invite extra effort. Every year new devs would start working on it (new devs, because turnover at these places is high). They would look at the mess and begin resume driven development to use the shiniest new things that were left out, hoping to fix and compensate for the problems from just sheer neglect, and then move on for the cycle to repeat.
That said, there are people that just prefer hopping from project to project to experience new things.
I suspect the tech debt that many start ups encounter is a matter of execution. They likely require original solutions to tough problems in very short time. The way to reduce tech debt in this case is to make deliberate time at great expense to frequently refactor complexity out of the system.
In the corporate world, on the other hand, the problem is an astonishing fear of originality. Most places I have worked have invented here mentality baked into every decision. Every 5 to 8 years they start over completely with a different tool, framework, or language hoping it magically solves for the group’s prior poor implementation.
My experience is a bit more on the agency side where technical debt is caused by developers/project managers not really caring about the longevity of an application. The idea of going back and fixing anything that isn't specifically called out and invoiced for is so far away from the priorities of these businesses.