The Double-Triple Death March
Welcome to the main event. Spoiler alert - over $350k wasted in less than a year!
The events described here led me to stop coding for money. My revelation(s) became my main mission statement (explained below).
Despite the money wasted, my wallet got thick from the collective failures. I would have preferred to work with competent, responsible, and intelligent people.
Not always possible, software is a brutal field.
Double-Triple Death March Defined
Death March: I was amazed at how developers who are 5 or 10 years into their careers know so little about the greater software experience.
I am speaking about the term “death march,” a scenario well-known to almost all developers.
A death march in software is the all-too-common scenario where a team continues down the path of a project, product, or feature, knowing it will fail. Regardless, management, investors, or some other high-influence person insists it is a good idea.
Now triple it: How about a “triple death march?” This is a unique scenario. A triple death march is learning that I was the third developer (triple) to try and fail at the task.
Two developers before me tried and failed. No one tells you this when you start, only happy unicorns flying out of the ass about the project. Gaslit, as usual.
Remember, it typically takes at least three months to understand how you are screwed, someone set you up, or both.
Now double it. Understanding the triple-death march, double it.
I had two triple-death marches, one after another—nearly a whole year working on doomed-to-fail projects—nothing but frustration and late nights. I remember my breakdown, lying on the carpet in my office, crying.
Programmers generally have a “this code sucks, starting over” reputation that precedes our arrival and slows down projects. I talk about this in the lessons+solution section below.
What Was I Coding?
First, it was a complex project that needed new features and the removal of old ones. The codebase was poorly designed, untested, and undocumented. Despite my 15 years of experience and career dedication to the language and framework, I spent a month reverse-engineering and creating fixtures to run it locally. I saw nothing but tech debt and no grasp of the severity of the problem by leadership.
The other project required building a high-performance data processing application. Despite meeting 95% of KPIs, poor support led to my drowning and accepting a PIP that I rode out to get fired.
On one project, a resentful junior developer, secretly on anti-psychotic medication, posed challenges. I discovered this accidentally and used the information to navigate the situation carefully. I was walking on eggshells. He would pull in our boss when I rightfully pointed out his mistakes (I now know them as sabotage).
Both projects ultimately failed due to technical debt and poor understanding of the problem. One startup hired me for my language and framework expertise and assigned unrelated tasks, including OpenGraph integration, open-source modifications, and database troubleshooting. While there, I saw AWS spending spiral out of control, reaching six figures monthly against a $20k budget—more details in the lesson+solution section.
Numbers: Tech debt gig.
Three developers at the market rate for three months each, so ($120k/year)/4 (3-month salary) = $30k. Now multiply 3x for the devs = $90k. Add in search, hiring, and onboard expense per dev ($9k x 3)= $27k. Not delivering the feature: $ unknown.
Low numbers are $127k wasted in one year with nothing to show. No developer is happy. No one retains important domain knowledge. There is no long-term support.
The mistake: Thinking hiring “freelancers” would be cheaper. You need to know how to manage developers and projects (see lessons+solutions below) and orchestrate standards and handoffs.
Numbers: Data app
I was there for nine months, costing them $90k.
The other devs were three months minimum, another $60k combined.
That team got nothing and lost around $200k while I was there due to infrastructure mismanagement, poor leadership (most new to the C-suite), and deep investor pockets with little oversight.
Another Mistake shared by both companies and a flag for others: Having zero handoff indicates that the previous devs checked out, just as I did, wanting nothing to do with leadership ever again.
(Multiple) Revelations
The first was depressing and hurtful: I was ineffective behind the terminal. To most companies, a developer is just part of doing business, their estimates always suck, and developers can and are replaced at will.
The next revelation was simple: Being mismanaged almost my whole developer career, I can shout out to the few good leaders I have worked with, but they are few and already have my praise and respect.
The big revelation: I can do more! I started my tech career in the early 2000s as a PM, which was the direction I needed to return to. Be the steward I never had.
The last revelation I stand behind daily Is helping people get the most out of software. As a leader, mentor, and team builder, my software knowledge can be used better, saving stakeholders money and keeping developers happy (and reducing turnover).
Lessons+Solutions
Problem: Developer(s) want to rewrite code and throw away current work.
Root Cause: It takes more time to reverse engineer code than to write a new solution.
Solution: Keep developers happy and on the team because their domain knowledge is worth more than you can estimate.
Problem: Uncontrolled spending on cloud assets
Root Cause: Developers were allowed to spin up, test, and abandon any service they wanted without guidance.
Solution: Senior developers or infrastructure needs to approve and assist with all spending, with no exceptions. Also, add spend alerts and keep a tight inventory of all deployed instances and services, auditing often.
Problem: Hiring “freelance” developers to save money and ultimately spend more than a full-time developer.
Root Cause: If you are hiring freelance developers for a large app (SaaS, not brochure website), you need someone committed who keeps system knowledge at least in the brain, ideally in documentation and via semantic coding and understandable patterns.
Solution: Avoid the risk of hiring freelancers without a proper handoff, tests, and documentation. Instead, look towards a long-term relationship, even if fractional, to capture key domain knowledge and stabilize the code and tech debt. Equally important is having leadership speak code; there is no substitute for this; these positions keep stakeholders in check and provide the support and unblocking developers need to focus on code.
About Me
I have had many successes, but failures, hard times, and difficult situations show a person's true nature. Do they run towards the fire or push women and children out of the way to find fresh air?
Despite the best intentions, ability to compromise, and skill in my field, not all scenarios will turn out well, especially if you are the third developer to try after two previous ones tried, failed, and left abruptly.
