The Way We Look at Technical Debt Is Wrong • Hacker News Board

Re: The Way We Look at Technical Debt Is Wrong

#71

Post by rsp1984 » Wed, May 13, 2015, 9:18 PM UTC

This btw is precisely what separates the good engineer from the great engineer:

A good engineer can produce a good product under moderate time pressure but will accrue technical debt in critical spots if more time pressure is applied.

The great engineer anticipates the change and will not strive for perfection in parts that are going to be rewritten in the future anyways but instead just make it do the job, while at the same time keeping things simple and flexible. That's how they deal much better with deadlines and time pressure.

Re: The Way We Look at Technical Debt Is Wrong

#72

Post by omouse » Wed, May 13, 2015, 9:21 PM UTC

moron4hire wrote: post #58

dccoolgai wrote: post #51

Earlier quoted context omitted.

|| they can have this feature today and in 6 months we grind to a halt Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had: PM: "Yes! Cut all corners and get it done today!" ...6 Months go by... PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..." PM:"Today, thanks!"

You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do…

That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment.

As you say, don't make magic happen. It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go and try and do it. Don't let the manager bully you and don't let them try and get another developer to tackle the impossible.

I've had that happen to me where I said it will take X amount of time to do it so let's not do it till next sprint. Then the manager went around my back when I was gone for a day and gave the task to another dev. The dev, who caused the mess, of course was able to fix it within an hour. Why did I say X amount of time? To cleanup and make sure the bug stays fixed.

When you work with other developers, actually work together. Stand up for them, don't make bad comments about them, and always stick together when you're asked to do the impossible.

Re: The Way We Look at Technical Debt Is Wrong

#73

Post by drhodes » Wed, May 13, 2015, 9:23 PM UTC

By the by, there's a recent software engineering radio podcast on technical debt:

http://www.se-radio.net/2015/04/episode-224-sven-johann-and-...

Re: The Way We Look at Technical Debt Is Wrong

#74

Post by MaysonL » Wed, May 13, 2015, 9:24 PM UTC

brlewis wrote: post #65

moron4hire wrote: post #62

Earlier quoted context omitted.

I suppose I could have said "most people" instead of "new PMs".

Yes, that would do it too. Generally I agree with you on the principle of using communication to help people learn from experience. I wrote about it here: https://medium.com/@brlewis/fighting-technical-debt-in-an-ag...

Yes, learning some lessons from other people's experiences is often much less painful…

Re: The Way We Look at Technical Debt Is Wrong

#75

Post by omouse » Wed, May 13, 2015, 9:24 PM UTC

ska wrote: post #12

The author seemingly misses an important way in which this can be looked at as "real". Some subsystems don't change much because they already do what is needed and aren't broken. Sure, the code could be improved, but it's not important enough to do (or at least, to do now). Other subsystems don't change much because they are scary to change. If the system is brittle and poorly designed, engineers may have very good r…

Even the code for the subsystems that work could be improved and turned into real dollars. I've seen it in so many projects where a commonly used web page loads very slowly. On an ecommerce site, seconds and milliseconds count. Optimizing those pages with caching would have provably increased sales (we saw sales go up on a page that was "accidentally" optimized ;)).

Speed follows quality.

Re: The Way We Look at Technical Debt Is Wrong

#76

Post by sirmarksalot » Wed, May 13, 2015, 9:31 PM UTC

dccoolgai wrote: post #51

moron4hire wrote: post #45

Earlier quoted context omitted.

New PMs are like children, they tend to only learn the fire is hot by actually getting burnt. Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I s…

|| they can have this feature today and in 6 months we grind to a halt Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had: PM: "Yes! Cut all corners and get it done today!" ...6 Months go by... PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..." PM:"Today, thanks!"

It sounds like you have a bad relationship with your PM. I've been in that situation before (seriously, check my post history), and it poisoned my attitude for quite a while.

There are a lot of terrible PMs out there, but there are also a lot of really good ones, and you learn to suss out which is which when you're interviewing for a new team. If you read Rands in Repose and start wishing your PM actually thought and cared about the things he talks about, maybe you need to find a new job.

Re: The Way We Look at Technical Debt Is Wrong

#77

Post by ska » Wed, May 13, 2015, 9:51 PM UTC

omouse wrote: post #75

ska wrote: post #12

The author seemingly misses an important way in which this can be looked at as "real". Some subsystems don't change much because they already do what is needed and aren't broken. Sure, the code could be improved, but it's not important enough to do (or at least, to do now). Other subsystems don't change much because they are scary to change. If the system is brittle and poorly designed, engineers may have very good r…

Even the code for the subsystems that work could be improved and turned into real dollars. I've seen it in so many projects where a commonly used web page loads very slowly. On an ecommerce site, seconds and milliseconds count. Optimizing those pages with caching would have provably increased sales (we saw sales go up on a page that was "accidentally" optimized ;)). Speed follows quality.

It probably could, but every hour spent on that has an opportunity cost. You might find the same hours spent elsewhere do more for you.

If you're doing your planning and analysis right, you should hope to have identified this... so in your example, hopefully that subsystem went up in priority because it was identified as a place for gain.

Re: The Way We Look at Technical Debt Is Wrong

#78

Post by sokoloff » Wed, May 13, 2015, 10:24 PM UTC

omouse wrote: post #72

moron4hire wrote: post #58

Earlier quoted context omitted.

You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do…

That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. As you say, don't make magic happen . It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go…

If I understand your story correctly, that other dev accomplished the task in some characteristically short amount of time, plus an hour for fixing a bug.

While you didn't specify what your "X" was, it sounds like the manager (and the company) got a better outcome by going around you and it was far from being "asked to do the impossible".

Re: The Way We Look at Technical Debt Is Wrong

#79

Post by jmaistre » Wed, May 13, 2015, 10:43 PM UTC

ekidd wrote: post #32

I'm unconvinced that accepting large amounts of technical debt allows startups to react faster. I've definitely seen startups that have almost found a good idea, but can't tweak it, scale it, or make it stable, because they're overwhelmed by technical debt and even simple changes have become engineering death marches. Letting your back-end code turn into a complicated, disgusting mess means that adding critical featu…

One of the most valuable startup skills is to know which kind of debt has a low interest rate and which kind of technical debt has a high interest rate. Certain things - lack of tests, poor build system, poor deploy system, very poorly structured code - have a very high interest rate. Every time you create bugs, you waste time tracking it down and fixing it. Every time you check something in that breaks the dev environment for the rest of the team, you create bugs. On the other hand, messy code that is isolated to one system, or an architecture that has a bit of copy and paste, are usually not too big of a deal. Going on some deep dive to create some "generalized framework solution" is almost always an error.

Re: The Way We Look at Technical Debt Is Wrong

#80

Post by moron4hire » Wed, May 13, 2015, 10:49 PM UTC

omouse wrote: post #72

moron4hire wrote: post #58

Earlier quoted context omitted.

You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do…

That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. As you say, don't make magic happen . It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go…

This is what I'm talking about with offering the alternatives. You can't hide the distasteful "make the pain go away, but not fix the underlying problem" option. You have to give people enough rope to hang themselves, which is thankfully also the same thing as giving them the opportunity to surprise you with their leadership. When you have a heavy-handed PM over you, you have to give them all the information, force the decision on them. Don't make the decisions for them that option A or option B is best. If they want to lead, they have to take responsibility for this stuff. It's up to you to present the options appropriately. "A) I hide the bug, maybe takes an hour, B) I fix it, probably takes a week". You don't know, you might be surprised, he might tell you "do both, A right now then get right on B." Or he might only be interested in A. Either way, if you don't want responsibility for the failures, you have to abdicate responsibility for the successes.