March 13, 2019 at 7:30 am
I definitely am with Jeff, too. My customer is willing to accept (in my opinion) quite a lot of debt as long as things run smoothly. We've been through a "unusable" scenario by now which we didn't have to if the customer would've listened to me.
I'm with Jeff on this one. As an intellectual construct tech debt sounds plausible
We are probably all with Jeff, but it can only be to a point. Things do have to get done in a timely manner, and sometimes a partial solution is better than a complete solution. We don't all even agree on exactly what a "complete" solution might look like. I just find in reality there are competing interests and views. Sometimes I can convince others and sometimes I can't. Sometimes when I can't, my concerns show up. But that is just a part of life at work.
March 13, 2019 at 8:42 am
I would advocate that some debt is good because this does meet a timeline or a milestone that's required. While we would all like to be expert coders, we aren't always, and certainly not at different times in a career. If Jeff worked at Redgate, he couldn't code everything, and some other developers would be learning skills, while writing some subpar, or maybe less desirable code.
I've had legal requirements or other situations where code needed to get finished. Promotions or campaigns or even sales promises sometimes need to be met, and that does cause issues with the work we do. This happens in other industries as well, so we get subpar buildings, bridges, medical care, etc.
Paying back the debt is hard, often because there isn't a quantification. I've walked into projects where sections of code "couldn't be touched" because there was such a mess that any work would invoke that payback and overwhelm a project. I'd argue that's exactly what we should do, and some companies do that, but far too few. More likely we limp along and then rewrite everything from scratch years later.
Quantifying debt is more a way of noting that we've made poor decisions for some reason. Now we know how many we're making, in some sense, and can decide if we should pay some back. I've had success with some refactoring and payback in a few places, but a lack of success in many more. There isn't time, or often even skill, to fix everything from the beginning. We don't have enough developers trained to be great, and the target for great keeps moving a bit, though not as fast as many would claim. We could be better, but not enough people advocate for better and just get through each day at their jobs.
Perhaps we also might not agree on what "better" and certainly not "best" are.
Jeff might like Redgate, however, as we often take a spring every 6 or 7 and try to pay down tech debt. It sometimes annoys me because new work stops, but I do appreciate that we've learned that a poor codebase does become an issue over time.
March 13, 2019 at 9:14 am
jonathan.crawford - Tuesday, March 12, 2019 11:24 AM"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
Ah, thank you, Jonathan, for defining the term "metric".
In our case here, we have a lot of technical debt for which we cannot even use unit tests. We have a surprisingly large amount of applications written in Microsoft Access (Access apps) and embedded in Excel spreadsheets. I know of no unit test frameworks for either of those.
Kindest Regards, Rod Connect with me on LinkedIn.
March 13, 2019 at 9:31 am
Rod at work - Wednesday, March 13, 2019 9:14 AMAh, thank you, Jonathan, for defining the term "metric".
In our case here, we have a lot of technical debt for which we cannot even use unit tests. We have a surprisingly large amount of applications written in Microsoft Access (Access apps) and embedded in Excel spreadsheets. I know of no unit test frameworks for either of those.
Good point..
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
March 13, 2019 at 9:56 am
RonKyle - Wednesday, March 13, 2019 7:30 AMWe are probably all with Jeff, but it can only be to a point. Things do have to get done in a timely manner, and sometimes a partial solution is better than a complete solution. We don't all even agree on exactly what a "complete" solution might look like. I just find in reality there are competing interests and views. Sometimes I can convince others and sometimes I can't. Sometimes when I can't, my concerns show up. But that is just a part of life at work.
You don't last long in IT without embracing pragmatism and a reasonable amount of C'est la vie.
The nasty side of tech debt is when the progenitors move on or up and another team have to keep the ostrich flying. Beyond a certain point a system requires so much hands on that the time to do anything other than keep it going vanishes. No time to train or devote to more productive uses of time. Couple that with a remote and disconnected management and a team is perceived as being outmoded and adding little or no value. Both the system and the team get deprecated. Not nice
March 13, 2019 at 11:13 am
David.Poole - Wednesday, March 13, 2019 9:56 AMRonKyle - Wednesday, March 13, 2019 7:30 AMWe are probably all with Jeff, but it can only be to a point. Things do have to get done in a timely manner, and sometimes a partial solution is better than a complete solution. We don't all even agree on exactly what a "complete" solution might look like. I just find in reality there are competing interests and views. Sometimes I can convince others and sometimes I can't. Sometimes when I can't, my concerns show up. But that is just a part of life at work.You don't last long in IT without embracing pragmatism and a reasonable amount of C'est la vie.
The nasty side of tech debt is when the progenitors move on or up and another team have to keep the ostrich flying. Beyond a certain point a system requires so much hands on that the time to do anything other than keep it going vanishes. No time to train or devote to more productive uses of time. Couple that with a remote and disconnected management and a team is perceived as being outmoded and adding little or no value. Both the system and the team get deprecated. Not nice
There still fundamentally has to be a clear definition of technical debt versus "I personally don't like how this is written/ performs". At least from the lessons learned here, it's been best to keep the definition limited but rather tight, so that there's no dispute as to what technical debt really is. For us it's become ANY violation of our (short) list of IT standards that have been vetted and approved by those same business leaders.
I know some of our "speed demon" friends here will likely object to the followup, but there really is a business concept of "fast enough". In short - simply because a query that used to take 2 ms "balloons out" to 20sec doesn't by itself turn that into tech debt. So we worked with our business partners to define what "good enough' was, and we use those metrics and the productivity drops that would result as justification and valuation of the debt.. That does mean that some of our overnight batch jobs still perform less than ideally (if the job isn't blocking anything else or causing some other business harm, it's not good, but also it's not "debt"), but it has helped to bring in a lot to the other badly performing items
Same thing with Dino's previously mentioned upgrade: simply choosing to not install the very latest SSRS platform isn't technical debt per se. Unless there's security hole, confidential data in the open, or some other substantial issue that can trace back to a drop in productivity, company liability potential etc... it's probably best not to refer to that as "debt". From our little view of the world technical debt you can live with "isn't " debt: trying to convey all of those nuances up to those who have to pay for it is hard enough for the obvious ones, so we avoid letting them associate the debt we can tolerate with the stuff we can't.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 13, 2019 at 2:16 pm
David.Poole - Wednesday, March 13, 2019 9:56 AMRonKyle - Wednesday, March 13, 2019 7:30 AMWe are probably all with Jeff, but it can only be to a point. Things do have to get done in a timely manner, and sometimes a partial solution is better than a complete solution. We don't all even agree on exactly what a "complete" solution might look like. I just find in reality there are competing interests and views. Sometimes I can convince others and sometimes I can't. Sometimes when I can't, my concerns show up. But that is just a part of life at work.You don't last long in IT without embracing pragmatism and a reasonable amount of C'est la vie.
The nasty side of tech debt is when the progenitors move on or up and another team have to keep the ostrich flying. Beyond a certain point a system requires so much hands on that the time to do anything other than keep it going vanishes. No time to train or devote to more productive uses of time. Couple that with a remote and disconnected management and a team is perceived as being outmoded and adding little or no value. Both the system and the team get deprecated. Not nice
Why do so many people think that "doing it right" is at odds with pragmatism? THAT's a major part of the problem!
--Jeff Moden
Change is inevitable... Change for the better is not.
March 13, 2019 at 2:21 pm
Why do so many people think that "doing it right" is at odds with pragmatism? THAT's a major part of the problem!
Nobody said that. Sometimes there is a need to get something done with a less than "perfect" solution. Add to that even among ourselves, we would disagree as to what constitutes the "perfect" solution. As a professional, you give your best advice, and then you do as you're told.
March 13, 2019 at 2:51 pm
RonKyle - Wednesday, March 13, 2019 7:30 AMWe are probably all with Jeff, but it can only be to a point. Things do have to get done in a timely manner, and sometimes a partial solution is better than a complete solution. We don't all even agree on exactly what a "complete" solution might look like. I just find in reality there are competing interests and views. Sometimes I can convince others and sometimes I can't. Sometimes when I can't, my concerns show up. But that is just a part of life at work.
We make decisions when we produce code based on constraints (time usually), but we (always try to) make the best decisions based on the constraints. Therefore, our code is probably never perfect. Is imperfect code technical debt? Is code written by the developer who left 6 months ago automatically technical debt? I don't think talking to "the business" about technical debt is a good idea. (I am stealing this example from a podcast: https://therabbithole.libsyn.com/stop-talking-about-tech-debt-with-dane-oconner). Imagine you are building a house and the contractor says they did not have time to build the interior walls correctly, but next time the are in to work on our house they will fix things up. But don't worry, your house will likely not collapse in the meantime... We need to be aware that too much talk about technical debt may make us look incompetent or negligent or both.
Having ranted against talking about technical debt, incomplete/half-assed/ugly/scary code exists in our production environment. We TRY to tackle technical debt whenever we encounter it...we try ti leave the code better than how we found it every time.
March 13, 2019 at 2:57 pm
Jeff Moden - Wednesday, March 13, 2019 2:16 PMDavid.Poole - Wednesday, March 13, 2019 9:56 AMRonKyle - Wednesday, March 13, 2019 7:30 AMWe are probably all with Jeff, but it can only be to a point. Things do have to get done in a timely manner, and sometimes a partial solution is better than a complete solution. We don't all even agree on exactly what a "complete" solution might look like. I just find in reality there are competing interests and views. Sometimes I can convince others and sometimes I can't. Sometimes when I can't, my concerns show up. But that is just a part of life at work.You don't last long in IT without embracing pragmatism and a reasonable amount of C'est la vie.
The nasty side of tech debt is when the progenitors move on or up and another team have to keep the ostrich flying. Beyond a certain point a system requires so much hands on that the time to do anything other than keep it going vanishes. No time to train or devote to more productive uses of time. Couple that with a remote and disconnected management and a team is perceived as being outmoded and adding little or no value. Both the system and the team get deprecated. Not niceWhy do so many people think that "doing it right" is at odds with pragmatism? THAT's a major part of the problem!
To paraphrase one of my favorite Modinisms...
1) Make it correct... 2) Make it fast... 3) Make it pretty... You're not done until you've done all 3.
All too often "pragmatism" equates to calling it quits after #1... 🙁
March 13, 2019 at 3:01 pm
To paraphrase one of my favorite Modinisms...
1) Make it correct... 2) Make it fast... 3) Make it pretty... You're not done until you've done all 3.
I told my children many times growing up that "Family comes first, but not always." Here I would say "Do it correctly comes first, but not always." I hear your comment about pragmatism too often equates to calling it quits. That's the same reaction I have to the word "denormalization." There are times denormalization is necessary, but they are uncommon and in my view used too often by those who do not either understand or care to apply the rigor normalization requires.
March 13, 2019 at 3:14 pm
RonKyle - Wednesday, March 13, 2019 3:01 PMTo paraphrase one of my favorite Modinisms...
1) Make it correct... 2) Make it fast... 3) Make it pretty... You're not done until you've done all 3.I told my children many times growing up that "Family comes first, but not always." Here I would say "Do it correctly comes first, but not always." I hear your comment about pragmatism too often equates to calling it quits. That's the same reaction I have to the word "denormalization." There are times denormalization is necessary, but they are uncommon and in my view used too often by those who do not either understand or care to apply the rigor normalization requires.
100% Agreed... If I've said it once, I've said it a thousand times, "denormalization <> failure to normalize".
"Denormalization" implies that it was once fully normalized, tested and then, for performance reasons, flattened out... Please show me the the original, fully normalized, version, a description of your test procedures and objective test results... <the sound of crickets chirping in the background>
March 13, 2019 at 5:57 pm
RonKyle - Wednesday, March 13, 2019 2:21 PMWhy do so many people think that "doing it right" is at odds with pragmatism? THAT's a major part of the problem!
Nobody said that. Sometimes there is a need to get something done with a less than "perfect" solution. Add to that even among ourselves, we would disagree as to what constitutes the "perfect" solution. As a professional, you give your best advice, and then you do as you're told.
Heh... I did. 😉 You said that sometimes you need to be "pragmatic". That seems to say that being pragmatic trumps doing it right. My take is, you can do both.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 13, 2019 at 6:45 pm
Jeff Moden - Wednesday, March 13, 2019 5:57 PMRonKyle - Wednesday, March 13, 2019 2:21 PMWhy do so many people think that "doing it right" is at odds with pragmatism? THAT's a major part of the problem!
Nobody said that. Sometimes there is a need to get something done with a less than "perfect" solution. Add to that even among ourselves, we would disagree as to what constitutes the "perfect" solution. As a professional, you give your best advice, and then you do as you're told.
Heh... I did. 😉 You said that sometimes you need to be "pragmatic". That seems to say that being pragmatic trumps doing it right. My take is, you can do both.
I would agree, that said in some cases - doing it right might take a lot longer to move into place. You first have to win over the hearts and minds, and not burn out your welcome while you're slaying said hearts and winning said minds. We've had to spend a few years showing that our technical debt actually has very real costs and liabilities if ignored, and while it's frustrating as hell to eat crow or choke down some of the half baked solutions you KNOW will blow up in no time, in time, people start remembering the feedback. Just as you yourself have said, when that happens those who do recall our feedback will be much more likely to recall and incorporate our suggestions if they don't come with a large dish of " I told you so" or " we could have avoided that mess".
Like if or not - we have to get funded if we hope to do anything, right or wrong. Doing it right first time out comes over time, often after many rounds of having to do it wrong first then fixing what breaks.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 14, 2019 at 7:15 am
Matt Miller (4) - Wednesday, March 13, 2019 6:45 PMLike if or not - we have to get funded if we hope to do anything, right or wrong. Doing it right first time out comes over time, often after many rounds of having to do it wrong first then fixing what breaks.
This is very true.
Those of us in large organization and limited resources don't always have the luxury of doing it the way we want the first time around. Normally, after something shows attraction to the business, then it's rebuilt the right way. It sucks, but tech is so expensive in the first place.
Viewing 15 posts - 16 through 30 (of 47 total)
You must be logged in to reply to this topic. Login to reply