Hacker News Reader

Comment by JMTQp8lwXL | Hacker News Reader

You're right-- nobody wants to hear about refactoring. Management instead hears "time sink and no additional revenue" (which isn't true, since too much technical debt reduces velocity-- but you're the engineering expert, not management. For a moment, let's forgive their naivete). So when you pick up tickets, build more time into your estimates. Adding 30% more time to your estimates isn't crazy, since estimates are often wrong, and people frequently go over them. This really is a communication issue with how you package up your discussion of time allocation to management. Before exiting industry, I would consider giving this strategy a try.

View on HN

I’ve seen ex-engineers in management positions (one very well known and experienced engineer in particular) forget how important it is to offset technical debt. I think, more than naïveté, product managers just become consumed by feature-making and feel unproductive if there’s not a constant rush to hand new features off to engineering (which are then rushed to release).

> I’ve seen ex-engineers in management positions...forget how important it is to offset technical debt

I see this across industries. It seems easy for former insiders to lose the ability to empathize with those in their former positions.

Another example: teachers who become principals.

my charitable take is that they don't forget, but they have a hard time explaining to customers why the next release has fewer new features. "now with fewer crashes!" isn't really a good marketing pitch.

It's a fantastic pitch to the existing customers who have suffered through those crashes.

When OS X Snow Leopard was announced, this was the intro slide: http://2ig18m1zutag3bjpoclbo8am-wpengine.netdna-ssl.com/wp-c...

I think some part of this is that technical debt is invisible to the people that don't directly deal with it, so it's easy to underestimate how much of it there is.

We, collectively, need to get better at communicating the cost of the technical debt we face in each project. I stress that this is a two-part conversation: the engineers need to get better at explaining the amount of it in terms that matter to the end user, and management needs to learn to understand what the engineers are trying to say.

Let's also not forget that the engineers are the ones who produced the technical debt in the first place. The earlier it can be identified and weighed against other business desires, the better. Speak up about it not only once it sucks but also when it is created in little pieces.

This reminds me of an article posted here a week or so ago (and posted many times before that) about working in a "feature factory":

https://news.ycombinator.com/item?id=22335738

It's worse. There are two cases I've observed.

The first is that some of these managers never really understood technical debt in the first place. They ascended to the position because they were willing to do "what it takes" to get the job done, with a "can do" attitude that often meant bowling over those who tried to keep sanity.

The second is the people who learned the right way, got into management, and then were crushed by the deadlines and expectations and the only thing they could figure out (while keeping their job) was to acquire more technical debt until it wasn't their problem anymore.

I always hear one of the two things when I say refactoring.

1. We will see, if we have time.

2. Why is it not written better the first time?

The first option is mentioned by managers who have been developers before and understand stuff like this, but need to balance the delivery aspect.

The second option is said either by clueless managers and senior developers who think an all-encompassing upfront system architecture/design would have been the solution. I can talk to the senior developers about it but I don't know how to respond to the clueless managers yet.

Edit: s/hear two/hear one of the two

Reply on news.ycombinator.com