Iyfjky

Question

This question already has an answer here:

How can I show my boss that aiming only for quick wins is causing more problems than it solves?

5 answers

I'm currently working at a software company as a programmer and for the last couple of months I keep struggling with finding the balance between doing exactly what the company tells me to do and what I think is the 'right' thing do. I couldn't quite put my finger on what that nagging feeling was.

Recently I discovered this wiki article about technical debt in software and it was just so SPOT ON. Everything described in the article is exactly what's bothering me in my current projects. I feel like I'm being forced to create huge amounts of technical debt, and whenever I'm confrontted with technical debt from the past there is no time/budget to pay the debt off.

How can I address this type of concern in a way that I:

Give the impression that I care and want to help the company (as in, create better products AND create a better work environment where the team doesn't crumble under technical debt).

Don't give the impression that I'm complaining (which I actually am?) and want tp work at a slower pace (meaning, I need more time because I want to pay off the technical debt, In hopes that it saves time later on).

Would it help to get others involved in my plea? Or what that create a mob mentality of "us against the boss" that I should avoid?

Worth reading: meta.programmers.stackexchange.com/questions/6629/â€¦ — Dec 5 '14 at 13:28

Communityâ™¦ 1 · Answer 1 · 2017-04-12 07:31:57Z

This is pretty common and something you will encounter in most programming jobs. If you ask management to stop producing just to make the code clean they will likely look at you as if you were crazy. What you do instead is to it a priority to always make sure you leave the code better and cleaner everytime you work on it.

As you are working on tasks, make sure to add 10 - 30% tasks that improve the code, test or development environment. When you schedule tasks, add 25 - 50 % to a reasonable estimate to allow for code cleanup in the area you will be working on.
Dont ask for the time, do it anyway.

But dont go overboard. You will never have anything perfect, settle for making it better.

There are alot of techniques for this, but those are better suited for asking in the programmers stackexchange. Have a look at this question as a start.

My motto is: "Always leave the codebase in a better state than you found it." — Dec 5 '14 at 11:05
I agree with both of you. @JoeStrazzere is absolutely right that improving parts of the code that you don't actually have to touch risks introducing new bugs or other costs, and sometimes unfortunately the short-term fix pushes things in the wrong direction. On the other hand, I do agree with the goal of always trying to leave the code better than you found it -- better documented at least, to save yourself and others trouble later on. On the other other hand, when you're supporting multiple releases (as I am), figuring out which can/should be improved is messy. — Dec 5 '14 at 14:28
Code improvements should not alter functionality or API:s, so the effect on other teams will be minimal. There are techniques for localicing the changes, but thats a discussion for another forum. — Dec 5 '14 at 15:26
Fredrik: That's a great ideal. Unfortunately, when you have real customers out there, they may depend on behaviors which you didn't define as part of the official functionality; in large systems the same can happen accidentally internally. I absolutely agree that modularity should be the goal when you're implementing the code... but after it's been out in the field for a while you start to find yourself constrained in ways the modularity didn't protect you from, unless you're in a position to be able to say "we never promised that, don't do it" -- which can be hard to say to a huge customer. — Dec 5 '14 at 19:23

keshlam 41.5k1267144 · Answer 2 · 2014-12-05 03:10:16Z

Development engineering is, in large part, the art of deciding when something is "good enough." If you want it to be perfect, you're likely to be frustrated anywhere but research or academia.

What the company tells you to work on is the right thing to work on at that moment, I'm afraid. Sometimes that means doing a partial job when a complete solution would save a lot of future work, because available resources just don't allow doing everything immediately. Sometimes that means fixing things the ugly way rather than the right way because the ugly fix is "minimal" and considered lower risk.

You can try suggesting that they use a task tracking system (I could plug the one from IBM...) so it's clear what needs to be done, its size can be estimated, priorities can be assigned to it, and a reasonable conclusion drawn about whether the work can be contained with the staff they have or if they need to find a way to either simplify some of it, delay it, or bring more people in. But that usually requires convincing at least one manager or group leader to try it, demonstrating its value, and working outward from there.

Or you can wait until you're a team leader yourself and in a position to try to push this through.

Meanwhile... well, you can do a micro-version of this, maintaining a backlog list of the things assigned to you, with estimates of how many man-days each one will take, crossing things off and adding them as they're completed and assigned. That will at least give you a strong argument for telling your boss "Here's what you've already asked me to work on. If you want me to add something to the list, I can do so, but we need to agree on what its priority is relative to the others. They can't all be top priority."

+1. Two comments. (1) Even in academia, perfectionism won't work, because then you will never actually submit that paper, and at some point in time, you'll be out of a job. (2) Even team leaders can't push through what they like, since they face pressure from (product) management, sales, users etc. In life, you'll always need to compromise on something - the key is to do the best you can. — Dec 5 '14 at 7:16
There is a difference between shipping "good enough" and shipping something that just meets the immediate requirements but it is likely to cause a huge headache down the road. "Technical debt" refers to the later, I think. The right answer depends on whether the OP jsut wants to pretty up the code or spend extra time to build a solid architecture that will be much easier to extend and maintain in the future than a quick hack. — Dec 5 '14 at 13:53
We all hate it, but sometimes "we'll pay for it later" really is acceptable. ANY decent programmer wants to pretty up the code and architecture. Unfortunately (a) customers often want ABSOLUTELY MINIMAL CHANGES made until the next major release because they're afraid you'll break something (which is why I'm still stuck supporting some rather elderly code) and (b) sometimes getting something that works shipped now, while customers are ready to buy it, beats waiting for it to be cleaned up and losing them to a competitor. Track your technical debt and fix it in the next major release. — Dec 5 '14 at 14:14
(I should note that there are other approaches -- "continuous release", for example, as the open-source projects tend to run -- but unless the customers are willing to accept "first upgrade and let us know if that fixes the problem", that can be MORE expensive to support... and support is very expensive already. Tremendously aggravating, but it's a hard trap to get out of if you want major customers to trust you.) — Dec 5 '14 at 14:18
Perfection is in the eye of the beholder. You might think your class hierarchy is pure awesome sauce but the next guy (or even you in a year) might wonder if you were smoking crack when it was coded. Also, devs love solving specific problems in a generic way. This isn't always a good thing. — Dec 5 '14 at 15:00

user8365 · Answer 3 · 2014-12-05 13:27:47Z

There are signs of poor code that typically lead to technical debt. Your project may have many of them, but that's not the problem. You have to show how it is costing the company in the long-term.

I'm confrontted with technical debt from the past there is no
time/budget to pay the debt off.

Does this mean you don't have allocated time specifically assigned to clean it up or does it mean it takes longer to debug or modify the code because of the way it was previously built? You need to consider this in your estimates. When people ask why a fix/change will take so long, remind them how hastily it was originally build, so now it's not as easy to work with as it should be. This is where the debt is costing the company. if not, then you have no technical debt.

People and/or companies rarely change things if there are no consequences. It's great you recognize the technical debt, but you're not showing the problems it is creating for those decision makers. Hopefully, they'll hear you constantly having to delay things because of the poor quality of your current code base, that they may eventually suggest taking some time to do a better fix.

RemcoGerlich 3,4421018 · Answer 4 · 2014-12-05 09:20:42Z

Ask your manager what to do about it. Since you work in a software company, he should know what you're talking about, and have an opinion about what course he wants to take.

As cute as the term "technical debt" is, this is not something that has to be paid at some point, so it's slightly misleading. The fact is that existing code bases are always a bit hard to work with because you'd do always it differently if you could write it anew, but you have to work with what there already is. Sometimes the situation is much worse than other times, of course, and your manager probably knows what's up.

You, in the meantime, should always work using the Boy Scout Rule: leave the campsite cleaner than it was when you got there.

You can't clean up all the code, it's a massive investment of time that has no immediate business benefit and always takes much more time than you imagine, and you won't even be happy with the end result.

What you can do is 1) write your new code as good as you can (write tests, make it look nice, etc) and 2) clean up the code around it a little bit.

Just because technical debt doesn't have to be paid, doesn't make it a 'misleading' term. Monetary debt doesn't have to be paid either - a person (like a codebase, or a business) is free to die at any time... — Dec 5 '14 at 9:29
I said slightly misleading. You can write something that looks great to you today, and next year you'll be a better programmer and you'll think of that old cruft as technical debt. That you have improved hasn't decreased the value of the existing code, however. — Dec 5 '14 at 9:34

David 42929 · Answer 5 · 2014-12-05 14:58:32Z

It's commendable that you're concerned about technical debt. But I'd throw in a word of caution: at the end of the day, you're being paid to add value to the business, not to be an architecture astronaut. Sometimes adding value means accepting technical debt, at least in the short term.

That being said ...

As some of the other answers have suggested, you should quantify the cost of the technical debt. "I just spent a week fixing a bug related to poorly / hastily written code instead of adding new functionality; I know we all want to deliver value to the business, but this code base makes it really hard."

At the same time, you don't want to get a reputation for negativity ... so pick your battles. I'd suggest picking one or two architectural issues and getting buy-in to focus on those.

Try to find opportunities that align with an organizational objective. "I know upper management has shown interest in making our site more mobile-friendly; can we build in an extra day or two every time we touch one of the main pages to try and build in some responsiveness -- and do some refactoring?"

When a team really adopts / internalizes best practices -- as opposed to jumping through hoops to please the higher-ups -- that tends to happen from the bottom up. So lead by example. You could start by getting into the habit of writing some unit tests for new features you're working on, or to better define the conditions to reproduce a bug. (You won't get to a "good" level of test coverage overnight; don't worry about that -- 20% or even 10% test coverage of a feature is better than 0%.) Or pick some other best practice to adopt and hope it catches on.

Bottom line, this isn't an either/or. You need to provide short-term value to the organization and make sure you're still positioned to add value in the long term.

gnasher729 71.1k31131222 · Answer 6 · 2014-12-05 15:47:14Z

Practically every software development project has technical debt. Technical debt means that adding new features or fixing bugs will take longer than they would in a project without any technical debt. On the other hand, fixing technical debt also costs time. Fixing technical debt in an area where you don't know 100% sure that it will pay off is a bad idea. So you need to sell to your company the areas where it actually pays off.

A way that may very well work is to tell your boss that you would like to clean up an area where new development is happening anyway. There you can make the argument that some of the time spent on cleaning up will pay for itself by making the new development easier. And in the new development, spending some time cleaning it up immediately is very likely to pay for itself because there will be fewer bugs, and the bugs that you have will be easier to fix. Plus you will have a debt free area of code, which may (but only may) help in the future; if you can foresee that changes will be needed in the area, that is even better.

score 0 · Answer 7 · 2014-12-06 03:44:50Z

Limit the scope & quantify the impact

Technical debt only needs to be addressed to the extent it's risking the current or future health of the product. The aim is not to get to the "perfect codebase", but rather make improvements that have concretely make the product more operationally stable, easier to develop and maintain, and so on.

So instead of asking your manager for three weeks for some vaguely defined cleanup tasks, it would make your case a lot more concrete to also estimate the cost of living with the technical debt, and pitch it against the cost (time) to fix it.

The impact of technical debt could come in many forms: longer time to add features, more production issues, untestable code, high maintenance costs, fragility, etc. See what problems your codebase suffers from due to technical debt, and identify some specific cleanup tasks that would alleviate these.

Having some sort of measured impact can also prevent one from rabbit-trailing into code beautification that doesn't really pay off, and prevent a never-ending fix-everything-that's-wrong-with-the-world refactor project.

Coming up with focused cleanup tasks with high returns is not an easy task. If you think in the current state of the codebase it would take you some significant time to do this analysis, I would recommend approaching your manager with something like:

I think there are some cleanup tasks we can do in our codebase to significantly improve [stability / development speed / ...] in a fairly short time. I would like to take [amount of time] to look into this a bit further and come up with a cost / benefit analysis. What do you think?

Communityâ™¦ 1 · Answer 8 · 2017-04-12 07:31:57Z

This is pretty common and something you will encounter in most programming jobs. If you ask management to stop producing just to make the code clean they will likely look at you as if you were crazy. What you do instead is to it a priority to always make sure you leave the code better and cleaner everytime you work on it.

As you are working on tasks, make sure to add 10 - 30% tasks that improve the code, test or development environment. When you schedule tasks, add 25 - 50 % to a reasonable estimate to allow for code cleanup in the area you will be working on.
Dont ask for the time, do it anyway.

But dont go overboard. You will never have anything perfect, settle for making it better.

There are alot of techniques for this, but those are better suited for asking in the programmers stackexchange. Have a look at this question as a start.

My motto is: "Always leave the codebase in a better state than you found it." — Dec 5 '14 at 11:05
I agree with both of you. @JoeStrazzere is absolutely right that improving parts of the code that you don't actually have to touch risks introducing new bugs or other costs, and sometimes unfortunately the short-term fix pushes things in the wrong direction. On the other hand, I do agree with the goal of always trying to leave the code better than you found it -- better documented at least, to save yourself and others trouble later on. On the other other hand, when you're supporting multiple releases (as I am), figuring out which can/should be improved is messy. — Dec 5 '14 at 14:28
Code improvements should not alter functionality or API:s, so the effect on other teams will be minimal. There are techniques for localicing the changes, but thats a discussion for another forum. — Dec 5 '14 at 15:26
Fredrik: That's a great ideal. Unfortunately, when you have real customers out there, they may depend on behaviors which you didn't define as part of the official functionality; in large systems the same can happen accidentally internally. I absolutely agree that modularity should be the goal when you're implementing the code... but after it's been out in the field for a while you start to find yourself constrained in ways the modularity didn't protect you from, unless you're in a position to be able to say "we never promised that, don't do it" -- which can be hard to say to a huge customer. — Dec 5 '14 at 19:23

keshlam 41.5k1267144 · Answer 9 · 2014-12-05 03:10:16Z

Development engineering is, in large part, the art of deciding when something is "good enough." If you want it to be perfect, you're likely to be frustrated anywhere but research or academia.

What the company tells you to work on is the right thing to work on at that moment, I'm afraid. Sometimes that means doing a partial job when a complete solution would save a lot of future work, because available resources just don't allow doing everything immediately. Sometimes that means fixing things the ugly way rather than the right way because the ugly fix is "minimal" and considered lower risk.

You can try suggesting that they use a task tracking system (I could plug the one from IBM...) so it's clear what needs to be done, its size can be estimated, priorities can be assigned to it, and a reasonable conclusion drawn about whether the work can be contained with the staff they have or if they need to find a way to either simplify some of it, delay it, or bring more people in. But that usually requires convincing at least one manager or group leader to try it, demonstrating its value, and working outward from there.

Or you can wait until you're a team leader yourself and in a position to try to push this through.

Meanwhile... well, you can do a micro-version of this, maintaining a backlog list of the things assigned to you, with estimates of how many man-days each one will take, crossing things off and adding them as they're completed and assigned. That will at least give you a strong argument for telling your boss "Here's what you've already asked me to work on. If you want me to add something to the list, I can do so, but we need to agree on what its priority is relative to the others. They can't all be top priority."

+1. Two comments. (1) Even in academia, perfectionism won't work, because then you will never actually submit that paper, and at some point in time, you'll be out of a job. (2) Even team leaders can't push through what they like, since they face pressure from (product) management, sales, users etc. In life, you'll always need to compromise on something - the key is to do the best you can. — Dec 5 '14 at 7:16
There is a difference between shipping "good enough" and shipping something that just meets the immediate requirements but it is likely to cause a huge headache down the road. "Technical debt" refers to the later, I think. The right answer depends on whether the OP jsut wants to pretty up the code or spend extra time to build a solid architecture that will be much easier to extend and maintain in the future than a quick hack. — Dec 5 '14 at 13:53
We all hate it, but sometimes "we'll pay for it later" really is acceptable. ANY decent programmer wants to pretty up the code and architecture. Unfortunately (a) customers often want ABSOLUTELY MINIMAL CHANGES made until the next major release because they're afraid you'll break something (which is why I'm still stuck supporting some rather elderly code) and (b) sometimes getting something that works shipped now, while customers are ready to buy it, beats waiting for it to be cleaned up and losing them to a competitor. Track your technical debt and fix it in the next major release. — Dec 5 '14 at 14:14
(I should note that there are other approaches -- "continuous release", for example, as the open-source projects tend to run -- but unless the customers are willing to accept "first upgrade and let us know if that fixes the problem", that can be MORE expensive to support... and support is very expensive already. Tremendously aggravating, but it's a hard trap to get out of if you want major customers to trust you.) — Dec 5 '14 at 14:18
Perfection is in the eye of the beholder. You might think your class hierarchy is pure awesome sauce but the next guy (or even you in a year) might wonder if you were smoking crack when it was coded. Also, devs love solving specific problems in a generic way. This isn't always a good thing. — Dec 5 '14 at 15:00

user8365 · Answer 10 · 2014-12-05 13:27:47Z

There are signs of poor code that typically lead to technical debt. Your project may have many of them, but that's not the problem. You have to show how it is costing the company in the long-term.

I'm confrontted with technical debt from the past there is no
time/budget to pay the debt off.

Does this mean you don't have allocated time specifically assigned to clean it up or does it mean it takes longer to debug or modify the code because of the way it was previously built? You need to consider this in your estimates. When people ask why a fix/change will take so long, remind them how hastily it was originally build, so now it's not as easy to work with as it should be. This is where the debt is costing the company. if not, then you have no technical debt.

People and/or companies rarely change things if there are no consequences. It's great you recognize the technical debt, but you're not showing the problems it is creating for those decision makers. Hopefully, they'll hear you constantly having to delay things because of the poor quality of your current code base, that they may eventually suggest taking some time to do a better fix.

RemcoGerlich 3,4421018 · Answer 11 · 2014-12-05 09:20:42Z

Ask your manager what to do about it. Since you work in a software company, he should know what you're talking about, and have an opinion about what course he wants to take.

As cute as the term "technical debt" is, this is not something that has to be paid at some point, so it's slightly misleading. The fact is that existing code bases are always a bit hard to work with because you'd do always it differently if you could write it anew, but you have to work with what there already is. Sometimes the situation is much worse than other times, of course, and your manager probably knows what's up.

You, in the meantime, should always work using the Boy Scout Rule: leave the campsite cleaner than it was when you got there.

You can't clean up all the code, it's a massive investment of time that has no immediate business benefit and always takes much more time than you imagine, and you won't even be happy with the end result.

What you can do is 1) write your new code as good as you can (write tests, make it look nice, etc) and 2) clean up the code around it a little bit.

Just because technical debt doesn't have to be paid, doesn't make it a 'misleading' term. Monetary debt doesn't have to be paid either - a person (like a codebase, or a business) is free to die at any time... — Dec 5 '14 at 9:29
I said slightly misleading. You can write something that looks great to you today, and next year you'll be a better programmer and you'll think of that old cruft as technical debt. That you have improved hasn't decreased the value of the existing code, however. — Dec 5 '14 at 9:34

David 42929 · Answer 12 · 2014-12-05 14:58:32Z

It's commendable that you're concerned about technical debt. But I'd throw in a word of caution: at the end of the day, you're being paid to add value to the business, not to be an architecture astronaut. Sometimes adding value means accepting technical debt, at least in the short term.

That being said ...

As some of the other answers have suggested, you should quantify the cost of the technical debt. "I just spent a week fixing a bug related to poorly / hastily written code instead of adding new functionality; I know we all want to deliver value to the business, but this code base makes it really hard."

At the same time, you don't want to get a reputation for negativity ... so pick your battles. I'd suggest picking one or two architectural issues and getting buy-in to focus on those.

Try to find opportunities that align with an organizational objective. "I know upper management has shown interest in making our site more mobile-friendly; can we build in an extra day or two every time we touch one of the main pages to try and build in some responsiveness -- and do some refactoring?"

When a team really adopts / internalizes best practices -- as opposed to jumping through hoops to please the higher-ups -- that tends to happen from the bottom up. So lead by example. You could start by getting into the habit of writing some unit tests for new features you're working on, or to better define the conditions to reproduce a bug. (You won't get to a "good" level of test coverage overnight; don't worry about that -- 20% or even 10% test coverage of a feature is better than 0%.) Or pick some other best practice to adopt and hope it catches on.

Bottom line, this isn't an either/or. You need to provide short-term value to the organization and make sure you're still positioned to add value in the long term.

gnasher729 71.1k31131222 · Answer 13 · 2014-12-05 15:47:14Z

Practically every software development project has technical debt. Technical debt means that adding new features or fixing bugs will take longer than they would in a project without any technical debt. On the other hand, fixing technical debt also costs time. Fixing technical debt in an area where you don't know 100% sure that it will pay off is a bad idea. So you need to sell to your company the areas where it actually pays off.

A way that may very well work is to tell your boss that you would like to clean up an area where new development is happening anyway. There you can make the argument that some of the time spent on cleaning up will pay for itself by making the new development easier. And in the new development, spending some time cleaning it up immediately is very likely to pay for itself because there will be fewer bugs, and the bugs that you have will be easier to fix. Plus you will have a debt free area of code, which may (but only may) help in the future; if you can foresee that changes will be needed in the area, that is even better.

score 0 · Answer 14 · 2014-12-06 03:44:50Z

Limit the scope & quantify the impact

Technical debt only needs to be addressed to the extent it's risking the current or future health of the product. The aim is not to get to the "perfect codebase", but rather make improvements that have concretely make the product more operationally stable, easier to develop and maintain, and so on.

So instead of asking your manager for three weeks for some vaguely defined cleanup tasks, it would make your case a lot more concrete to also estimate the cost of living with the technical debt, and pitch it against the cost (time) to fix it.

The impact of technical debt could come in many forms: longer time to add features, more production issues, untestable code, high maintenance costs, fragility, etc. See what problems your codebase suffers from due to technical debt, and identify some specific cleanup tasks that would alleviate these.

Having some sort of measured impact can also prevent one from rabbit-trailing into code beautification that doesn't really pay off, and prevent a never-ending fix-everything-that's-wrong-with-the-world refactor project.

Coming up with focused cleanup tasks with high returns is not an easy task. If you think in the current state of the codebase it would take you some significant time to do this analysis, I would recommend approaching your manager with something like:

I think there are some cleanup tasks we can do in our codebase to significantly improve [stability / development speed / ...] in a fairly short time. I would like to take [amount of time] to look into this a bit further and come up with a cost / benefit analysis. What do you think?

Search This Blog

Iyfjky

Ask company to allow time/space to pay off technical debt [duplicate]

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

7 Answers
7

Limit the scope & quantify the impact

7 Answers
7

7 Answers
7

Limit the scope & quantify the impact

Limit the scope & quantify the impact

Limit the scope & quantify the impact

Limit the scope & quantify the impact

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

One-line joke

Category

Random preview

Ask company to allow time/space to pay off technical debt [duplicate]

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

marked as duplicate by gnat, Jan Doggen, Garrison Neely, IDrinkandIKnowThings, yochannah Dec 5 '14 at 17:10

7 Answers 7

Limit the scope & quantify the impact

7 Answers 7

7 Answers 7

Limit the scope & quantify the impact

Limit the scope & quantify the impact

Limit the scope & quantify the impact

Limit the scope & quantify the impact

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

One-line joke

7 Answers
7

7 Answers
7

7 Answers
7