Journal BarbaraHudson's Journal: Justifying not cleaning up code in a click-bait "agile" article 15
The reg has this incredibly stupid attention-seeking article justifying not trying to clean up dirty code that seems to be working okay.
âoeYou might have a complete disaster in code
You know the code is crap, and you're willing to leave that technical debt until you HAVE to change it? In any other industry that would be called willful negligence. No wonder it's a good thing we don't build houses (or cars or airplanes) the way we build software. That code could be one reboot away from a disaster but hey, we won't fix it until we have to.
âoeThe purist in me would like to say you still need to clean it up because itâ(TM)s terrible. The pragmatist says ignore it, itâ(TM)ll go away.
Ignore it, it'll go away. Really? Here's a hint. The code is not self-aware. It won't fix itself, and ignoring it means that it won't go away. Only paying attention to it and doing a good review *might* make it go away.
Dirty code is a fact of life, and working out which software really needs changing and leaving the rest will help many IT organizations gain at least some of the benefits of going Agile, ThoughtWorksâ(TM) CTO told the Continuous Lifecycle conference today.
Just another consulting business trying to convince other businesses that it's better to wait until stuff craps out and then call in a consulting firm to fix it rather than keep people on staff who know the product and have a vested interest in making sure that the dirty stuff gets done before the turds hit the ventilator.
Their motto should be "Don't be proactive - be agile!"
Of course, if your bosses buy into this, you'll probably be out of a job when the company has an unrecoverable error and goes broke, if they haven't already fired you because maintenance of legacy code is seen as no longer needed.
Only more lawsuits over bad software will get rid of this attitude. And jail terms for bad software that results in injury or death. Bosses will only take quality seriously when their asses could be thrown in jail because of such willful negligence, or shareholders suing their asses into personal bankruptcy for loss of value.
Risk (Score:3)
Respectfully, I don't think you've done a good job assessing or presenting the risk posed by the code.
Is this Internet-facing code? If not, there may not be a security risk.
Is this business-critical code? If not, there may not be any business risk.
How often does the code get used? If it generates a report twice a year consuming 8 hours of staff time, how much time should really be spent resolving technical debt?
Technical debt should be avoided, but once you have it, it should be resolved either when it poses some legitimate risk to the organization or when the manpower needed to use or improve the code is impacted enough to merit the cost of refactoring.
Re: (Score:1)
I think it's rationalizing to try to examine technical debt along narrowly-defined lines. It's excuse-making.
(Similarly with tending to over-estimate how much code in an organization actually will never need to be touched again.)
The risk of technical debt is surprise costs, of unpredictable magnitude, that are unforeseeable.
You can manage personnel, operations, etc., but you can't manage chaos. It's chaos.
It's the folly of thinking everything is manageable, quantifiable, etc. Like you can plug formulas i
Re: (Score:2)
Of course we can manage chaos. That's what business is all about.
Any particular software impacts specific processes within the business. We can know those impacts and place an upper bound on the cost of failures without having to know anything at all about how well the software is programmed.
If any of those impacts is a critical business failure they yeah, we'd better deal with the technical debt. But not every piece of software sits in a business critical path where it's capable of failing in a manner whic
Re: (Score:2)
Businesses go bankrupt all the time. Black swan events are by definition not predictable. So no, business is not all about managing chaos.
Business is first and foremost about staying in business. Technical debt is like any other debt - eventually it will need to be paid, with accumulated interest. One of the advantages of keeping technical debt low is that it keeps your in-house people sharp. You do want sharp people, don't you?
there's the problem right thar (Score:1)
Bosses will only take quality seriously when
Bosses don't know what quality is. They have no means of assessing whether a routine I wrote is shitty or good. Only if it works or not. Programmers have anywhere from a little to a lot of ability to sniff out technical debt in code. Bosses have zero. So while I agree there's a problem, I don't know how bosses can rightfully be held accountable for it.
Re: (Score:2)
I remember recommending that someone be fired, as well as the guy who hired him, because the person hiring them obviously didn't have the chops to make such decisions.
So of course that person was the person I was talking to, the owner. Always works out that way, doesn't it :-)
The Dunning-Kruger effect was strong with that one ... but they could have used several proxies to judge who might be more likely to not be so casual about quality. For example, bitching about unnecessary changes and saying that it's
Re: (Score:1)
Dunno what Agile has to do with it. Where I worked before it was 9 month trudging long waterfall with feature creep up the ass. Where I am now we do 2-week sprints. I just started there, it's my first Agile place, but it seems like it has to be better than what my previous employers were doing.
Re: (Score:2)
Re: (Score:1)
I fail to see how tackling a big picture problem requires long-ass waterfall development cycles.
Maybe agile sucks, I don't know, I'm on my first agile project right now, but I know the alternative sucks total ass, so merely sucking is a huge improvement.
The word 'pragmatic' is the key here (Score:2)
If you read the article properly, you would have understood that according to her it is all about being pragmatic. This means weighing the financial risks of having bad code in your software, against the costs of fixing it.
This person speaks from the perspective of a CTO. It is all about risks and the costs that go along with it. The world of a CTO is not all black-and-white with regards to software and bad code. There is a lot of grey area, where the cost of fixing a bug does not always necessarily measure
Re: (Score:2)
Being pragmatic is all well and good, but a pragmatic person should realize that it's better to fix known problems before they become roadblocks. Cleaning up code today means that if you need to add functionality 4 years down the road, you don't run into as many side effects, you have a cleaner path to doing so, and it also makes understanding the code and debugging it easier.
In the long run, it doesn't take more time, and probably less because you're not trying to both fix old code and add new code. Doing
clueless (Score:2)
This is wrong thinking. You wouldn't build a house on a bad foundation, so why would you do so with software?
Follow this "dont fix bad code" strategy long enough and you get to a point where even small changes take months, have a very high risk of unanticipated side-effects, and eventually even management are forced to agree that the whole system needs totally rewriting at massive cost.
The problem is that if the code is bad then so are its interfaces, and so are its side-effects. If you have some shit code
Re: (Score:2)
Exactly. It also sets a bad example for anyone around you. You slack off about cruft, so will they.
I remember one time when my former boss came in (I had been working there about 18 months to 2 years at the time) and announced that I had made a mistake. He was so happy. So I turned the tables by cheering about it. "Yes, I made a mistake! Isn't that GREAT? I learned something new!!!" Then I told him that I had realized it on the drive home and fixed it already.
This project required multi-threading c code t
What do you expect? (Score:2)
He's coding for a company who does click-bait. You expect a guy who's willing to work for a truly evil employer to give two shits about his job? If he had an ounce of character he'd be living at the homeless shelter before making his money from evil.
Re: (Score:2)