Hacker News Reader

Comment by readme | Hacker News Reader

Exactly. I had coworkers like this, and their code was impossible to understand. To make a simple change to it, it would require days of refactoring just to know you weren't going to introduce a bug.

It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write.

View on HN

"It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write." This. When someone does this in a hurry or because they didn't know better, it's understandable. But when someone thinks that this style of working is superior, that's a huge problem.

Paying down tech debt is like brushing your teeth, if you don't do it regularly, you'll end up with more pain and a higher bill at the end.

How old is the software and what's the change that needed. If the software is past it's ROI and changes are happening due to scope creep then days of refactoring isn't refactoring it's just days of dev work against new requirements. It's just happening on an old product.

Management may be willing to spend that time and not be unhappy with what you perceive as time wasted because they have seen greater than expected ROI on the product already so it's not a loss to them.

I've ran into these problems with software that wasn't even released yet. Some of these practices will likely bite you in the ass in months or even weeks, not years.

They generally get the next person to work in the code without understanding what was going through your head: and 90% of the time, that’s you, three days from now.

Reply on news.ycombinator.com