May 8, 2023 at 12:00 am
Comments posted to this topic are about the item Technical Debt
May 8, 2023 at 4:10 am
I wonder why it is that there's always more pressure to "get it done" than there is to "get it done right".
Actually, I know why and the answer generally falls into the category of "we have bigger fish to fry". They don't ever seem to understand that the little fish they're shining on become big ones later on. And some become Blue Whales in size and Great White Sharks in severity and you have to take care of those before the little ones and, and, and...
... and no one understands that when you're stuck in a hole, the most important first action is to stop digging the hole deeper. Fix the debt and make sure it doesn't return. You'll then have the time to do it right instead of a death-spriral of continuously producing crap just to meet some unreasonable schedule and then having to rework it 3 or 4 times to actually make it work correctly.
And don't forget the black-eye you'll get from your customers, if they remain customers long enough to give you one.
In other words, stop making excuses and just do it right for a change. 🙁
--Jeff Moden
Change is inevitable... Change for the better is not.
May 8, 2023 at 3:34 pm
Technical debt is a huge topic, but I'm glad you brought it up, Steve. Everywhere I've worked I've witnessed technical debt. Often, it is as you said, developers (and DBAs) not fully understanding the system they're to develop and the requirements for the requested software solution. i.e.: they develop something that doesn't match what's needed. Blame goes between developers and BAs not grasping it correctly, to users not communicating what's needed well.
However, I've also noticed that the technical debt in the organization I currently work for is significantly large. To me it seems disproportionally larger than any other organization I've worked for. But I might be wrong. It might be because this organization has been around for many decades and the IT group is exceptionally large (at least by the standards I've experienced). I work for a large state government agency in southwestern US. This state has been a state for over 100 years, so some of the software systems have been around longer than anyone here has worked in the IT field.
Certainly, the ever-present pressure to work on the next urgent thing pushes addressing technical debt to the back burner. Heck, I think sometimes technical debt has even been taken off the stove. But one thing you didn't mention in your post, Steve, is a phenomenon I've only seen here. One of the first projects I was put on was to make modifications to an old ASP.NET WebForms app written by someone who left years before I came along. The fellow who wrote the app used techniques from old Windows apps development, rather than anything related to web development. I told my boss about this. My boss's response was, "All developers think every other developer's work is junk. So, the first thing they want to do is re-write it. Don't re-write this app. Just fix the small task that needs fixing and move on." I was shocked by this response. I wonder if this thinking is commonplace among the managers where I work. I wonder if this type of thinking is commonplace in other places as well. I get the feeling that if a software solution satisfies more than 75% of the requirements, then the temptation is to just call it good and move on to the next high demand project. And maybe that's the way in many places.
Kindest Regards, Rod Connect with me on LinkedIn.
May 8, 2023 at 7:57 pm
....
I get the feeling that if a software solution satisfies more than 75% of the requirements, then the temptation is to just call it good and move on to the next high demand project. And maybe that's the way in many places.
In some sense that's true. There is always more work than resources. It's also very hard for a manager, or even another dev somtimes, to judge whether something is really bad or that a developer just doesn't like how it works. Or isn't clear/comfortable with how it works. Lots of people start to change things and go too far past their scope.
Working is a feature, as is maintainability. I usually have luck pointing where I can improve things, though I do have to limit the scope of refactoring. There are other things to do. Even in great development environments, devs often want to make things better (or do nothing at all) and prioritization and time management are critical.
May 9, 2023 at 10:49 am
I feel that if the goal was to achieve flow we would all be a lot happier. As long as there are hard (but artificial) deadlines on which people's performance is measured we will always be under pressure to cut corners that we regret cutting later. Delivering software in constipated chunks is a painful process
May 9, 2023 at 2:30 pm
I feel that if the goal was to achieve flow we would all be a lot happier. As long as there are hard (but artificial) deadlines on which people's performance is measured we will always be under pressure to cut corners that we regret cutting later. Delivering software in constipated chunks is a painful process
That's very good point, David, and one I hadn't thought of, although it certainly is true. Many is the time I've felt pressed to get some tasks done, instead of making sure it was done well. And I'm the sort of person who caves under pressure, rather than pointing out that we might be sacrificing quality to cross the finish line.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply