• ray10k (unregistered)

    My knee-jerk reaction was, "Why not scrap the entire thing and rebuild from scratch," but from the sound of it, the company just didn't have the money to do that. Good on Gigi that she's looking for an escape, companies like that just won't improve, period.

  • Jayce (unregistered)

    Keep the job, continue the job hunt, leave the current job off the resume, pretend it never happened.

  • Zenith (unregistered)

    Prior to my current position, the last few years had me in several different development jobs. I know exactly what it feels like to look at the screen and seriously consider picking up your purse/briefcase and walking out the door. You just can't fix these problems. They're problems because management wants them to be problems. If you fight, then you will be labeled a villain and disposed of. The only sane course of action is to look for another job and pay closer attention at the interview this time. There's no shame in having been fooled; some of these places deliver Oscar-worthy performances.

    I love the ones with a tangled garbage mess of a program who want stuff fixed but are terrified to let you touch anything. They do not, however, exercise even the slightest bit of caution making breaking changes without telling you or checking in code that doesn't even compile. There's no NIH about it; this is why nobody wants to be a maintenance programmer.

  • (nodebb) in reply to ray10k

    companies like that just won't improve, period.

    Exactly. There's no saving a place that has gone this far without a clue. They will never, ever, get any good developer working for them, because anyone sane will see the issues and either realize the place is completely insane, or try to fix it and get fired/forced to quit for rocking the boat too much. Places like this will only ever attract the complete dregs of development work; those too clueless or ignorant to have any useful skills and can just coast along mediocrity until they burn out, retire or die.

  • (nodebb) in reply to Zenith

    "They're problems because management wants them to be problems."

    Not necessarily. They might be enduring problems because management doesn't see that they are problems, or doesn't want to see that they are problems. The villain thing (better to be labelled a villain than a villein, perhaps, although the two words have the same origin) won't be much different.

    And yeah, being a maintenance programmer does suck pretty hard at times. Like the time at the beginning of 1995 that my manager told me that he had been told that upper management thought our group was "over-valued". He was ... unsurprised ... when about two months later I handed in my notice.

  • MaxArt (unregistered)

    Products with something like 8800 bugs that developers can't keep up on solving should be rewritten from scratch. A small company simply can't deal with thousands of issues. Period. If they don't understand that, they're doomed.

  • (nodebb) in reply to Steve_The_Cynic

    Being a maintenance programmer sucks precisely for the reasons outline: You are never given the freedom to fix things in the right way, usually people are so paranoid about breaking something that it's always "don't change too much" and greatly restricting what you can and can't do, so you are expected to fix a leaky pipe while being explicitly told you can't replace the pipe, only put enough duct tape over the hole that it gets fixed.

    This is why companies like this are, as I said above, the complete cesspits of IT and will only ever attract the most worthless of dregs and the absolutely new people who need to get experience. Anyone smart or experienced will either see these places for the terrible jokes they are, or if they get suckered in (many of these places are only good at one thing: Putting on enough of a show to not look like clueless simpletons to deceive people) will quickly realize the truth and leave because they realize that it's too far gone to be fixed; the company has put off fixing things correctly for so long they have no way to fix anything short of a rewrite, which management almost never will want to approve, and as a result they have this miasma about the company where even daring to suggest a rewrite is enough to get you reprimanded, if not immediately fired; I seriously worked at a place where it was stated in no uncertain terms by the manager that it would be a VERY dangerous (job-wise) move to even utter the words "rewrite" in front of senior "leadership", no matter how bad things were.

    How places get this clueless is completely beyond my comprehension.

  • PZ42 (unregistered) in reply to Steve_The_Cynic

    That's because most non-technical people (i.e. upper-management/sales people/marketing people) do not understand or appreciate the work involved in anything actually remotely technical.

    Of course, these same people always think they are technical themselves because they know how to turn their computer on and browse websites. But I'm sure there is an subconscious belief in such people that development happens via some kind of strange magic or pixie dust or something.

    Given a new feature that a development department reckons will take 3 months to complete, these people genuinely seem to think that developers are merely being lazy and will all just sit around on their arses for 3 months before pressing the magic "make new feature" button on their magic keyboards

  • (nodebb)

    Is Monster the right place to look for programming jobs these days? Probably better to start with a good LinkedIn profile, no?

  • Shashank (unregistered)

    So? Gigi wants to have a perfect codebase and life should be all 'La La La..' so that she could come, sit in the office and leave happily? Great!

    Why did Gigi even think of becoming a programmer in the first place if she can't enjoy the work she's supposed to do? Only to continue to wonder that grass is greener on the other side which could be seen in 'That Another Ideal Job'?

    Either Gigi is not a programmer but is trying to be a programmer or this story could have been better with a few additions such as 'the boss wanted her not to touch anything more than just this one but wanted the product bug-free (void of all those 8,800 bugs) in the next 3 days' or such.

  • Sandman (unregistered) in reply to Jayce

    I had a job like that. Lasted 6 months and they gave me 2 weeks severance. I refer to it as the "Garbage Factory" because the "Director" got pissed whenever I tried to write rational code as opposed to following his ridiculous "patterns". Maybe one of these days, I can strike it from the resume.

  • EatenByAGrue (unregistered)

    I'm going to play devil's advocate for a moment: Scrapping and replacing an application that's big enough to have 8800 bugs is probably a more Herculean task than fixing the 8800 bugs. Especially since it's entirely possible that lots of the bugs might be related.

  • (nodebb)

    Aaannd... this is why companies should only hire people with at least some formal Computer Science education. Now, don't get me wrong, I am not saying that Computer Science graduates always use the most suitable pattern for the job, the best data structures for the job or that they write perfect code, but at least they have a general idea of how software is meant to work, so there are fewer chances of something like this ending up in your corporate software:

    " The first file created an object and a thread; the next file scheduled the thread in a private queue. The third class hooked the thread up to the button, while the fourth class caught button clicks and scheduled another thread to handle the event. There were a few more layers of passing data around between files, until finally, another thread was queued to destroy the object."

    Such code is the tell-tale sign of some hack whose programming education consists entirely some fly-by-night technical school or some seminar, and who treats the programming language and the programming environment as something that has to be randomly bent and twisted till a way of "getting it to work" has been found.

    Addendum 2017-02-14 10:57: So, to conclude, companies should only hire people with at least some formal Computer Science education to make sure that their code is at least refactorable, instead of a giant steam factory. Do those management types ever learn from each other, or is it considered a taboo in their circle?

  • Jerepp (unregistered)

    ...ummm.... seems to me from the story that a previous 'bug fix' was setting the background to red to 'cover-over' the flakey red text and then write the same text again over all of that in a font that sort of worked. Not only do you have 8800 outstanding bugs but I am guessing the the earth and turtles its bugs layered on bugs all the way down.

  • (nodebb) in reply to kurkosdr

    And you're assuming that everyone who doesn't have a formal CS education is going to write code like what you describe. I don't have a formal CS background (though I did take a few classes back in the day), and I would never write code like what you've described.

    To me what you described looks like SOLID (something one gets in CS classes, perhaps) gone wrong.

  • SolePurposeOfVisit (unregistered) in reply to jkshapiro

    Correct. The answer is "no."

  • Herby (unregistered)

    On hiring those that have a "formal education". Yes, they can understand the basics of how things should work, and hopefully they were taught that pasta code (of whatever type) is bad. Unfortunately there are a couple of flaws. First, people from competent schools usually cost a bit more, and second, there is no guarantee that they will in fact be competent in their field. The current trend in schools now is Java, and while that is nice, sometimes the experience can't be ported to another language easily. Yes, the competent person can do it, but there you go again, cost.

    As for bugs and the like, I am reminded of a project that I witnessed (I wasn't involved) many years ago. The project was "hurried" and the programmers just wanted to get something functional, so they whipped up bits and pieces that tried to work. They noted the "bugs" and went on, skipping over them, implying that they could come back at a later stage and fix them. The bugs piled up and the resulting mess was unworkable. They just said, we can't get it to work, it has a few bugs we know about, but we bypassed most of those. Then some intelligent person came on board, and insisted that the bug list be taken care of, and the program (it was a communication stack for two wildly different machines) slowly started to work. The "bugs we will take care of later" was most of the problem. Amazing what happens when you have adult supervision on a project, and not some person who "wants results" even if they are wrong. Then again, isn't that the case in many WTFs encountered here.

  • Jacob (unregistered)

    TRWTF is how much of a quitter Gigi sounds like. Slogging through crazy legacy code and trying to improve it is normal - if you can't manage that, and only want to write brand new code... well, you're not going to last long in this industry.

  • dpm (unregistered) in reply to Jacob

    (jacob) She wants to improve it but isn't allowed to. Remember the bit about being told not to touch any other code?

  • Dreayt (unregistered) in reply to Jacob

    I totally agree with you. I cannot see any other WTF here.

  • Zenith (unregistered) in reply to EatenByAGrue

    With 8800 bugs, the question is whether there's enough that's not broken to salvage.

  • CrazyEyes (unregistered) in reply to PZ42

    From what I've learned, the mentioned undesirable type of manager treats developers this way for a couple of reasons:

    1. (This one I know for sure) They don't think that developers "create value." The work that developers do for the company is frequently not easily translatable into a definite sum of earned profit, therefore, it must not be that valuable. This logic frequently takes hold in companies whose flagship product or service is not directly software related (and frequently even when it is; a good example is banks, where most modern transactions are performed digitally). This is the same reason that software companies go to shit over time, because sales executives eventually pack the board, since they get more promotions for "bringing in revenue."

    2. I personally believe there has to be at least one other reason, but I'm not entirely sure what it is yet. My rationale is that not everyone on the executive board can be a complete idiot who believes in 1) all the time, or at least, it's pretty unlikely. I think it may have something to do with the fact that developers look like they're having more fun at work? I honestly have no idea.

  • Zenith (unregistered) in reply to DocMonster

    Doc, why do I get the feeling that you've worked for some of the places that I've worked?

  • Earp (unregistered) in reply to kurkosdr

    I've seen some AMAZING CS grads, as in, super bright, can code anything, in any language, and are able to think about how to do things they dont know already. I've also worked with many CS grads who couldn't code anything worth a damn. While having a CS degree certainly shows they should know something, its rather unamusing how many choke on the simplest of tasks outside their immediate experience, and seem unable to think for themselves at all. I'm not sure if they bought their degrees, had other people do their assignment, or their degree was simply worthless, but when I have a phd in my team under me, and I have no formal training, it shows that its not an absolute indicator of competence.

  • Daniel Shuy (unregistered) in reply to kurkosdr

    My company has CS grads who can't even write a simple for loop.

    Sure, having a CS degree gives you a head start, but I think if someone has the desire to continuously learn and improve themselves, they will be able to figure out the right way, even if they are working for a company that uses shoddy practices, especially in this age where almost any information can be found online.

    The problem arises when people think that they already know enough, and refuse to learn anymore or even be corrected by others ("The Expert Beginner"). This is amplified in companies like the one in this article, where the good talents will not stay for long, leaving behind these people ("The Dead Sea Effect"), who are eventually promoted to management. These people will then enforce their practices, not with evidence, but with seniority. Then, any new hire without the desire to learn, will just blindly follow their practices, thinking that its the right way as well. This results in a vicious cycle, where anyone that tries to challenge their practices will be met with heavy resistance, and will be forced to assimilate, or leave the company.

  • Wernsey (unregistered)

    TRWTF today is the number of people bashing on Gigi for being a quitter.

    Seriously, if I was staring at 8800 bugs to fix and knew that tomorrow there'll be only 8799 bugs remaining, it would crush my soul.

    Especially if they were as convoluted as the ones described in the article.

  • (nodebb)

    "I'm not sure if they bought their degrees, had other people do their assignment, or their degree was simply worthless, but when I have a phd in my team under me, and I have no formal training, it shows that its not an absolute indicator of competence."

    Well, with so many job interviewers not bothering to check if the degrees are actually from an accredited university (and not a bunch of Chinese guys in a basement cranking out fancy parchments for mail-order degrees), I wouldn't be surprised if those people literally bought their degrees.

    Now, as I 've said, a degree is not an ultimate indicator of competence. But, they have to learn something to get the degree (the Sokal affair prevented the liberal arts majors from messing STEM degrees, so they haven't managed to mess those up) , so the chances a graduate will WTFs like the one I quoted in the previous post are far fewer.

    Of course, there is always the case of someone without a degree having learned everything himself and be an excellent software engineer and coder, and thus requiring a degree will single out those guys.

    BUT, you know what, there is a reason they are not letting people without a medical degree pose as doctors, despite the fact there will be the occasional dude who learned correct medicine by himself.

  • Paul Neumann (unregistered) in reply to kurkosdr

    The elitism is very high with this one!

    job interviewers not bothering to check if the degrees are actually from an accredited university

    Yeah, that's the reason for all of the well accredited yet poorly implemented developers -- they don't have a real degree. A real degree holder could never write bad code.

    prevented the liberal arts majors from messing STEM degrees

    So apparently an AA, BA or MA isn't a real degree. They don't really learn stuff anyway.

    BUT, you know what, there is a reason they are not letting people without a medical degree pose as doctors

    Yeah, because you writing your latest AppStore junk is just as important as the guy treating cancer and the gal massaging a bare heart back to life. Get over yourself!

    despite the fact there will be the occasional dude who learned correct medicine by himself

    Excepting the edge case of people make their own decisions as when to seek care for themselves or their charges, I'm willing to bet the ability of those in the tech field is much more evenly distributed than those in the fields of medicine vs. quackery.

  • Gus (unregistered) in reply to Jacob

    Perhaps you missed the part about "at least 3 layers of bugs" and the admonition to make "minimal changes".

  • Zenith (unregistered) in reply to Gus

    You should see some of the code at the local insurance company. It looks like really bad scientific code, where data is "fixed" and "unfixed" at several stages to work around bugs that nobody wants to understand, let alone correct. In cases where a conditional was dependent on half a dozen (or more) properties, they refused to put it into a function no matter how many times it was repeated. When a fixer was wrong, the unfixer had to detect how much of the middle component to reinvent or refix and reprocess without warping the results further. It was just patchwork like that all the way down.

    And then you have this kind of clown attempt to lecture other developers about best practices as if they'd know what a clue even looked like if they ever saw one.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    "Don't touch unrelated code" isn't a bad request for someone just getting their toes wet with a bear of a code base. But if I was going to be expected to maintain that code, I'd make damn sure that I would be allowed to be The Guy, allowed to make some serious maintainability changes, and have the occasional screw-up be tolerated. That could even be fun. I've done it before, too.

    But if there's already a "The Guy" who allowed the code to reach that Lovecraftian level of horror, I'd listen to The Doctor when he says RUN!

  • (nodebb)

    CS degrees aren't all equivalent and therefore fungible, so that the term "CS graduate" manages to convey what the holder was taught (let alone what they learned). It's not like "airline pilot", which implies that certain industry-mandated standards have been met. It's more like "most valuable player" in that it means whatever the hell the bestower feels like making it mean.

    I did minor in CS, but what was taught in that subject was computer science (hence the name), not software engineering - that was another school entirely. There was a C compiler available in the students' workspace alongside the usual suspects (like Prolog), and it was just assumed that you'd be able to use it should you have a mad posh for writing something in the course of your studies. But as far as the teaching of CS was concerned, actually implementing a parser generator was kind of missing the point.

  • Dave (unregistered)

    I'm genuinely shocked that people here are so ivory-tower that they don't understand why this stuff happens. It's pretty simple. The reason management tolerates the code-base is that in practice it doesn't actually matter much. Sure, the reason the text displays a bit funny on a red background is ridiculous, but the text displaying a bit funny doesn't cost the business anything.

  • Gus (unregistered) in reply to Dave

    Well, actually, it was a huge deal, as there is an actual US LAW that mandates that this particular displayed text be visible and readable.

  • (nodebb) in reply to Jayce

    Keep the job, continue the job hunt, leave the current job off the resume, pretend it never happened.

    There's no point in including it on the resume, and no point in covering it up either.

    The big contract fell through, they were nice enough to keep you employed, but it became clear the company was overstaffed, and you made a mutually-beneficial decision to leave.

    You show concern for your employer's well-being, and maturity to deal with the natural reversals that happen in business.

  • Mike Waters (unregistered) in reply to kurkosdr

    "Well, with so many job interviewers not bothering to check if the degrees are actually from an accredited university (and not a bunch of Chinese guys in a basement cranking out fancy parchments for mail-order degrees), I wouldn't be surprised if those people literally bought their degrees."

    Very true, my favorite from some 30 years ago was my "Doctor of Divinity in Computer Science" which I bought as a gag. looks very fancy too. Everyone in the office thought it was great fun until some halfwit from HR saw it on my wall and put me in for an "appropriate promotion fitting my new qualifications"!

    By the time I found out about this (and my boss 10 minutes later!) it had gone into the rarefied "upper management" ranks for approval and HR was NOT about to admit that they had been fooled!

    Noting actually came of it, but it was a great gag to remember for years afterwards.

    Oh yes FWIW I have REAL BSEE (1968) and BSCS (1979) degrees and have been retired for more than 20 years.

  • NN1 (unregistered)

    I would advise management that this codebase was in a state that it should be burned to the ground and rebuilt from scratch. I wouldn't expect them to go for that, but it is something that they should hear.


  • MitchG (unregistered)

    The idea that education = competence is ridiculous. We've all met useless programmers with CS degrees. The problem, as always, starts at management. If they aren't getting people in (at any stage) who are competent enough to do it correctly, then they are not paying enough or are just plain bad at their jobs.

    Obviously, if some person is over their head and starts building an application with painful spaghetti code (CS grad or not), they share in the blame. But I can safely say from my own experiences that management will just say "that's ok, just get it done", because they don't want to hire anyone more expensive.

    Ridiculously, I went from a History Degree, to a GIS Degree, to eventually working successfully as a programmer. There is some code I wrote in my early GIS days, that is just embarrassing, but the message was always "just get it to work", and I was always replacing even worse code/applications. CS education programmers I work with every day, show me some of the things they wrote early in their career and it looks just as bad or worse.

    In a weird way, building workable garbage was my education. Maybe I just disproved my own point? hah

Leave a comment on “What Bugs Beneath”

Log In or post as a guest

Replying to comment #:

« Return to Article