• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Technical Debt vs Profitability

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Fernando Doglio,
Have you come across a situation where there is a need to  balance technical debt and doing what is necessary for the business. Business perspective can deviate from Developer perspective. Sometimes it is very difficult to get a buy-in for technical projects which may NOT be profitable to the business directly. What are your thoughts on that? How does software skills help here?
 
Author
Posts: 17
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Anantha, thanks for the great question.

Yes, in my almost 20 years of experience working for consulting companies I'm sad to say I've seen this scenario play many times. On one side you have the technical team trying to solve problems that they know will harm the project down the line and on the other side, you have the business looking at today's numbers and only caring about the immediate results.
As you can problably imagine, there is no easy way to solve this, it all depends on many factors:
- does this tech debt have a clear implication in the near future of your project? Can you prove that if you don't fix it now you'll run into a bigger problem in the future?
- Does your client have a basic (at least) technical background which you can leverage to explain the tech debt?
- can you quantify the amount of effort and time required to fix the tech debt?

If you can answer these questions, you might have a chance to get a green light on fixing the problem, but keep in mind that whatever your scenario might be, if you go to your business saying "there is tech debt and we need to fix it" you'll lose. You will have to be prepared to answer the following questions:

1. How long will it take you?
2. How many people will you need?
3. What impact will it have on the system? (will it run faster? will it scale easier? etc)
4. What's the proposed timeline.

That will let me weigh pros and const and decide, otherwise they'll keep moving forward.

Please let me know if this answered your question or of you still have more doubts ,don't hesitate to post them in this thread!

Anantha Ramu wrote:Hello Fernando Doglio,
Have you come across a situation where there is a need to  balance technical debt and doing what is necessary for the business. Business perspective can deviate from Developer perspective. Sometimes it is very difficult to get a buy-in for technical projects which may NOT be profitable to the business directly. What are your thoughts on that? How does software skills help here?

 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Technical debt is everywhere - we're trying to clear some from the Ranch software itself, in fact!

I've often said that software rots from the outside in, not the inside out. Management often thinks that once a system has been created, it should run forever, but like so many "shoulds", this is a dangerous misconception. Changes in hardware, OS, external connections such as databases, all of these mutate over time and if a system doesn't adapt to these mutations then eventually it may degrade or fail catastrophically.

As auto mechanics like to say, "You can pay now or you can pay later". And later usually requires a lot more work and expense. Probably exponentially so.

On the other hand, constant fiddling isn't a good idea either. There's a middle ground between wasting time polishing the friggets and showing up on the from page of the New York Times. So wise management should monitor constantly so as to be able to plan and co-ordinate intelligently.

That, of course assumes a dedication to an ongoing business model. Aside from greedy executives who focus on quarterly numbers to the detriment of the future, sometimes debt is allowed to accrue because everyone who would be held responsible plans to have bailed on the company by the time things go really sour. Or the plan may call for the total dismantling of the company, so why bother?

In many cases, there's "newer, better" replacement system planned so the idea (or more realistically, the hope) is that everyone will be on the new system before the old one collapses. Spoiler: very often this ends up not being the case and they end up having to run both systems at once indefinitely or even abandon the new system and revert the now-crumbling old one.
 
Saloon Keeper
Posts: 7585
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paraphrased from a talk by Kent Beck: "Pretend that the money spent on your current project is your own - that'll focus the mind on documentation."

So yes, there can be business reasons to allow technical debt to accrue in the short term. That's not a good strategy in the long run, of course.
 
I hired a bunch of ninjas. The fridge is empty, but I can't find them to tell them the mission.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic