March 14, 2019 at 8:02 am
Matt Miller (4) - Wednesday, March 13, 2019 11:13 AM
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.
Well if your organization is large enough, old enough platforms turn into real technical debt. With my customer all SQL 2008 & R2 have to have their sundown by end of march according to organization software LifeCycle policies.
So if the head of organization defines the sundown (which is done early in advance, usually when new versions get approved you have an updated cycle showing the sundown period) and you humble along until 3 months ahead of sundown, this is another technical debt as usually it will lock a lot of resources "out of a sudden" from doing something on someone's else roadmap. Stalling that roadmap I would consider another technical debt, if and when you might catch up on sprints and the such afterwards, is highly questionable.
Asides that: When your paid software is way past EOL (like Win 2008 / SQL 2008) I see it defaulting to "security hole" wether it is at the point of time you're looking at it yet or not, someone will find a bug, question is just when.
On a side note: just recently the customer within this organization approached me and was like "oh, we have this new VM with Win16, install SQL2014 Ent. right?" and I was like "oh well, why 2014?" and he said "that's our standard, isn't it?" An hour searching later we had proof that organizational standard as of right now is SQL2017. In the end we did install SQL Server 2017 Standard because 2 Cores and 8 GB RAM should tell most of the story anyways. My result of this discovery was to create an updated SQL Server Installation Blueprint for 2017 as this wasn't in place here either.
My point here would be: OK we do have SQL2014 Support and no Sundown yet, though the application would run on 2017 I still see a 2014 install as future debt, it'll require an earlier migration than the VM with SQL2017 installed which will bind resources in the future earlier for this than something else.
You probably hardly can measure if the resources will be cheaper when 2014 sundown is or 2017 but if you have mid term release cycle plans, they might see an direct impact from this earlier than might be desired at that point.
All of this does not count in the work that has to be done when a new Cardinality Engine is in place, just imagine 2008 R2 was fine, with some modifications your 2014 setup performs more or less the same but whatever changed with (by then SQL 2020 or something like this) SQL 2017 just requires much more time to make it work again, would you like to make it work on 2014 first and then on 2017 again with the expected targets? I rather spend time doing something new than grave digging the old packages over and over again every or second year. Sure you could argue you keep a job that way, at least for a while.
If I tell my customer something like "why 2014?" I'm basically trying to offer him avoiding technical debt, in the end the customer get's what he pays for:
- Bad Data Sources? Sure throw enough resources at it to cope with it, don't expect to be able to run it cheaply on AWS and the such.
- Bad Data Type Decisions? Same answer as first, with an addition: Want nvarchar everything? Accenture is the route to go for ya!
Once I've informed the customer about what I see from my perspective, the show is whatever the customer decided.
March 14, 2019 at 8:35 am
Matt Miller (4) - Wednesday, March 13, 2019 6:45 PMI 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.
You both (Jeff and you) are missing that part where you have the knowledge to do it right, or better. Often there are inexperienced people that don't have enough knowledge, but learn later. Changing code once it's in place is hard.
We all have a path in our knowledge, and it's not the same or equal for everyone.
March 14, 2019 at 9:33 am
Steve Jones - SSC Editor - Thursday, March 14, 2019 8:35 AMMatt Miller (4) - Wednesday, March 13, 2019 6:45 PMI 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.
You both (Jeff and you) are missing that part where you have the knowledge to do it right, or better. Often there are inexperienced people that don't have enough knowledge, but learn later. Changing code once it's in place is hard.
We all have a path in our knowledge, and it's not the same or equal for everyone.
Heh... no... I'm not missing that point at all. THAT, good Sir, is actually my whole bloody point! 😀 I'm glad that someone finally recognized what I'm trying to get at!
First, too many managers, experienced or other wise, don't know what the people they hired don't know and can't do a bloody thing about it because they are the ones that hired people that also don't know what they don't know but absolutely NEED to know in order to be able to do the job correctly (right the first time quickly, accurately, and with scalability/performance in mind).
Then you have the 9-to5 flavor of coders that have the attitude that know enough to get the job done because they don't actually know what they don't know. These people aren't necessarily "in-experienced" either. Some of them also have the piss-poor attitude that if they need to learn to do something or do something better, they 1) think the employer should tell them (but can't because they don't know what they don't know either) or 2) that the employer should pay them to learn how to do the job that their resume said they could do or 3) just flat out have a "I just need to get it off my plate" piece-work DILLIGAF attitude.
Managers need to learn that they must empower people to quickly do it right the first time (but don't because they're DILLIGAFs that also won't take the time to learn what they don't know) and to take great pride in it. In the absence of such motivational and helpful leadership, individuals should empower themselves to do so but won't because of the reasons I previously stated.
If you don't think this is true, then look at most of the questions on this and other forums and realize that most of these people where hired into known positions with known requirements and still don't know even some of the most basic of tasks and have such a DILLIGAF attitude that they won't even try a "Yabingooglehoo" before they ask.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 14, 2019 at 10:09 am
Once you are in a senior position your role is to develop the team, not the software.
The individuals with a poor attitude are far more rare than their impact would suggest. I do see poor culture and organisation that provides a breeding ground for practises generating tech debt.
Once it goes live and is delivering something to the organisation people tend not to like interruptions in service. "It works why do you want to stop it and why should I care"?
Team structure and empowerment helps here. If a team can own an end-to-end product then the team feel the pain of the technical debt, gain an understanding of it and are keen to address it. If teams are siloed along functional boundaries then as long as it mechanically functions it becomes the downstream teams problem. It doesn't cause a problem within the area of responsibility for the siloed team. The downstream team have to convince people that something is a problem of sufficient magnitude that it stands a chance of being prioritised in the battle for resources.
I think that people in more senior positions have to focus more on staff development so juniors learn the correct way of doing things. I find that staff development is somewhat of an after thought with all the focus going on technical stuff rather than people and process.
March 14, 2019 at 11:39 am
There are definitely issues with management, but there is also time involved to get people to learn to be better. That is something that should happen, but it can't happen on day 1. No organization I know of is also willing to sit a new hire down for days or weeks to learn to be better until they start writing production code.
Plenty of organizations also need to hire people, which can be hard to do. Some hold out, but some need bodies to get work done, and that's understandable. Some of those bodies will write poor code as they learn and grow, and some senior people will help them learn, but it's always a challenge.
It would be great to do everything right the first time, or at least do most things right, but many of us don't agree on right in every case, so it's not really a reality. We should strive to be better, but not everyone does and that's also reality. We don't get to hire just the stars or even the "I want to be a star". There are people that work 9 to 5, in this industry and every other one.
March 14, 2019 at 1:55 pm
My company has started to look beyond graduates and into schools. Doing this means we accept that a heavier commitment to training. A great deal of effort is going in to partnering with Princes Trust, and working out how to make tech jobs appeal to women. We are certainly not alone in doing this in the Manchester UK region. There is a hard headed reason for this. Technology touches eveything in today's world . The challenges posed by such a diverse audience are not going to be met by a culturally limited IT department. The challenge is to change the culture and mindset permanently. You cannot achieve such a change by putting "We are an equal opportunity employer" on an advert and hoping for the best.
And you know what? It's hard work but the most fun I've had in ages. As Terry Pratchett wrote "It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done". That's what we get from school leavers
March 14, 2019 at 9:26 pm
Steve Jones - SSC Editor - Thursday, March 14, 2019 11:39 AMThere are definitely issues with management, but there is also time involved to get people to learn to be better. That is something that should happen, but it can't happen on day 1. No organization I know of is also willing to sit a new hire down for days or weeks to learn to be better until they start writing production code.Plenty of organizations also need to hire people, which can be hard to do. Some hold out, but some need bodies to get work done, and that's understandable. Some of those bodies will write poor code as they learn and grow, and some senior people will help them learn, but it's always a challenge.
It would be great to do everything right the first time, or at least do most things right, but many of us don't agree on right in every case, so it's not really a reality. We should strive to be better, but not everyone does and that's also reality. We don't get to hire just the stars or even the "I want to be a star". There are people that work 9 to 5, in this industry and every other one.
I get that but when you hire someone that claims 10 years of experience and you're hiring for a senior position, there should be little excuse for not doing it right the first time but the company won't actually know that they're going to have a problem because, thanks to Microsoft Marketing, everyone and their brother think they know SQL Server and, especially, T-SQL because they can actually do an INNER JOIN based on more than one column.
And, yes.... it absolutely does take time to get people to learn better but a whole lot of companies simply don't make that investment because they supposedly hired only senior people. Remember my question about how to get the current date and time using T-SQL and how I quite counting after 20 out of 22 people couldn't answer the question? Remember also that they all claimed senior experience on the resume and job history and that they supposed got that experience while working at another company.
People keep saying that their code is "good enough" but how the hell would they know? They're a part of the group that fail the current date and time question.
And I'm not talking about people needing to become rock stars but I am talking about people with more than 5 years of experience not even knowing the bloody basics.
There's something really broken out there if "Good enough" has become the standard because "Good enough" usually isn't and few have to foresight to understand that rework costs 8 times or more than simply doing it right the first time.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 14, 2019 at 11:15 pm
It's often hard to do it right the first time. A lot of the large projects I've worked on where hundred million dollar online video games where getting it right the first time meant you are trying to plan out the 5-year development plan to perfection. Good luck with that! 😀
March 15, 2019 at 7:40 am
Steve Jones - SSC Editor - Thursday, March 14, 2019 8:35 AMMatt Miller (4) - Wednesday, March 13, 2019 6:45 PMI 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.
You both (Jeff and you) are missing that part where you have the knowledge to do it right, or better. Often there are inexperienced people that don't have enough knowledge, but learn later. Changing code once it's in place is hard.
We all have a path in our knowledge, and it's not the same or equal for everyone.
Sorry for the pause there - I am actively involved with trying to retire some of said technical debt as we speak, so this is highly relevant here.😛
I get to live daily the part where changing code that's made it through is hard to change. I unfortunately don't have control over the skillsets of the folks doing the coding or over the latter stages of our deployment cycles, so I try to put my influence to use in avoidance when possible: in the early design phases, training, reference materials, patterns and standards. Failing that - issues often gravitate my way once they've started to fester which gives us another chance to hopefully get it right.
That said - I was simply trying to provide how we define and manage our technical debt levels, which once incurred does require all of those coordination points in business, IT leadership and PM, etc... It purposefully is a somewhat narrower definition, but it at least does have the merit of being an "easy" definition, so we no longer have to haggle over those pieces. As we find new issues or spots we may institute new standards which then bring that new issues under the umbrella.
----------------------------------------------------------------------------------
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 15, 2019 at 9:36 am
David.Poole - Thursday, March 14, 2019 1:55 PMMy company has started to look beyond graduates and into schools. Doing this means we accept that a heavier commitment to training. A great deal of effort is going in to partnering with Princes Trust, and working out how to make tech jobs appeal to women. We are certainly not alone in doing this in the Manchester UK region. There is a hard headed reason for this. Technology touches eveything in today's world . The challenges posed by such a diverse audience are not going to be met by a culturally limited IT department. The challenge is to change the culture and mindset permanently. You cannot achieve such a change by putting "We are an equal opportunity employer" on an advert and hoping for the best.
And you know what? It's hard work but the most fun I've had in ages. As Terry Pratchett wrote "It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done". That's what we get from school leavers
Glad to hear it. That's a good, positive approach.
March 15, 2019 at 9:39 am
Jeff Moden - Thursday, March 14, 2019 9:26 PMI get that but when you hire someone that claims 10 years of experience and you're hiring for a senior position, there should be little excuse for not doing it right the first time but the company won't actually know that they're going to have a problem because, thanks to Microsoft Marketing, everyone and their brother think they know SQL Server and, especially, T-SQL because they can actually do an INNER JOIN based on more than one column.
And, yes.... it absolutely does take time to get people to learn better but a whole lot of companies simply don't make that investment because they supposedly hired only senior people. Remember my question about how to get the current date and time using T-SQL and how I quite counting after 20 out of 22 people couldn't answer the question? Remember also that they all claimed senior experience on the resume and job history and that they supposed got that experience while working at another company.
People keep saying that their code is "good enough" but how the hell would they know? They're a part of the group that fail the current date and time question.
And I'm not talking about people needing to become rock stars but I am talking about people with more than 5 years of experience not even knowing the bloody basics.
There's something really broken out there if "Good enough" has become the standard because "Good enough" usually isn't and few have to foresight to understand that rework costs 8 times or more than simply doing it right the first time.
You are mostly correct, but companies making the investment in training still get technical debt because people don't know enough yet. Not enough at this time. Some get better, some pause in their learning too often and rely on old habits.
The complaints you have are valid, but they are also realities. It's important to keep pushing people to improve, which is really my mission, but having empathy and understanding that the world isn't going to always match what I'd like. Advocating for improvement requires as much carrot as stick.
March 15, 2019 at 9:40 am
Matt Miller (4) - Friday, March 15, 2019 7:40 AMSorry for the pause there - I am actively involved with trying to retire some of said technical debt as we speak, so this is highly relevant here.😛I get to live daily the part where changing code that's made it through is hard to change. I unfortunately don't have control over the skillsets of the folks doing the coding or over the latter stages of our deployment cycles, so I try to put my influence to use in avoidance when possible: in the early design phases, training, reference materials, patterns and standards. Failing that - issues often gravitate my way once they've started to fester which gives us another chance to hopefully get it right.
That said - I was simply trying to provide how we define and manage our technical debt levels, which once incurred does require all of those coordination points in business, IT leadership and PM, etc... It purposefully is a somewhat narrower definition, but it at least does have the merit of being an "easy" definition, so we no longer have to haggle over those pieces. As we find new issues or spots we may institute new standards which then bring that new issues under the umbrella.
I think that's a good approach.
March 15, 2019 at 4:33 pm
xsevensinzx - Thursday, March 14, 2019 11:15 PMIt's often hard to do it right the first time. A lot of the large projects I've worked on where hundred million dollar online video games where getting it right the first time meant you are trying to plan out the 5-year development plan to perfection. Good luck with that! 😀
To be clear, I very much get that you don't know what you might run into and that requirements may have to change based on what was found during development. What I'm talking about is things like people writing (as a super simple example) a recursive CTE that provides an incremental count instead of using either an inline Itzik Ben-Gan style cascading CTE to do the counting because someone says it won't matter due to a low rowcount or someone calling a RBAR proc with a While Loop instead of processing the data as a set because the proc is already written or {gasp} someone using a WHILE loop because they don't know how to do a 3 table join or a running total, etc, etc, etc.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 15, 2019 at 4:43 pm
Steve Jones - SSC Editor - Friday, March 15, 2019 9:39 AMJeff Moden - Thursday, March 14, 2019 9:26 PMI get that but when you hire someone that claims 10 years of experience and you're hiring for a senior position, there should be little excuse for not doing it right the first time but the company won't actually know that they're going to have a problem because, thanks to Microsoft Marketing, everyone and their brother think they know SQL Server and, especially, T-SQL because they can actually do an INNER JOIN based on more than one column.
And, yes.... it absolutely does take time to get people to learn better but a whole lot of companies simply don't make that investment because they supposedly hired only senior people. Remember my question about how to get the current date and time using T-SQL and how I quite counting after 20 out of 22 people couldn't answer the question? Remember also that they all claimed senior experience on the resume and job history and that they supposed got that experience while working at another company.
People keep saying that their code is "good enough" but how the hell would they know? They're a part of the group that fail the current date and time question.
And I'm not talking about people needing to become rock stars but I am talking about people with more than 5 years of experience not even knowing the bloody basics.
There's something really broken out there if "Good enough" has become the standard because "Good enough" usually isn't and few have to foresight to understand that rework costs 8 times or more than simply doing it right the first time.
You are mostly correct, but companies making the investment in training still get technical debt because people don't know enough yet. Not enough at this time. Some get better, some pause in their learning too often and rely on old habits.
The complaints you have are valid, but they are also realities. It's important to keep pushing people to improve, which is really my mission, but having empathy and understanding that the world isn't going to always match what I'd like. Advocating for improvement requires as much carrot as stick.
I very much appreciate the part about empathy and understanding and the world not matching our ideals. I just continue to marvel at 10 year veterans that don't know how to avoid WHILE Loops or how indexes work and people with more than a year of experience not knowing how to do a 3 table join or even how to get the current date and time using T-SQL. I also don't know how the 10 year veterans managed to keep their jobs nor how the people with over a year of experience managed to keep theirs give such basic gaps in knowledge as I've just described.
While I am empathetic, I'm also disgusted by the fact that people won't take the time to invest in themselves. The statement "I'm a newbie" only works for so long.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2019 at 4:25 am
For me technical debt is putting in place something that will be a pain point that will manifest from early on and which is known to be a pain point at the time it goes into production.
The stateful nature of data magnifies that pain.
The point of technical debt is to provide a competitive advantage to the organisation. If you don't address technical debt then that advantage will be lost when the interest payments (in the form of additional mitigation actions) start to bite.
The important thing is to gain a shared understanding of the benefits and cost and an honest agreement as to the repayment plan terms.
Viewing 15 posts - 31 through 45 (of 47 total)
You must be logged in to reply to this topic. Login to reply