• Quite (unregistered)

    I was half expecting him to have written an automatic tool to rattle through the entire codebase replacing the existing instances of ...

    ... never mind.

  • Foo AKA Fooo (unregistered)

    TL/DR: Copy&Paste, easy to write, terrible to maintain

  • Foo AKA Fooo (unregistered) in reply to Quite

    My first thought, too. But in such a situation, I'd expect some of the 800+ instances to have subtle differences that the tool would choke on or worse, silently mishandle.

    I've had such situations (though with numbers way below 800), and the only workable solution for me was semi-automatic, i.e. have it show me the changes it'd make and have me confirm for each instance. Of course, there's a big danger you get bored and confirm too quickly, so you need good keep-awake methods (whichever you prefer ...).

  • Poor Soul (unregistered)

    That choice, unfortunately some poor souls do not get and end up playing to whims of management adding more debt as they go along.

  • Quite (unregistered) in reply to Poor Soul

    The usual approach taken by management in such circumstances is for someone to recognise that one of the key personnel (in fact, the key person) is about to leave the company within 2 weeks, leaving the company with an unmaintainable codebase and non-functioning code. Now, I am more than prepared to accept that management practices in certain areas of the world are not the most accomplished (managers being those people who bullied the nerds to do their homework for them), but there being nobody in the management structure here who is capable of joined-up thought is a toughie to accept.

  • DocMonster (unregistered)

    What I often see, in regarding to technical debt forming, is that there is always SOMEONE (usually very high up management/executive/big kahuna) who, when presented with facts or reasons why things should take a bit longer to fortify against the future, acts like a spoiled 5 year old told they can't have a piece of candy and starts throwing a tantrum/threatening if it's not DONE RIGHT NOW, and nobody has the guts to stand up to said spoiled 5 year old, so they hunker down and do some hackjob that collapses later.

    I honestly do not understand what management thinks. It has always ever seen like they go stupid when they get into management and only think short term, never long term. It's always "How can we make the most money in 3 months" not "How can we make sure this company is still growing in 3 years", and while your middle manager may see that, the higher ups seem to be so short-sighted and often so entitled and petulant that they refuse to listen to anything resembling reason and finally just throw their hands up and start dictating orders "or else" to get their way.

  • DocMonster (unregistered)

    Also is it just me or does anyone else keep getting "Illegal arguments: string, object" whenever trying to log in? Is the forum software once again the Real WTF on this site?

  • Ron Fox (google)

    At last -- a happy ending -- for the worker that is. For management, not so much but they do get what they deserved.

  • (nodebb) in reply to DocMonster

    The reason that the tantrum-throwing management thinks like that is that enough programmers pull just enough rabbits out of the technical debt-soaked hat to confirm that rabbits can be pulled out of it. And, of course, when someone objects, that person is just spouting "technical mumbo-jumbo" or "programmer jargon" that gets translated as "I can't do my job." Because the job is to pull rabbits out of the hat.

    In other words, it's *our* fault. (I'm also guilty of this particular error.)

  • pif (unregistered)

    I don't consider an IDE to be serious unless it sends an electric discharge to the developer's hand via the mouse each time he does a copy&paste. Voltage and current should be proportional to the number of lines involved.

  • Anonymous Coward (unregistered)

    It's all "We're a standards based shop and refuse to bend to unreasonable requests" untill a client throws a tantrum and threatens to leave that turns into "We will bend over and let our clients assault our product for the sake of keeping business on."

  • (nodebb) in reply to pif

    Fortunately I use ^C and ^V for my copy and paste.

  • (nodebb) in reply to DocMonster

    Note you mention '3 months'... what's every 3 months?

    Quarterlies...

    Management is beholden to the dollar.

    This is not unique to programming, it's most industry.

  • lonadar (unregistered)

    There are three types of jobs in this world: Good, Fast and Cheap. You can have any two...

  • (nodebb) in reply to DocMonster

    @DocMonster Yes, I've gotten that error too. I wonder if it has to do with password length? I had been using a four-character password but when I changed it to something longer the error went away.

  • Joseph Osako (google) in reply to DocMonster

    It has always ever seen like they go stupid when they get into management and only think short term, never long term. It's always "How can we make the most money in 3 months" not "How can we make sure this company is still growing in 3 years", and while your middle manager may see that, the higher ups seem to be so short-sighted and often so entitled and petulant that they refuse to listen to anything resembling reason and finally just throw their hands up and start dictating orders "or else" to get their way.

    One word: stockholders. Most of the stockholders - including pretty much all the larger share holders - are not investors in the classic sense, but margin holders looking to get the biggest return in the shortest time. The majority stockholders of most large companies are not by individuals, but other companies - money market and retirement protfolio management firms. They have no interest in the companies themselves, just in getting am. steady, and rising, profit from them.

    These majority stockholders will pressure the upper management to do stupid things to keep the margin high until the end of the quarter - which is the longest they will have their money in most corporations, so they don't give a fuck if the company tanks the moment they jump ship as long as they squeeze every dime they can from them first.

    Similarly, most CEOs, chairpeople, and corporate presidents have no domain knowledge of the industries they nominally work in, and expect to leave their position - in good standing or bad - for another slightly improved one at a company in another field within less than five years, and often are ready to deploy their golden parachutes in less than six months on the job. Their motivation is to take te money and run, so their priority is less the survival of the company and more minmaxing their personal severance package.

    Jim Fucking Sterling, Son, did a great expose on this sort of thing in the game industry a couple years ago, where he pointed out that nearly every AAA game company is now being run by people who know nothing about video games, and have no interest in them: https://www.youtube.com/watch?v=NzthXKu8lJw.

    Addendum 2016-08-16 09:27: Also: https://www.youtube.com/watch?v=yOi5aDQKrYc

  • Dave (unregistered) in reply to Quite

    Usually it's a problem translating between technical-speak and management-speak which causes these decisions that seem like rank stupidity. If someone had explained properly to the management what was going on, in a way they could have understood, there's a decent chance they'd have made the right decisions.

  • Dave (unregistered) in reply to Joseph Osako

    Joseph Osako, that's pure fiction you've regurgitated there - a conspiracy theory with roots in Nazi propaganda, moreover. There is not a shred of truth to the claim you make about stock-holders, and in fact the reality is almost diametrically opposite: the vast majority of shares are owned by long-term investors.

  • operagost (unregistered) in reply to Quite

    Actually, what surprises me is that they didn't respond to his notice by spitefully walking him to the door that day without bothering to let him complete his documentation.

  • Bruce W (unregistered) in reply to Steve_The_Cynic

    "Because the job is to pull rabbits out of the hat."

    I've started saying, "we keep pulling rabbits out of the hat. One day the rabbit is going to be dead."

  • DocMonster (unregistered) in reply to Anonymous Coward

    Yes I love those. " is pissed and is threatening to leave us unless we do this RIGHT NOW. Hack it if you have to but it needs to be done!". I'm sorry but if one client holds that much of your business that them leaving will be a huge hit, you've done something terribly wrong in your business venture or just got lucky with something, and there are much worse things that you need to fix. Any time you have an important client, they WILL demand that you do whatever they ask regardless "or else" and chances are that everything will stop because god forbid you stand up to a bully (and that's what they are, bullies) and say that no, this is what they get, and they're happy to go to a competitor if they so choose.

    Really, you get rid of problem customers. You don't bend over backwards to appease them, because all that shows is that they can get away with it and they'll just keep doing it because last time they threatened to pull the contract, you kissed their ass, so you'll do it again and again and again until they decide to leave anyways because someone else offered something better/cheaper, or until they drain you dry with their ridiculous demands.

  • S. Ivar (unregistered)

    "They ordered him to do as they said, and that he needed to own this problem and do whatever it took to get it fixed."

    So basically they told him to go and terminate them with extreme prejudice?

  • Jack (unregistered) in reply to Ron Fox
    At last -- a happy ending -- for the worker that is. For management, not so much but they do get what they deserved.
    When reading this I was thinking "this guy should leave the company to fail, but it's not gonna happen" and then it actually did. Good for him. Hopefully those managers learned their lesson.
  • Carl Witthoft (google)

    It's not always stockholders, but the setup is similar. Some manager decides (usually based on a GANTT chart that started out with realistic estimates, but the manager KNOWS that engineers are lazy, and cuts their estimates in half) to promise a delivery date to some customer. That manager will never allow himself to be embarrassed by not delivering on time; nor will he ever believe that something he said is wrong (see, e.g., Ronald Reagan). I once got read the riot act for pointing out that a qualification test and the product involved would have been fine if a proper peer review had been done, and THEMANAGER said, "don't you realize we had a schedule to meet? We can't add reviews!"

  • (nodebb) in reply to pif

    Voltage determines how "shocking" the shock is, but higher current can quickly become lethal.

  • Developer Dude (unregistered)

    "Decapsulation"

    I like that.

    I am going to start using that to describe the codebase I work on

    I am so a robot!

    Bender honey, we love you.

    Shutup baby, I know it.

  • Grzes (unregistered)

    This is not copy&paste. This is the Clipboard-Based Inheritance.

  • Developer Dude (unregistered) in reply to Ron Fox

    Yes - it gives me hope, for when I retire in 4 years.

  • Guest-Guy (unregistered)

    @DocMonster - I love how some blame management when this is obviously a scared developer too afraid to do the right thing and ensure it works. Upper management needed to know nothing about refactoring to an interface. They simply needed to know the amount of work involved, when it would be done by, and who would do it. I dont ask management how to apply best practices to my code, in fact i try not to explain any technicals to those that cant understand it. I just make sure when it goes to prod, it works. This has kept me successful.

  • DocMonster (unregistered) in reply to Guest-Guy

    @Guest-Guy and what when management says that the amount of work is too long, and the timeframe for when it will be done is too much, and it needs to be done by tomorrow (i.e. if you can't get it done by 5pm, better cancel whatever plans you had because the company is more important than you, so you need to work late)? Make no mistake, it's still a management issue. They don't have to know about refactoring to an interface, but they often make assumptions about how difficult/long something is (often without any relevant experience) and then hold you to their expectations, and should you dare not do it or point out why it's wrong, then you're "not a team player" or some other such excuse to get rid of you and bring in someone who is a scared developer afraid to do the right thing.

  • jrn (unregistered) in reply to djls45

    Good point. I'll make sure to max out both!

  • (nodebb) in reply to Grzes

    This is not copy&paste. This is the Clipboard-Based Inheritance.

    Best Comment.

  • (nodebb) in reply to DocMonster

    Make no mistake, it's still a management issue.

    If management are going to insist on behaving like that, you don't want to work there as they will make your life miserable (possibly to the point where you're physically ill; stress is bad for you!) and you should GTFO. The economy isn't in such a state that you have to take any old crappy job that comes along, and there's always going to be somewhere else that's better than that (provided you're not too insistent on working in a particular location). Also, if it screws the manager over then whatever, never mind, as it is just a job; let them do the worrying.

  • itsme (unregistered) in reply to Quite

    ah, been there, done that. Had an ex-boss, who was from the trade, and he didn't care (to his defense, it was "just" the homepage of the company)

  • Herby (unregistered)

    A side note: Keep in mind that when companies fail it is usually due to bad management, not bad engineering. The usual path to failure is bad management leading to bad engineering (or programming).

    A lot of the WTF! errors can be attributed to management decisions: hiring the wrong person (Paula comes to mind), or dictats (do it my way fool).

    Anyone who has been in the profession for any length of time has seen it all! Those who haven't will soon!

  • (nodebb) in reply to pif

    Hey! Copy and Paste is standard practice to duplicate control IDs to avoid mistypes, especially when the form is already swamped with controls with similar names.

  • (nodebb) in reply to Guest-Guy

    You need to allocate man-day to do refactoring. Remember, when you refactor, you do nothing but refactor. i.e.: No new features to be delivered to clients.

    When I did refactor in one of my previous company, I requested 75 man-days to do that. And after that, any changes demanded from customer is done on the same day requested or the day after that in order to show my boss the effort worths it.

  • fragile (unregistered)

    "The original developers knew not of this otherwise widely-known limitation."

    Was it ActiveMQ ?

  • snoofle (unregistered) in reply to fragile

    No.

  • (nodebb)

    Company manager: "See, now, this is why we need slavery!"

  • (nodebb)

    I've seen this happen a few times (currently stuck in a similar situation), and I've always come to the conclusion that someone in the chain of higher ups has made a stupidly unrealistic promise. This is some unholy combination of

    • Not enough information given
    • Trying to look like a rock star

    A few weeks into these scenarios, and you always get the sense that if this doesn't meet the deadline, then heads will roll. In my youth, I would've sympathized. I am now a jaded cynic who couldn't care less when any of the following is true:

    • I was not involved with design
    • I was not involved with estimates

    Trying to make good on someone else's promises is the turns you into the typical "Nice guys finish last" kind of guy. If the project goes well, PHB takes all of the credit. If something goes awry, then they throw you under the bus. Very rarely does the inverse happen.

  • (nodebb) in reply to AgentDenton

    Agreed. And I'll add a third condition: New tasks are inserted even when the schedule is already tight / impossible. If new tasks are added, a restart time per task will also be added to the estimated delay to reflect the reality.

    It's important to teach them breaking developers out of the "flow" is costy.

  • (nodebb)

    Just out of curiosity: assuming it's not an anonymisation feature, what's the "economic event" mentioned? Was this 2010-05-06 by any chance?

  • satan (unregistered)

    I hate to say it, but management is correct on this one. They have an emergency bug fix that needs to go out. You don't restructure the code base due to bug injection risk. You do that later when you migrate to the new tool that was mentioned.

  • Karl Bielefeldt (github)

    Usually refactorings that would have helped you avoid a mass change will also speed one up, because they make the changes simpler. Instead of carefully picking through copy-pasted fields and making precise changes, you're deleting five lines and replacing it with one call to a constructor, for example.

    Also, this is one of those cases where using a proper editor like vim with support for macros can really help you out. Just saying.

  • b.a. freeman (unregistered) in reply to Quite

    i work in just such an outfit in a dying industry. before the dot com boom/bust, this industry rolled in money for over 100 years; no stupid project could fail, because every stupid project made some money. therefore, there were no managers, or even the memory of a manager, who actually knew how to run a business. it has been 15 or 16 years now, and the particular company that employs me is finally beginning to roll up. banks continue to loan money if there has been cashflow in the past, so this company has been getting loans and wasting them, and has been owned by multiple groups who finally gave up, considered the money as wasted, and threw us away. the geniuses in this story would be too smart to run my employer.

  • b.a. freeman (unregistered) in reply to Dave

    yes, most stocks are owned by individuals, but most only as owners of a fund of some sort that holds the stocks. in the u.s., the feds don't allow fund managers to put people on the board, so the only choice a fund manager has when management makes a stupid decision is to sell before it's too late. management has a fiduciary duty to owners (stockholders) to make money, but again, in the u.s., management tends to be the tail that wags the board, so boards tend to focus on what makes management - not owners - happy. bottom line, most generally stupid things U see going on in the market are there for a reason - usually the dn government. privately held companies have similar problems when daddy's dumba kid starts running the company.

  • (nodebb) in reply to Karl Bielefeldt

    Yup, it also help you properly isolate methods with side effect, so you'll be less likely to introduce new bug(s) when adding new features. (When unit test is not available, proper function names, xmldoc and exception declaration really helps to reduce yor trouble)

  • (nodebb) in reply to Watson

    I was thinking of one that happened earlier (2007?), when the Chinese IPO'ed one of their big banks. They priced the shares very low, a handful of yuan, so that the Chinese equivalent of Sid(1) could buy a few.

    (1) Character used in the advertising for the privatisation of, if I recall correctly, British Gas.

    Of course, pricing the shares low meant that they had to issue more of them so that the initial capitalisation would be the same.

    On IPO day, the total shares-traded volume for that bank was 14 billion shares. Trading and information systems around the world had issues. I was responsible for a VWAP (Volume Weighted Average Price) calculation module that used 32-bit signed counters to keep track of the total volume. Needless to say, clients weren't amused when we started calculating negative average prices. They kinda understood, because no single stock had ever had an intraday volume over two billion before that day, but it was still embarrassing.

  • Thu (unregistered) in reply to pif

    Voltage and current should be proportional to the number of lines involved.

    Voltage and current are already proportional (U=IR). You'll just have to choose whether you want to drive the "subject" with current or voltage, since other parameter will depend on his body resistance. Note that human body resistance is a complex parameter, and depends on multiple things. Skin resistance greatly varies from person to person, and for a single person it also highly varies with time. Roughly, it may be anywhere in 1K-100K range. If you shock your subjects with constant voltage (proportional to copied line count), you'll therefore get a very different response in different people. Don't forget the fact that when the skin is pierced and burnt by discharge, it's resistance drops to some hundreds Ohms, and with constant voltage, the current will momentarily increase by order of magnitude. If you don't want to spend your life in jail, it's best you then use constant current source, with limited maximum output voltage. But then, when you think that finally the solution is at hand, there is this fact that different people have very different pain perception. And the perceived pain isn't really linearly dependent on the current. So this machine would have to be very precisely tuned to each programmer, to produce pain in proportion to copied lines. Imagine how much time and resources this would take, not mentioning the hardware costs. What I'm saying is that you propose your solution, knowing nothing of the problems this solution would bring, which is kinda what management did in this article. Which is ironic. Why go to such great lengths as to install and tune some volatile, costly and potentially dangerous system, when you can simply install keylogger, which triggers on Ctrl+C and sends copied text to senior programmer, who then decides if and how much he should beat the bastard with "The Art of Computer Programming" (whichever volume he'll find fit for the occasion)?

Leave a comment on “Technical Debt”

Log In or post as a guest

Replying to comment #:

« Return to Article