SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Dealing with Technical Debt


Dealing with Technical Debt

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (682K reputation)SSC Guru (682K reputation)SSC Guru (682K reputation)SSC Guru (682K reputation)SSC Guru (682K reputation)SSC Guru (682K reputation)SSC Guru (682K reputation)SSC Guru (682K reputation)

Group: Administrators
Points: 682134 Visits: 21588
Comments posted to this topic are about the item Dealing with Technical Debt

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
nitinbhojwani
nitinbhojwani
SSCommitted
SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)SSCommitted (2K reputation)

Group: General Forum Members
Points: 1954 Visits: 672

Very interesting topic. Just like most of the backend stuff, Technical debt is also quite abstract and hard to measure.
I do like the idea of using a measurement system for all Technical Debt. Unfortunately, we don't have any.
In our firm, it is usually reviewed (or paid off) for a particular module/application when there is an enhancement required or an upgrade planned.


DinoRS
DinoRS
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1781 Visits: 823
I (as I'm the only one here doing BI things) have a very basic measurement about Technical Debt:
Once existing applications exceed their target runtime, it's time to revisit the SSIS Package and make it better. Usually for me these packages have been existing for years and when I have to re-visit them I start asking the usual questions like "Do we really need to store a Date as Int?" Once I get a "no" for something like that, my work starts on the package.
In the last 8 Months I've reduced daily run times by a total of 9 hours but almost nothing new I've done, import 2 flat files and make a simple fact table.

Next up for me will most likely be upgrade SSIS 2012 -> 2017 with everything that goes along with that, upgrade Package model, check if Performance is viable and such.

I feel like all I'm doing is having the customer pay for their technical debt.
Rod
Rod
SSC-Dedicated
SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)

Group: General Forum Members
Points: 32467 Visits: 2887
I appreciate this article Steve and the one you linked to. Actually assigning some measure to technical debt is a great idea.

I've considered the technical debt I've added to the software I've written here. I'd say it's between 10% to 15%. That's not so much because I'm just a brilliant developer, its more because at least half of what I do is maintain something that someone else wrote 10 or more years ago. And there are very serious consequences for modifying code without first getting permission, which is hard to get.

I think you touched upon something related when you spoke about how an organization could measure their technical debt. I'm referring to doing code reviews. Not directly addressing technical debt, but certainly related to it. We don't do any code reviews here. In fairness to where I work now, I'll say that of all the places I've worked, none of them have been open to doing code reviews.

Kindest Regards,Rod
Connect with me on LinkedIn.
Bryant McClellan
Bryant McClellan
Hall of Fame
Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)Hall of Fame (4K reputation)

Group: General Forum Members
Points: 3995 Visits: 612
I was surprised at the amount of debt they calculated. It translated to about $4600 which is 70-80 hours of work @ $65/hour. I think it was underestimated but calculating value in this way makes it very easy to understand the impact.

He was also primarily focused on old debt. Unless we calculate the future value of debt we are presently incurring we will have a very incomplete picture. That said, if we could value new debt incurred in current projects we would have a more realistic way of explaining the true cost of an application.

------------
Buy the ticket, take the ride. -- Hunter S. Thompson
jonathan.crawford
jonathan.crawford
SSCertifiable
SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)

Group: General Forum Members
Points: 5914 Visits: 1635
What is the difference between this metric and unit testing? In other words, if you're just refactoring because you can, and the basic functionality you need from it still works, then is that time well spent? If it's truly broken then shouldn't your testing reveal that?

-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
Rod
Rod
SSC-Dedicated
SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)

Group: General Forum Members
Points: 32467 Visits: 2887
jonathan.crawford - Tuesday, March 12, 2019 10:05 AM
What is the difference between this metric and unit testing? In other words, if you're just refactoring because you can, and the basic functionality you need from it still works, then is that time well spent? If it's truly broken then shouldn't your testing reveal that?


I am not familiar with metric testing, so I can't answer your first question. My bad.

Concerning refactoring, I see value in doing it, especially if it is results in the code doing exactly what it should be doing as before. If someone just refactors so they can pass the time, then I'd agree that's a waste of time and effort. But one of the goals of refactoring code is to make it adhere more to the SOLID principles. For example, I've seen lots of code in which a module is meant to do one thing, but when you look through the code you see that it's doing half a dozen or more things, as it accomplishes doing that one thing. That violates the "S" in SOLID (Single Responsibility Principle). So refactoring code like that will leave you with routines which do the one thing they're supposed to do and that one thing is only done by one routine, rather than being done by several routines scattered throughout the code.

Kindest Regards,Rod
Connect with me on LinkedIn.
RonKyle
RonKyle
SSC-Dedicated
SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)

Group: General Forum Members
Points: 30033 Visits: 4649
All this very thought provoking. We've all experienced it, but now there's a name for it.



jonathan.crawford
jonathan.crawford
SSCertifiable
SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)

Group: General Forum Members
Points: 5914 Visits: 1635
Rod at work - Tuesday, March 12, 2019 10:41 AM
jonathan.crawford - Tuesday, March 12, 2019 10:05 AM
What is the difference between this metric and unit testing? In other words, if you're just refactoring because you can, and the basic functionality you need from it still works, then is that time well spent? If it's truly broken then shouldn't your testing reveal that?


I am not familiar with metric testing, so I can't answer your first question. My bad.

Concerning refactoring, I see value in doing it, especially if it is results in the code doing exactly what it should be doing as before. If someone just refactors so they can pass the time, then I'd agree that's a waste of time and effort. But one of the goals of refactoring code is to make it adhere more to the SOLID principles. For example, I've seen lots of code in which a module is meant to do one thing, but when you look through the code you see that it's doing half a dozen or more things, as it accomplishes doing that one thing. That violates the "S" in SOLID (Single Responsibility Principle). So refactoring code like that will leave you with routines which do the one thing they're supposed to do and that one thing is only done by one routine, rather than being done by several routines scattered throughout the code.


"this metric" = technical debt. I was just wondering if there was really any value in trying to decide somewhat subjectively how "bad" existing code is, when you could use the mechanism of unit tests to determine if something was doing its job. Over time, as all the other unit tests are passing, you could add in things for quality checks like SOLID

-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (975K reputation)SSC Guru (975K reputation)SSC Guru (975K reputation)SSC Guru (975K reputation)SSC Guru (975K reputation)SSC Guru (975K reputation)SSC Guru (975K reputation)SSC Guru (975K reputation)

Group: General Forum Members
Points: 975134 Visits: 49307

From the article:

Just like financial debt, not all technical debt is bad.

Actually, it's bad on both counts. You always end up paying much more in the end.

From the article:

Sometimes debt lets us get more things done sooner than we might otherwise be able to do. We do need to take shortcuts at time in development to get a prototype working, or deliver a feature or meet some other goal.

It's that very "justification" that is the primary cause of technical debt and the eventual "Death by a Thousand Cuts" of a database. No one considers how much such an inexcusable justification is going to cost down the line because the folks that justify the technical debt for such reasons are normally long gone when the time comes to pay the debt, which normally manifests itself in major performance issues. That also means that those same people never learn the horrors of such technical debt and carry that same poison to the next job, and the next job, wash, rinse, and repeat.

It takes so little to actually do things the right way. Don't fall prey to the ridiculous "it's ok this time" mentality or "we have a schedule to meet" mentality. If you don't do it right the first time then, just like compound interest, you'll pay many times more trying to fix the problem (and no one fixes technical dept until it becomes a problem) including, perhaps, the loss of reputation in the eyes of the customer and future customers because bad news travels faster than the elevator someone is travelling in or the golf ball they just power to the hole.

To put it more bluntly, it's never ok to feed the baby a turd so stop trying to justify it.


--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

When you put the right degree of spin on it, the number 318 is also a glyph that describes the nature of a DBAs job. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum









































































































































































SQLServerCentral


Search