Dirty code? If it works, leave it says Thoughtworks CTO 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’ CTO told the Continuous Lifecycle conference today. Keynote speeches at software conferences often paint grand visions for …
10 But this new stuff is shiny, and new, and it will be much much better if you take the hit of refactoring you code to use this shiny new glittery stuff.
20 Rework code,
30 Find inexplicable bugs caused by new stuff
40 Google "I'm having this problem with new stuff"
50 About 360,000 results (0.60 seconds)
60 All say variants of "Help, I'm having this problem with new stuff". None have any solutions.
70 Eventually get bugs fixed by luck and educated guesswork
80 Wait three months
90 Goto 10
its not called code for nothing!
Most high level languages seem pretty readable to me - a lot more than various human languages like %any except english%
I mean whaddya want, something more like this:
10 open that file bruv, the one with list
20 go through it , check each entry innit
30 drop a printout on me desk, giving me the skinny on each thing.
40 chill
Seems to me she is just regurgitating Joel on Software's seminal advice. Old code always looks like inelegant bad code, but it rarely is because it is also something the value of which developers who want to use the latest tools, language advances and code patterns tend to massively underestimate; Debugged code.
The dirtier the code the harder it is to find those Zero day exploits.
One contractor I worked good number of years ago with delighed in making the code he wrote as hard to read and understand as possible. If he could make the code fit on one line then he'd do just that. One application was written with no line breaks. Back then, peer code reviews were just a pipe dream.
The Support team hated him so much that for years after he moved on, they had a dartboard on the wall in their part of the office. His mug shot was there with darts sticking out of it. anyone finding 'holes' or 'undocumented features' in his code was entitled to vent their anger by throwing darts at him
He was last heard of in Kiwi land doing the same down there.
"whats the point having it then? may as well just delete it once its been compiled."
Some people (I confess to being one of them) argue that it's better to write code that can be thrown away than to continually change and tinker with existing code due to time and cost restraints.
This post has been deleted by its author
mmmm. Dirty code means what kind of code, exactly? I mean this could be anything from just a pain in the arse to read and back to front logic for most people, or it could be dangerous code that doesn't handle certain conditions well and introduces shite into your data. This smacks of soundbitiness.
Dirty code like Bobby Tables' school used?
Actually that was probably perfectly clean, easy to read code. Just take the user input, and pass it straight to the database. Could be done nice and simply in a single line.
In my current place of workship, Dirty Code is "anything written before the current development manager started".
Even today, a request was discussed to add a new field to an existing screen. But because that screen doesn't look great (it's only used internally so nobody cared about making it look good), and is written in older tech, the decree has been to re-write the entire thing into <insert today's new technology>. So the job has become about a week instead of about 3 hours.
In my experience there are often "developer" and "support" people's different approaches to fixing or enhancing code written by someone else.
The "developer" writes a large blister patch based on how they would have implemented the whole thing. This often leads to unintended side effects.
A "support" person gets to understand the code - and often finds that it only needs a tweak. This is then coded with a method in the spirit of the original,
On numerous occasions I had to rip out a colleague's large blister patch that had produced new bugs. It took time and effort to understand exactly how the original code worked - and why it failed in a particular case.
You know when a sphere of human endeavour become 'in vogue' in the 'common' sphere. You get a fucking bunch of know nothing arseholes commenting and generalizing on something they don't know anything about and getting paid for it in conferences - and then their ramblings are quoted in the media.
Part of my job involves fault finding on systems involving a number of integrated servers and applications to produce a single product - this is probably close to 20 years old now, with continuous updating and development during that time and I suspect very little code from earlier versions has been cleaned up.
We're now at the point where there are so many errors, especially Java errors, in the logs that quite often the only way to tell if an error is relevant or not is to look at a functioning instance and try and work out which errors can be expected and which are not just a result of normal operations.
Add to that the vast number of code blocks, still present, that apply to obsolete hardware and deprecated processes (or even integrated applications) which result in duplicated config files and dead ends - well, you end up with a nightmare to maintain, but it's all ok, because development cost has been minimized.
"The pragmatist says ignore it, it’ll go away"
the author obviously hadn't any concept of technical debt when this sentence moved from their brain to their fingers and the keyboard. Sort of like a small child covering their eyes and thinking they're invisible.
Meanwhile. back in the real world profits are evaporating at an ever increasing rate as the "if it ain't broke domn't fix it" motto continues to be misinterpreted as "if it's a pile of incomprehensible rubbish, but generally works most of the time and we can muddle through, despite the huge cost of maintaining it, don't fix it".
You just want to wash your hands of it all. The problem is that if you work on code over time that has accreted parts here and there from increasing requirements, you just keep pounding away at adding little things here and there, and the ball of string just keeps getting bigger and bigger. Yes, it works, but very few people "understand" it, or what is going on.
I suspect that eventually you get shortcuts compiled in, and underground cheats (see VW). Those that actually need to RUN the software and understand its error messages and their context (to correct the environment as necessary) just need to muddle through.
It is a tough life but we all persevere somehow.
Don't even ask what software I am relating to, let's just say it is BIG and COMPLEX and EVOLVING, all at the same time.
Oh, at one time I drove a nice grey VW bug (it wasn't THAT dirty!).
What I got out of this was A) If you don't need to fix the code, don't fix it. B) Hopefully by the time you need to fix it, you don't even need it, and C) Maybe someone else will have fixed it so you can fix it when you need to fix it.
Or in other words:
Step One: Ignore Dirty Code
Step Two:
Step Three: Dirty Code is fixed.
"This fits in with a world where lowly IT functionaries could not hold up change anymore, but where businesses were demanding systems work the way the business did, she argued."
It's the lowly IT functionaries that manage to keep things moving despite interference from management types, who require yet another meeeting to decide nothing at all, who won't cross the room to talk to one of their lowly IT functionaries.
Often in the real world, refractoring or rewriting old code sounds very good. But the problem is the revised/new code still needs to be thoroughly tested and verified which is not a trivial task. Thus, code clean up could end up being a bigger mess than leaving the gnarly, dirty code alone.
When "Quality" was all the rage - the managers complained that we were over-engineering by writing open-ended code. Invariably the customer use changed in a way that vindicated having the flexibility to accommodate it.
It reminds me of someone discussing their very successful OO implementation of a POS terminal. He said that it worked because their previous systems had taught them all the wrinkles that the customer might need. If you don't understand the customer's needs thoroughly - then you can paint yourself into corner with a "precisely engineered" design.
Tom Peters had a story in one of his books about several companies producing various major assemblies for a successful missile system. They defined the interfaces between them in a flexible fashion - rather than trying to tie everything down to the last detail.
I have always been a woodworker rather than a metalworker. Cut the joint close enough - then gently tap it home.
There were problems in WW2 when it was discovered that some components didn't fit together - although they had been accurately machined to the same specification in the USA and UK. It was discovered that the countries' imperial standard measures were slightly different.
' If you don't understand the customer's needs thoroughly - then you can paint yourself into corner with a "precisely engineered" design.'
This, a thousand times. At my last client one of the internal bods - who should never have been let loose on a database let alone design one - came up with a schema closely tailored to the initial requirements. When I retired they were still having to amend that schema and the supporting code every time there was an amendment to the contract.
I thought that dirty code was stolen code, as in the code whose functionality you need to replicate using "clean room" methods. So what is "dirty code" in this context? Code written to standards that are no longer fashionable?
I wrote a program suite in CB-80 to run in CP/M. When the time came to recompile this for CB-86 and DOS, my successor was pleasantly surprised, he needed to change only a couple of lines out of thousands. When "the competition" decided to advance to a new platform, they were down for about nine months. Was my code "cleaner"? No, we were lucky.
Is it really safe to be agile in certain areas, though?
Say I work for an automatic enrolment pension company who, despite having millions of members, has still yet to see the largest waves of member enrolment, as that will be when the smallest businesses are rolled into the scheme in 2017.
We keep to an incredibly strict waterfall timeline and have to keep up clear audit trails through every step of our software testing processes, from design to execution to defect management. We're rapidly reaching a point where we could expect 50+ thousand member enrolments a month.
Would it be safe for us to adopt an agile process, taking on the burden of low or inadequate documentation and testing of a questionable depth? I can see it being fine for a small city bank rolling out an optional app to about 300k people (an agile project a friend is currently working on), but for the largest automatic enrolment pension scheme in the country? I can't see us developing and testing a new method for members to retire in a single agile sprint. I guess the argument can be made that the continuous incremental and iterative lifecycles allow for constant updates to be made in the case of issues being found... But does that not also apply to issues being introduced? If we find a production incident now, we have a very clear line of traceability to see what went wrong and where, and the issue is then dealt with outside the normal testing lifecycle ASAP (though still with a clear audit trail).
Sometimes I feel like "Agile" is just an 80's buzzword and I really do think its just jumping on the bandwagon in a lot of instances. Though this is from the point of view of a tester, not a developer, and also from someone who is in an environment where the "customers" cannot just change their mind about what they want or the suitability of developed software.
I thought the point she was making was don't make changes for change's sake? If the code is insecure or buggy or unsafe, then change it, but if it's a mess and is working, don't touch it until you have to. I would imagine that most gainfully employed folk don't have time to go around changing code that functions perfectly well. And imagine the joy you'll experience if your shiny new version has bugs in it!
Where I work there are probably over a hundred hand-tailered slightly different versions of the same 20 year old software for each customer installation. It's a mess and it's becoming unmaintainable.
There's a new platform which is supposed to save everything, however it's Java and it's not high transaction so customers are rejecting it. They probably went with Java because of Java schools producing Java devs by the bucketload. Again, low dev costs and whatever problems come up will be fixed in the future (except they won't).
Agile promotes this, "just do enough now to get it out the door" instead of writing quality code now which can cope with future use cases. Layer on layer, over years, until you're stuck. It's shit.
It's a mess but it's where your value is. All those different versions, patches, tweaks and kludges represent 20 years investment in understanding what your customers do and all those odd exceptions, minor cases and other surprises that have come up over the years.
The myth that we all subscribe to is that you can sit down with <user> and apply <methodology of the month> and you will produce a complete new shiny system that will cover all those cases.
And one that won't be technologically obsolete by the time you finished it
"The myth that we all subscribe to is that you can sit down with <user> and apply <methodology of the month> and you will produce a complete new shiny system that will cover all those cases."
An alternative approach is to sit down and ask what's the general problem of which this current requirement is an example. It's the basis of the most widely used software, otherwise you'd have compilers only capable of compiling helloworld.c and operating systems only capable of running them.
" It's a mess and it's becoming unmaintainable."
Known as "the spinning plates" problem. Too many plates that need to be kept spinning when there is a common change to apply.
In one company it was called "the cream problem". The "cream" boxes proved extremely versatile as a base for customers' special requirements. The applications could be quite different - but they could use the same basic box, hardware, and much of its firmware. That meant development time and costs were reduced significantly - but the tree of versions gradually expanded.
"Where I work there are probably over a hundred hand-tailered slightly different versions of the same 20 year old software for each customer installation. It's a mess and it's becoming unmaintainable.
There's a new platform which is supposed to save everything, however it's Java and it's not high transaction so customers are rejecting it."
I have a feeling you and I may work for the same company.
Your name's not Sam, is it?
Not sure the picture matches the content, although I am sure they were going for the dirty car as an analog for dirty code, Mr Allen (who has had several accusations of child abuse from various locations) is bad code that should be removed.
Problem here, as elsewhere, is too much concentration on the implementation. Totally naive. Bullshitter.
As someone who, for ltast 20 odd years, has effectively been a programmer, I dont worry too much about the language - bit of whitespace here, white space there, they are all much of a muchness (apart from Java which is shit and being used for something for what it was not designed for i.e. only programming set top boxes. Oh and PHP too. Junk).
What care about is how a system is put together. Is there some sort of structure, where I can pull bits out and swap them in and out.
How can I test something? Does the system make testing easy?
Is there a control system in place? As soon as something leaves the door, can you rebuild a previous release easy? Is there versioning - at the software and the product level?
Requirements will change, definitely before you've finshed, usually before you've begun.
Requirements will change, did I mention that? hardcode nothing.
Elegance maybe satisfying, Payday is better; know when to stop twiddling.
The one who will support your code in five years time is a homicidal maniac who knows where you live.
Good code is like good driving; defensive; everyone else is out to get you so deal with it.
Copy and Paste is the Enemy of the people, don't do it, that's what functions were invented for.
Software is never finished, it is always a work in progress.
Software is never released, it escapes.
LIve by these rules or forever be condemned to rewrite management reports ad nauseum..
This post has been deleted by its author
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 somewhere in your code it always ends up forcing bad behaviours through the whole rest of the code in a sort of viral way.
How many times have we been forced to add new code in some screwy way just to comply to some fucked-up underlying code rather than fix the actual problem. So now you just have even more shit code. Not fixing the underlying bad code is just kicking the can down the road to a much larger problem later. I've already lived through it at several different companies that all thought they were being 'smart', and every time they learn their lesson the hard way.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
