• ray10k (unregistered)

    Joel sounds to me like a textbook example of an Expert Beginner, no? Here's hoping his changes to CVS didn't introduce any subtle bugs that only show up when you try to roll back something, but I'm not exactly holding my breath on that one.

  • LCrawford (unregistered)

    Kloc - sounds like the metric IBM was rumored to use in the 90s to measure productivity, where more was better.

  • (nodebb)

    People get their source control together with their antibiotics these days?

  • William F (unregistered)

    TRWTF is that Joel approved the code change.

    I can't get worked up about the spaghetti copypasta. They built a profitable business. Clean code is overrated.

  • Little Bobby Tables (unregistered) in reply to William F

    How's the underside of the arches of your bridge looking these days?

  • Chris (unregistered)

    So where is the CVS part of the story ? Some c&p of code is hardly a noteable wtf, even when the refactoring was approved.

  • Maia Everett (github)

    A TDWTF story where the sane person actually enacts some positive change? Now that's a rarity.

  • consultan (unregistered) in reply to William F

    The cleanliness of one's code is somewhat overrated amongst programmers. Sometimes the results you get today genuinely do matter more than the maintenance burden you have to shoulder next year.

    The ability to tell the difference between clean and dirty code is hideously underrated amongst non-programmers and the code monkeys they hire. You can't do a good cost/benefit analysis if you can't even recognise the costs associated with your approach.

    ...That second issue seems to be more applicable here.

  • dpm (unregistered) in reply to consultan

    The ability to tell the difference between clean and dirty code

    ITYM "the difference between unnecessarily clean and necessarily dirty code". HTH.

  • RLB (unregistered) in reply to William F

    Clean code is overrated.

    Well... until you have to maintain it. Then you'll be grateful for just a little bit of cleanliness and just a little bit less copypasta.

  • Brian (unregistered)

    Ah, the exciting world of startups, full of slapdash code because we have to have something that works now. Never mind the continual accumulation of technical debt, the poor schmucks who wind up buying the company can deal with that trainwreck after the creators are long gone. That is, unless the poor practices make the product so buggy and unreliable that the company folds.

  • Dan (unregistered)

    I hate to be a downer here... but I would argue that TRWTF here is that a new and possibly (based on the comment that she went to someone with "more industry experience") junior programmer was allowed to spend a whole month refactoring an important part of the product without proper planning or even a risk analysis first.

    I spent 5 years coding a large application by myself before we started hiring more programmers. I KNOW a lot of my old code is absolute garbage... but it's garbage that works. The process of replacing that pile of junk with well thought out, well designed code with proper unit tests in place is slow and painful, and requires a lot of planning... not just to make sure the code is right, but also making sure that we're tackling things in the proper order so we spend resources on the important parts first. We've had junior programmers go off and freelance on things they see that are "wrong" (and they are usually right about it being "wrong") where we've had to go and pull all their work and reassign them to keep them focused. Without doing that, we wouldn't be able to keep the system moving forward.

  • NoLand (unregistered)

    We may introduce a new meme here, "not invented at this stage and time". Seriously: The whole contraption probably started out as a single page admin tool to be used in-house by savy developers, probably by the very person, who wrote and maintained the code. At some point, a small variation was required, so the quick and dirty way was to copy and modify the interface. Was this the right time to rewrite the tool, change the class hierarchy and invest an extra man month? What is the opposite of technical debt? "Technical loan"? Notably, at this point, any changes affecting all incarnations of the GUI may still be handled by search and replace and can be applied in about a minute. Where is the exact moment to transition to a more sophisticated approach? Probably, when you've grown to the extent that you're hiring personal who isn't acquainted with the traditional style of maintaining the software and a more general approach is needed. Is "I was hired at exactly this point in corporate history" a TWTF?

  • NoLand (unregistered)

    (Following up on the previous comment) The TWTF was probably not to invest a lousy 6 extra months and add a remote interface and an iOS client app. Clearly, this technical debt! Who knows, what this tool may have to handle in the future and who may be using it in whatever circumstances? To make sure, we really should add a speech recognition bot, while we're at it…

  • Geoff (unregistered)

    I think the TRWF is some big SWING client connecting directly to the database engine; not the implementation of said client. I mean really if the issues is having a more generic solution for controlling the back end; than something portable is in order?

    I mean really as the company grows you going to let every Tom, Dick and Harriet in customer service make connections to the database sever? Leave the firewall rules on the datacenter or hosting provider open to the client dchp pool? Not to mention any of the potential locking and concurrent editing issues that will be vastly harder to deal with in a fat client.

    As far as the code base itself goes..Copy/Paste isn't always that bad depending on how its done. Example here lets say a class exists for every tab and they are each neatly placed in their own file. Provided they all start from the same template and then get a few changes each; it might not be that bad to maintain, test, etc. Sure you have to make some changes 15 times but they are all the same change in about the same spot you can quickly locate with "find." Is it how I'd build something like that if it was going to be a production app with a long life and real project plan behind it - No. I might choose to organically evolve a little maintenance tool that way though..

    On the other hand if its 15 mud balls where individual methods are copied in helter skelter that is a different matter entirely.

    I am all for DRY - but DRY'ied out is a thing too. So she has made this nice wonder widget that is flexible enough to be any tab in the app? Okay great can I actually use it quickly or am I now looking at 20min of reading documentation to understand how 10s of properties and constructor arguments all interact; and slogging thru conditionals nested 15 deep when I think I hit a bug?

  • Copy paste heaven (unregistered)

    15 variations you say? Bah, I once investigated a system that had 3000+ variations with minor differences. Each with 3+ places with hardcoded database user and password strings.

  • desertrat (unregistered)

    Or Joel just got the n00b to finally do the tedious refactor the gargantuan mess of code the founders left him to deal with on top of all his other duties.

  • (nodebb)

    Code reuse by OOP?

    Crazy talk!

    We do code reuse by copy & paste! Much faster and more productive.

    BTW - I am not talking about Marylou's employer, I am talking about my client and the devs the client typically hires.

  • (nodebb) in reply to Copy paste heaven

    I've got you beat; we use only one JDBC connection, left open all the time, used across multiple threads, with some of the threads setting the commit flag on and off.

  • Appalled (unregistered) in reply to desertrat

    This sounds more likely to me, that Joel was ecstatic that the kludge was finally upgraded . Plus his quick "Code Review" inspection was more likely Standards and Guideline related. In other words he TRUSTED that his developer fully tested and got it right. Trust is the highest form of compliment one can give or receive and is rarely seen in IT. No WTF's here except for the original slapdash approach and resultant kludge.

  • Karl Bielefeldt (github) in reply to NoLand

    I tell people to use the rule of three: refactor the third time you need something nearly identical. Making a single additional copy is no big deal, but if you start making more, it's a sign you should create a more general solution.

  • DK (unregistered)

    I don’t really get the issue here. It sounds like most of the changes were deletions in a non-critical component. They also do not deploy the code into production immediately. Sounds to me that Joel spent the right amount of time reviewing the code. If it does not work, it should be easy to revert the change. If it works, it’s going to be easier to maintain than the old mess. Am I missing something?

  • BobbyTables (unregistered)

    I've seen a lot of startups, the ones I've joined where they have a successful business often have ugly code bases. Those that have really clean codebases, were struggling for revenue and traffic.

    The only bright side to the latter is the chance of an aquihire, but that pretty much means the 'clean' codebase is deleted. With those ugly codebases, you'd be lucky if the eng team wasn't very ambitious, and the uglyness was just copy-pasta and a few monolithic classes here and there. That can be refactored.

    The real bad codebases are where an eng team has tried to create the 'generic object system' that implements 'generic actions'. The only bright side there, is you can submit those to this site while your management is wondering why some 'easy' feature takes months to develop.

  • Loko8765 (unregistered) in reply to consultan

    I wrote a ugly hack once (well, several times, but this is about that one time).

    It was so ugly that I would have written better in just 4 hours more. I was ashamed even while writing it.

    I wrote it starting at 6 PM after a full working day, pushed live at 7 AM, user acceptance testing at 9 AM sharp. The new user did +30% on company revenue and +300% on company profits, and we got a nice article in the press that brought in more of those users. Those users all got the same hack, I think we didn't touch that code for 6 years.

    And yes, the sales guy who when discussing tomorrow's client at day's end meeting thought to mention for the first time those special conditions the client had made him put in the contract when they signed it a month ago? He got his commission and kudos for the sale, of course.

  • (nodebb)

    You know the universe is out of kilter when the WTF is that a massively-improving code change didn't get rejected out of hand.

  • amaarali (unregistered)

    I've seen a lot of startups, the ones I've joined where they have a successful business often have ugly code bases. https://47biz.com

  • Barf4Eva (unregistered)

    "That… that isn't frist," the last commenter said.

    "Well, it's like frist."

  • smf (unregistered) in reply to consultan

    Compromises have to be made at times, but clearly the compromises in this story would have taken longer to implement with a higher chance of bugs.

    It's not always wrong to refactor like this, that is just as bad idea as always refactoring.

Leave a comment on “A Big Change”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article