- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Stop Poking Me!
- Operation Erred Successfully
- A Dark Turn
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Typical, why are people so afraid of reworking awful code?
Admin
More like people are afraid of change.
Admin
Admin
Because it might be reworked by somebody less intelligent than the original developer. Then the entire system is broken. Better to keep the shit that at least runs.
Think like a manager, not a coder.
Admin
Rule 2: If it works, break it.
Admin
Bah, why not just use the best of both worlds? Write a new system that will generate invoices. Then rely on the sort of hack that will keep you up most nights, but not all nights:
if ($invoice->date < $revisedBySimonDate) { $oldClunkyElseifSystem->Generate($invoice); } else { $newBeautifySystem->Generate($invoice); }
The system that works and has worked for 10 years stays in place, complete with whatever eccentricities and hacks that keep it alive and working. Any new invoice won't have to rely on the older, discontinued products, and thus can be handled differently.
Admin
To a coder it's an abomination. To everyone else it's a working system.
The fact that it's inelegant is not reason enough to introduce a load of fresh bugs with a rewrite.
Admin
If a system meets the needs, then the benefit vs. cost and risk of a re-write is very very very rarely justified.
Coders wanting to re-implement systems simply because they are not elegant (or are even clinky) is a major problem in software engineering.
People who watch the TV show "Numbers" should remember an episode a few weeks ago (sometime in October) where major issues (including multiple deaths) resulted directly from engineers NOT taking into account hard realities and always believing they could make things better in a short amount of time.
Admin
Agreed. The manager was completely correct to refuse the rewrite.
Admin
Except the problem wasn't just that the code was inelegant. It's that the code was running "slower and slower". The performance problems were presumably why the inelegant code was discovered in the first place. In fact, the TRWTF is that when the manager asked "Why would we want to change?", the answer wasn't simply "Uh...because our customers are complaining that even the simplest transaction takes way too long."
Admin
[quote user="halcyon1234"]if ($invoice->date < $revisedBySimonDate) { $oldClunkyElseifSystem->Generate($invoice); } else { $newBeautifySystem->Generate($invoice); } [quote] I applaud your efforts to ensure that readers of thedailywtf will continue to be entertained for years to follow.
Admin
It's working and making money? I wouldn't touch it without a whole lot of signing off. And testers. Lots and lots of testers.
Admin
That's true. However, next to the want of coders to always re-engineer what others made, I think in this case, that it's justified to do so. Performance and maintainability of this code is nigh-zero...
Admin
Well upgrade the server then. (aka bruteforce) Oh crap That is not a good answer it is working so why change it?
Admin
Using the show Numbers in place of a real world example is the real WTF here! ;oP
(Btw, I actually agree with you - just couldn't resist)
Admin
He could have improved the else-ifs. Simply put the new products and the often shown/bought stuff at the beginning of the decision tree and everything should run faster. ;)
Admin
I WTF'd at the end, when the big bosses back-tracked on their decision to replace the old system with the one Simon was proposing.
Then I realized what the WTF really was: Simon was what we used to call "hobby jobbing". He wasn't acting on management instructions. He wasn't addressing business or operational concerns. He hadn't taken direction in a meeting where his manager (say, Rob, in honor of this) said "Simon, I'm concerned our shopping cart application is getting a bit slow. See what you can do to speed it up."
Simon was pursuing a course both self-satisfying and good for the business. But not one that his bosses were aware of and, apparently, would have approved.
I suspect a lot of code monkeys out here in WTF-land are thinking that the WTF is Simon not being permitted to do the obviously right thing. "Stupid management, too short-sighted to allow me to solve all their website performance problems."
The real WTF is that solving a problem which isn't an actual problem--not hurting productivity or revenue--and in which the solution imposes new problems (like making Customer Service refer to soft-copies of invoices instead of direct lookups) is generally not a good solution.
I have to wonder which of Simon's actual tasks he was blowing off to do this journey to the center of the app, the land that code sanity forgot.
Yes. It's hideous code, and WTF-worthy in the same sense that a bad accident in a road race is compelling. But if it's functioning, you have to lay the organizational ground very carefully to support "fixing" what isn't broke, from the user perspective.
Admin
Well said! My sentiments exactly - the problem here seems to be the fact that Simon was just like every other 'coder' (not a developer - doesn't deserve the title). When faced with the (rhetorical) question from his boss he actually cared that it was rhetorical - hence: "However, the more familiar Simon got with the code, the harder it was for him to understand why it was allowed to remain in place for over ten years."
His boss is clearly a moron: "what we have works already and has been working consistently for the past ten years!" - er... the code is changing all the time and getting slower. Try factoring ongoing maintenance versus refactoring time into the equation.
CAPTCHA: plaga ... sort of like a spanish beach for drunks?
Admin
Ohhh interesting take on it - expect at the end it says: "Defeated, Simon went back to his maintenance work and added yet another elseif() block to represent yet another promo offer." so I assumed that this is what led Simon to consider that the whole thing was becoming troublesome (as he opened the file responsible and waited several minutes while his IDE eats up all his resources). And then he did go to managment (we hope he did this before creating a new branch in the companies' VCS of choice and playing about) but he just gave up to easily.
:)
Admin
This. You will rise to management fast.
Admin
Maybe the boss wasn't being rhetorical. Maybe he actually wanted to know why something should be done before spending developer hours, QA hours on something that requires a change of process for the customer support for the worse? Maybe Simon should be able to come up with a valid reason for this. "It currently takes 15 seconds to bring up and invoice. My estimates indicate that at the current rate we are growing it would take 80 seconds to bring up an invoice by 2012." To which the boss might ask something like "are there any other feasible options with lower risk?" to which the developer could say "well.. we could use a map-kind-of-thing to store the product codes in.. that would make large orders run almost as fast as single-item orders. I'm guessing that would work."
Admin
Simon may not have been acting on management instructions, but he was addressing business concerns: It is (too) complicated to add new products or change existing ones, and the system is unresponsive. Taking action against this, whether instructed to or not, is A Good Thing.
TheRealWTF is that he gave up so quickly when his boss asked him why this was needed (rhetorically or not). Instead of assuming his boss is a moron, and having all the facts had already made a (wrong) decision, he should have said:
Fair chance his manager would have been happy with his initiative and told him to go ahead and change it.
Admin
While I don't disagree with the conclusion that it was right for management to reject the proposed change, I'd question whether it can be safely assumed that a core business function which is getting slower and slower at a linear rate is not hurting productivity or revenue.
Admin
Admin
Assuming the order of the if ... else-if blocks can be changed that is, the time taken to shuffle around 16000 lines of such blocks and then test they are working is potentially a monstrous time sink.
You then also get the problem of where to locate existing blocks - they start new -> old then go old -> ancient and finally ancient -> old again, this is a minefield for whoever has to maintain this new 'improved' version.
Admin
I find myself in a similar position to Simon now, except its with a denormalized database. The most central table of the site has grown in size because of quick fixes and easy additions done because we're never allowed time to refactor. The result is that the site is able to handle less and less traffic, and if this goes on will eventually be unable to handle enough volume necessary to make a profit. This has been made clear to management, repeatedly, and the response is always that the site isn't crashing so we can't stop the business to let Tech do it. They also don't think they should have to pay for additional hardware unless the site is actively crashing.
So, no, if the system meets the needs that means nothing in regards to if refactoring is justified. If the needs change then the system must be capable of meeting the needs that haven't happened yet.
Admin
What I understand from reading this story is that it wasn't Simon's job to refactor or rewrite the spaghetti code - his job was simply to add a new item to it. So on the one hand I would say well done for looking into ways of improving the long-term maintainability of the code; but on the other hand, he should not have been wasting time on work that was never tasked to him in the first place. If he wasn't actually told to do the work then he shouldn't really be surprised when his boss tells him to get on with something else.
Admin
If the time taken to refactor can be provided without disrupting the service then it is (should be) an easy decision, however management (for whatever reason) often let problems exist past the point were fixes are practical and the problem turns into one of keeping the existing system up as no other solution appears possible.
If the system is going to fail then there is a massive financial impact looming and this is the point that should be brought to the appropriate persons attention, preferable with hard figures to back up the prediction.
If the management still refuse to act then make sure all your documentation and paperwork backs you up, keep your CV up to date and by keeping your eye on the current system you will know when to start looking for the next job...
Admin
Admin
Fantastic - replace 16000 lines of if / else with 16001. Genius.
Admin
Umm... so old fashioned receipts aren't a good solution anymore? Granted unless the pdf's were setup in a way that was easily searchable that wouldn't be a good solution at all. But having to execute 16,000 lines of code or just search a couple of pdf's for a particular receipt sounds like a pretty big difference in speed and efficiency.
Admin
Admin
Hahaha agreed. If everyone thinks like this why the hell would companies have maintainers to begin with. "if it works who gives a crap if its slow and written poorly"....yeah.....
Admin
Admin
Yes, Yes!, YES!! Management hires developers to NOT tell them when the infrastructure is beginning to crumble so as NOT to avoid future disaster.
It's exactly the same as engineers and bridges, only instead of people dying the company loses profit and customer base.
The real culprit here is the writers on Star Trek, for convincing every manager out there that they are Captain Kirk and the engines will not explode when pushed 20% beyond maximum capacity simply because the Captain ordered it to be so.
If the Captain says that the energon crystals can be refitted in 30 seconds when the manual states it takes space dock and 6 months of work, then obviously the Captain is correct! Make it so!!
Why allow reality to intrude on good television? Or on management's decisions for that matter?
Admin
As a professional, your job is not merely to write code, but to also warn management of possible future problems and risks to business you may become aware of. Granted, the system works now, but what would happen when the system finally becomes too large to rewrite, and too slow to work? I can hear management now, "Simon, how long have you known about this? And why didn't you say something sooner?" The real WTF is that Simon couldn't muster the courage to say something like, "Yes, I know it works now, but it will become progressively slower unless rewritten, and it will cost you less to do it sooner rather than later." In any case, Simon is now cleared of any liability for the inevitable system crash and lost business that such a system will eventually produce.
Admin
"You didn't tell us it would be this bad!"
/facepalm
Admin
The easy medium-term solution here is to just throw hardware at the problem. Moving to faster machines from time to time is probably more reasonable than rebuilding the whole system.
Admin
Eventually there will be enough screaming by the users that it will get done. You may get fired for not being able to maintain it when that happens but, keep your chin up, the next guy will be allowed to actually fix it.
Admin
You could get a massive performance increase without breaking anything simply by replacing the massive if tree with a select / switch block.
Admin
I posted this comment before registering. Just taking credit...
Admin
This looks like a classic case of Code Cancer. The code started out with only a few elseifs, or other bad practices. However, bad practices tend to grow uncontrollably, until physical symptoms began to appear. Once this happens, there are no good options. You are forced to choose between the software development equivalents of chemotherapy or radical surgery.
Like other forms of cancer, early detection and treatment is the best option.
Admin
Kids these days are wimps.
(1) Hash. Or hash-map. (2) Do not show it to your manager. Keep it on the side. (3) Wait for somebody (customer support, etc -- somebody who actually gets hurt by this) to walk by your desk/cuboid. (4) Ask an innocent question. "That's about five seconds per query, isn't it?" (5) Wait for answer. These people have been brainwashed. "Of course ... well, about that, anyway." (6) Demonstrate parallel system with Magic Hash (Non-Smokeable). (7) "Well, that certainly seems to ... er ... work." (8) Ask customer service person to recommend new (magic! instant! not-quite-checked-in-to-madness) solution to customer service management.
Works every time.
Otherwise: find a less awful job.
Admin
Not to refute the claim that this is a full-on WTF, but two thoughts:
No, neither of these fix the fundamental WTF, but (especially #2) strike me as hack fixes that somewhat justify the business decision
Admin
I think I missed the part where he solved the elseif hell?
Or was he planning to spend his time coding elseifs, printing out the related invoices, then removing the elseifs when the promos were finished?
Admin
And for good reason. You're asking them to switch from a bad-but-functioning (at least for the moment) system to an unknown. Maybe the new system will be better. Maybe it's the best thing since cat-6 cable.
Or maybe it'll be the next entry on this site.
Local example: we just changed systems here from
My suggestion to the guy would be to start building the new system now - when the old one comes, he's already ahead of the plot to build a new one (which makes you look smart). If that day never comes, you at least got to work on an interesting problem.
That's my personal strategy around here.
And if it never hits the fan, I'm at least building my skills.
Admin
Admin
except, (assuming that the code posted in TFA is representative of the system) some scripting language is being used (looks like PHP to me) and that's 16,000 lines that have to be read from disk, lexed, parsed, syntax verified, and ... then finally... executed for each invocation of the page.
even if you assume byte-code pre-optimization and caching (ala the Zend engine) which I doubt was in use in a 10+ year old project, you're still talking about an expensive proposition...
Admin
Perish the thought.
Admin
sorry, my point being that the execution in some scripting languages can be one of the shortest phases of the execution of the page (obviously there are exceptions for DB and network accesses), and that even with the conditionals put into a "more optimized" order, if the execution is already faster than fetching from disk and other phases, it's not going to have much of an impact.