The Case of the Missing Product Feedback

I am working on an article about how crucial feedback is to product development these days, but we (as a society) don’t teach our internet users to give feedback with purpose. We generally only hear from a vocal minority, and in my opinion, that’s not enough.

Follow me here, on Twitter or LinkedIn to get updates.

The Hidden Cost of Technical Debt

I have some very strong feelings about technical debt, but first I want to share an article that I think does a great job of describing it and why it’s worse for your business than you think. (I highly recommend reading the whole post).

Here’s an excerpt from an article originally published March 3, 2016, by Sean Cuevo on Galvanize Blog – 🔗

The term technical debt is frequently used in the software development world to serve as a metaphor for doing things the quick-and-dirty way in order to get something out the door sooner rather than later. Just like its financial analogue, accruing technical debt is not necessarily a bad thing, so long as the value of delivering something more quickly outweighs the development costs (i.e. the interest) of fixing the quick-and-dirty solution in the future. However, the interest expense analogy usually stops there, ignoring the less quantifiable, more human side of debt that could end up costing more.

[…]

Cutting out features and taking time to clean things up may seem like a hit to both progress and budget, but technical debt is the most expensive when the people who are able to pay it down say “fuck it” and leave.

It then lists a couple of things that developers and their managers can do to prevent total failure in the face of technical debt.

http://blog.galvanize.com/the-hidden-cost-of-technical-debt/

---

My Response

This article resonates strongly with me, and I have a feeling that Mr. Cuevo and I have a couple of shared experiences. I’ve experienced this depressing work environment first hand with not one, not two, but three different employers. And since I was the latest developer hire at any of those places, there was very little I could do about it. Trust me, I tried. I couldn’t even share Mr. Cuevo’s post with my employers two years ago because it was a little too “on the nose”, and I had already expressed my concerns to my supervisors. This is a big part of my motivation to branch away from development and into product management. I’m aware that there are milestones the business needs to hit, but as the article says, there’s a limit to how much code you can sacrifice before the people building it don’t want to anymore.

The companies where I experienced this awful technical debt had mostly existed for at least 15-20 years before I joined, though the youngest of the three is now 6 years old (founded 2012). These are companies that should have hit some kind of stride already. The older ones in-fact had at one point been award-winning businesses leading their industry, but in trying to adapt to the new, digital world they failed to heed the advice of incoming talent more familiar with new technology. Or they acted too slow to save their businesses.

I pleaded with higher-ups to try to fix this to no avail. Here are a couple of the suggestions I made:

1. I asked that we take a sprint to clean up our good code and remove dead code.
2. I wanted to try to make a plan for how to combine the tools that had existed over 3 generations of discrete platforms.
3. Implement a “20% time”, as popularized by Google, but instead of working on pet projects, we work on the next generation of our code base. Optimized for all of our goals.
4. Test smaller projects with new architectures to see if they fit in with our model.

Some of them were considered but never followed through on. The responses I received included, but were not limited to:

1. If you would like to do it, you are welcome to do it on your own time (without pay). (This was the response I heard most often. As long as it wouldn’t affect the bottom line the managers didn’t mind. But this was without the support of team planning, discussion, sprint scheduling, or any other resources. So I found this to be an unacceptable solution).
2. We will do that soon. (No).
3. I’ll take that under consideration.
4. How much time will that take? You don’t know without consulting with the team and having a planning meeting? We don’t hame time for that.

There was always a deadline, a need for investors, or a milestone that someone several seats separated from the developer team has required of us, and the chain of command was not able to push back. Unfortunately in these situations it was usually too late because the culture of the company did not allow for fixing the technical debt in the first place.

In the end, one of the companies indeed lost a significant portion of their talent pool and has since been acquired and pivoted sharply, the other, a SaaS, closed down unexpectedly – causing a disruption across their industry on one of the busiest weeks of the year, the last is still growing into its aspirations. At the 2nd I even told my supervisor I was burnt out and I received a dismissive “what would you like me to do about it”.

Having experienced this so many times now, asking about a potential new employer’s technical debts and hopefully constant efforts to minimize them has become a required discussion point during interviews. Even then it’s easy for companies to hide the scary information under lofty ideas when you can’t see the code or know their history in-depth.

I joined these companies because all of them expressed interest in updating their tech stack, promised clean code, and had enthusiastic software engineers. I later learned that it would only happen when the budget allowed (rarely), and when we weren’t pushing strongly for funding (rarely). All of those enthusiastic engineers had already been on the team for 10 years and considered everything that was happening “run of the mill”.

If any readers have suggestions for new-hires to ask their potential employers which would help ending up at a company that has already amassed a large technical debt, please send them to me. I would this to be common knowledge. And if you’re at a company where’ you’re frustrated by this, please write to me and let me know about your experience. I would love to collect more of these stories to show how bad for business technical debt can be.