
We’re Drowning in Tech Debt. Why Isn’t Anyone Listening? - dsr12
https://hackernoon.com/were-drowning-in-tech-debt-why-isn-t-anyone-listening-f4269cb5cc40
======
jmcomets
I recommend reading The Mythical Man Month[1] to anyone interested in proper
SWE project management. There are so many wannabe managers out there that will
just through more people at a project which is slowing down.

To quote the book: "Adding manpower to a late software project, makes it
later". There's some really good stuff in there, even for those of us that are
less interested in management.

[1]: [https://www.amazon.com/Mythical-Man-Month-Software-
Engineeri...](https://www.amazon.com/Mythical-Man-Month-Software-Engineering-
Anniversary/dp/0201835959)

~~~
kwhitefoot
I keep recommending it to my younger colleagues but they just make polite
noises and forget it.

Some of Brooks' suggestions for the make up of a development team are
interesting. In particular I have always liked the idea that there should be a
toolmaker. Most of us are less efficient than we could be because we lack
specific tools to do the job and we don't personally have time to make them.
If we had someone who's only job was to make tools I think a lot of things
could go faster. Of course this only applies to moderately large teams.

~~~
carlmr
I'm my team's toolmaker. There's just so much lost opportunity in custom tools
doing repetitive tasks, it's strange that you would leave that on the table.

But I'm not getting paid for it, my manager doesn't order it. He's kind of
happy to see us getting more efficient with less bugs. But it would be good to
have some support.

------
bfu
Because when you wait a little bit and work on something else for a while,
original requirements will change and you don't need to refactor at all.

------
dehef
Tech is time, time is money. There always an ajustement tech-money. You can't
promoting new tech or refactoring without looking contingencies. What you need
is just a circular graph. Who can be a vicious circle or a virtuous cycle,
depending who is in charge.

------
optimusclimb
IME this is why some new companies are extremely choosy with hires for a long
time. The newer/smaller the company, the less time there is available for
oversight of each other's work. That is not to say zero review happens, but if
you're trying to move fast, trust and confidence in what the rest of the team
is doing facilitates that.

This may sound overly negative or controversial, but I think there are a lot
of tech workers out there that are technical debt factories. They'll produce
highly coupled code, super long functions, inefficient code, etc...and be
extremely defensive during code review. The mantra you'll hear from this
person is, "but it works!" \- which is exactly what the PM will hear.

So it gets shipped. After this happens enough, "simple" changes to the product
that should be easy to produce, aren't so simple.

------
convolvatron
Imagine you're a CEO, or VP sales, or anyone with responsibility for moving
the company forward. Lets say you have a technical background and actually
understand how bad things can get with a codebase.

Its year 2 and you're desperate to ramp sales. the company is in existential
crisis, the end of the runway is approaching rapidly. The product ostensibly
works, but there are lots of customer problems and new feature requests always
seem to get bogged down.

Your technical leaders say that the product has driven into a swamp, and you
need 2 months to dig it out, plus 30% overhead ongoing to finish the cleanup
and try to keep on the straight and narrow.

Even though its the right thing to do in some world, how likely are you to say
'I understand, take all the time you need, we don't want these problems
plaguing us'

~~~
nickthemagicman
Well that's what happens technical debt is not properly accounted for. It can
kill the company. That's what's so scary about it.

------
trophycase
Fractional reserve software system

------
DeBraid
The solution? Get Real [https://github.com/DeBraid/tech-
notes/blob/master/basecamp-g...](https://github.com/DeBraid/tech-
notes/blob/master/basecamp-getting-real.md)

37signals wrote a book on this a decade ago before they changed their name to
Basecamp. It is loaded with practical advice on how to build good software and
avoid technical debt.

Aside: no affiliation, just a fan of the book.

