• MP79 (unregistered)

    I've never understood why people are incapable of seeing why their code is bad when it's staring them in the face

  • masseyis (unregistered)

    frist = null

  • bubble (unregistered)

    public static string ScrubFrist(string comment) { string newComment = string.Empty; if (string.IsNullOrEmpty(comment)) newComment = null; else newComment = comment; return newComment; }

  • (cs) in reply to MP79
    MP79:
    I've never understood why people are incapable of seeing why their code is bad when it's staring them in the face

    Ignorance? Arrogance? Who knows. I've seen a lot of crappy code written by people who should have known better but were too lazy to actually try, they just wrote the first thing they could think of to finish the task and then move on to the next one.

  • (cs)

    There is a certain therapeutic satisfaction in having a job that consists of cleaning up shit code. It's like an academic exercise:

    "Question 1: a) Identify the aspects of this code which fall short of optimum. b) Implement improvements for these areas of concern. (40 points)

    Question 2: For the improvements implemented in question 1: a) estimate or calculate: i) the percentage improvement in run-time ii) the percentage improvement in size of codebase

    b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."

  • pay me to comment (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Ignorance? Arrogance?
    Money.
  • pay me to comment (unregistered) in reply to Matt Westwood
    Matt Westwood:
    b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    Oh yeah. She'll totally enjoy feeling up your wallet.
  • Askimet (unregistered)

    Without knowing C#, would the following work?

    public static string ScrubString(string stringToScrub) {
      return (stringToScrub == string.Empty ? null : stringToScrub);
    }
    
  • QJo (unregistered)

    I can't even comprehend what was the motivation behind this code's existence.

    "Oh look, sometimes when someone enters an empty string it goes ahead and does something we haven't got time to go into the codebase to work out. Shall we just make sure that when anyone enters nothing into a mandatory field we invoke a null pointer exception? Then we'll be able to catch it and feed the stack dump back to the user. That'll work."

  • RFoxmich (unregistered)

    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Question 2: b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    The answer to the last part is still 0. It was zero before and is still zero. She has her eye on that charmer in Sales.
  • noone (unregistered) in reply to Askimet

    yes. however given the original function your function should utilize string.isNullOrEmpty

  • minusSeven (unregistered) in reply to MP79
    MP79:
    I've never understood why people are incapable of seeing why their code is bad when it's staring them in the face

    This is rather hard when it is YOUR code. Every one else code usually stinks anyway !

  • (cs) in reply to Nutster
    Nutster:
    Matt Westwood:
    Question 2: b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    The answer to the last part is still 0. It was zero before and is still zero. She has her eye on that charmer in Sales.
    (*quivering chin*) (*sob, sniff*)
  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Nutster:
    Matt Westwood:
    Question 2: b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    The answer to the last part is still 0. It was zero before and is still zero. She has her eye on that charmer in Sales.
    (*quivering chin*) (*sob, sniff*)

    ... actually I have it on good authority that the charmer in Sales is already married and has three children (all with different women, none of which is his wife, who is built like a brick shithouse and has been known to hospitalise her rivals). If the cute brunette wishes to continue with her less-than-sensible course of action and thus risk life limb and happiness, then she's not the girl for me, I thought she was more sensible than that. On the other hand, if she is open to listening to reason, and would prefer a straight-up guy who actually knows how to fix things, not just fuck them, then hey, how about it, babe?

  • Dave (unregistered) in reply to RFoxmich
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    TRWTF is Joel's URLs.

  • faoileag (unregistered) in reply to QJo
    QJo:
    I can't even comprehend what was the motivation behind this code's existence.
    A bad attempt at memory consumption optimization? Strings in C# are reference types.
    string a = "";
    string b = a;
    
    String b now has a reference to string a; string a can't be garbage collected.
    string a = "";
    string b = ScrubbingBubble.ScrubCustomerName(a);
    

    String b now is null, the connection with string a has been severed. String a can now be garbage collected.

    Still a rather costly way to do this;

    string b = string.IsNullOrEmpty(a) ? null : a;
    

    would be more concise and would not necessitate the creation of a temporary object.

  • Oslo (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    they just wrote the first thing they could think of to finish the task and then move on to the next one.

    Isn't that just how TDD ends up working?

  • faoileag (unregistered) in reply to minusSeven
    minusSeven:
    MP79:
    I've never understood why people are incapable of seeing why their code is bad when it's staring them in the face
    This is rather hard when it is YOUR code. Every one else code usually stinks anyway !
    So that's the reason we never see stories like: "I have just coded <insert_some_function> and I made such a collection of wtfs of it, I wanted to share these with the wonderful community of TDWTF!"...
  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    ... they just wrote the first thing they could think of to finish the task ...

    If that's genuinely the case here, then TRWTF is that someone decided that the data scrubbing logic was "If the string is null or empty, make sure it's null, otherwise just use the string as-is".

    I have to admit I once invoked code that involved something like

    if (String.IsNullOrEmpty(input)) input = string.Empty;
    but only because in that situation passing an empty string produced more consistent behaviour than passing null. And I didn't call it 'Scrub' anything... ;)

  • Herwig (unregistered) in reply to pay me to comment
    pay me to comment:
    ObiWayneKenobi:
    Ignorance? Arrogance?
    Money.
    Yep. It's all like in my current project: We've got too much money. Therefore we can afford this bullshitty big ball of mud.

    captcha: oppeto. As far as I remember oppedo (Latin) means "I fart"

  • QJo (unregistered) in reply to Dave
    Dave:
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    TRWTF is Joel's URLs.

    Who cares? He talks extremely good sense. I recommend his blog to all my staff.

  • fristman (unregistered) in reply to faoileag
    faoileag:
    QJo:
    I can't even comprehend what was the motivation behind this code's existence.
    A bad attempt at memory consumption optimization? Strings in C# are reference types.
    string a = "";
    string b = a;
    
    String b now has a reference to string a; string a can't be garbage collected.
    string a = "";
    string b = ScrubbingBubble.ScrubCustomerName(a);
    

    String b now is null, the connection with string a has been severed. String a can now be garbage collected.

    Still a rather costly way to do this;

    string b = string.IsNullOrEmpty(a) ? null : a;
    

    would be more concise and would not necessitate the creation of a temporary object.

    Strings are interned anyway, so there's probably not much memory to save (yes, you can disable string interning, but that's rarely a good idea)

  • Fredegar (unregistered)

    In C# is it considered good practice to set strings to NULL instead of empty?

    TRWTF is the management policy of rating programmers by Lines Of Code produced. This is why they have an entire contingent of redundant scrubbers, instead of a one line function for all strings.

  • (cs) in reply to Fredegar
    Fredegar:
    In C# is it considered good practice to set strings to NULL instead of empty?

    Depends what you're going to do with the string :p

    No, seriously. It's entirely contextual. AFAIK there's no real advantage one way or the other (except perhaps for consuming code, which would know whether it needed to check for null, Empty, or both. Then again, that would rely on the code documenting whether it returned null, or Empty, or either (arbitrarily), which given the quality of this code, seems unlikely).

  • Anonymous Paranoiac (unregistered) in reply to Fredegar
    Fredegar:
    In C# is it considered good practice to set strings to NULL instead of empty?

    TRWTF is the management policy of rating programmers by Lines Of Code produced. This is why they have an entire contingent of redundant scrubbers, instead of a one line function for all strings.

    Alternately,

    Management: "What do you mean you're scrubbing all data the same way?! Everybody knows that you can't scrub a customer name the same way you scrub a phone number - they're completely different! Now stop being lazy and go back and do it right this time!"

  • Anonymous Paranoiac (unregistered) in reply to faoileag
    faoileag:
    minusSeven:
    MP79:
    I've never understood why people are incapable of seeing why their code is bad when it's staring them in the face
    This is rather hard when it is YOUR code. Every one else code usually stinks anyway !
    So that's the reason we never see stories like: "I have just coded <insert_some_function> and I made such a collection of wtfs of it, I wanted to share these with the wonderful community of TDWTF!"...

    Well, it's hard to see the WTFs in your own code in part because when you write the code, it (hopefully) makes perfect sense to you and you have the full context of the project loaded in memory.

    It's when you come back six months (or sometimes even a few days/weeks) later and the contextual memory in your brain has been overwritten many times that the WTFs start jumping out at you.

    If you can't spot WTFery (or, at minimum, things that could have been done better) in your own well-aged code, then you seriously need to work harder on improving your skills.

  • (cs) in reply to faoileag
    faoileag:
    QJo:
    I can't even comprehend what was the motivation behind this code's existence.
    A bad attempt at memory consumption optimization? Strings in C# are reference types.
    string a = "";
    string b = a;
    
    String b now has a reference to string a; string a can't be garbage collected.
    string a = "";
    string b = ScrubbingBubble.ScrubCustomerName(a);
    

    String b now is null, the connection with string a has been severed. String a can now be garbage collected.

    Still a rather costly way to do this;

    string b = string.IsNullOrEmpty(a) ? null : a;
    

    would be more concise and would not necessitate the creation of a temporary object.

    Not quite right, faoileag. The .Net optimizer will convert the string constant "" to a reference to a predefined static (string.Empty), so there is no issue here. Also, variable a can indeed be "garbage collected" regardless of the value it was set to. however the memory referenced must still remain since another object still references it.

  • Withnail (unregistered)

    Throw yourselves into this video, to escape all this hideousness... you'll love it, you little tarts:

    http://www.youtube.com/watch?v=WYDlX49yUSI

  • (cs) in reply to JimM
    JimM:
    Fredegar:
    In C# is it considered good practice to set strings to NULL instead of empty?

    Depends what you're going to do with the string :p

    No, seriously. It's entirely contextual. AFAIK there's no real advantage one way or the other (except perhaps for consuming code, which would know whether it needed to check for null, Empty, or both. Then again, that would rely on the code documenting whether it returned null, or Empty, or either (arbitrarily), which given the quality of this code, seems unlikely).

    Correct...and sometimes you even have to set them to: DBNull.Value

  • RuBen (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Matt Westwood:
    Nutster:
    Matt Westwood:
    Question 2: b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    The answer to the last part is still 0. It was zero before and is still zero. She has her eye on that charmer in Sales.
    (*quivering chin*) (*sob, sniff*)

    ... actually I have it on good authority that the charmer in Sales is already married and has three children (all with different women, none of which is his wife, who is built like a brick shithouse and has been known to hospitalise her rivals). If the cute brunette wishes to continue with her less-than-sensible course of action and thus risk life limb and happiness, then she's not the girl for me, I thought she was more sensible than that. On the other hand, if she is open to listening to reason, and would prefer a straight-up guy who actually knows how to fix things, not just fuck them, then hey, how about it, babe?

    1. Ignore all previous possible scenario's and simply go talk with her (0 or 100 points)
  • (cs) in reply to QJo
    QJo:
    Dave:
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    TRWTF is Joel's URLs.

    Who cares? He talks extremely good sense. I recommend his blog to all my staff.
    In this particular case, what he says lacks a very important caveat, and it is as if he doesn't even realise it.

    Specifically, sometimes the old codebase CANNOT accept a very important change. The example I think of is when the old codebase, whatever its faults, cannot be ported cleanly, if at all, to a new platform. Imagine a crufty(*), brittle codebase that is heavily tied to use of COM / DCOM interfaces between components, and deep-juju Win32 threading weirdness. Now imagine that a major(**) customer says, "We love the product, but no Windows in our datacentre please. Linux is fine, but not Windows."

    What do you do? Throw away the customer and rely on the one other customer you actually have?(*) Write a DCOM emulation layer for Linux, including support for all the marshalling madness, custom moniker implementations(**), and so on? Rewrite the code so that it is portable to any platform with a TCP/IP layer?

    Bear in mind, in passing, that one GUI-less network server component had been written in VB6, for reasons that continue to defy my capacity to imagine any justification for such a thing.

    No, in this case you rewrite it. The old codebase was brittle, and had extensive multithreaded locking / object lifetime management issue. It would crash and burn accessing deleted objects, or it would deadlock nine ways to Sunday at the slightest opportunity. If it got busy, it would sometimes fail when Win32's 2GB user address space was full of thread stack space, somewhere around 1500 threads(!).

    The new codebase was largely platform independent, aside from a portability layer, and single threaded. I worked on the architecture of it with a colleague who had previously worked on routers at DEC, and as a result of his experience, we had a model that never completed anything in-line, but posted delayed callbacks (overlapped I/O style) to all requests. No code was allowed to block for any reason. The new code base came up and working in about half the time the previous one took, and just worked. It never deadlocked, nor did we ever have problems with long-term leaks, nor objects dying before their time.(*****) Furthermore, we also had ports of the platform layer for Win32, Linux, FreeBSD, OpenBSD, and VxWorks.

    () It was crufty despite being less than three years old with only one production release. Go figure. () I.e. one of two, an ISP (the other being a California school district) () See (**). My company was a dotcom startup that eventually stopdowned, but not until late 2003. Complicating its continued existence was a tendency to sack almost the entire marketing and sales crew at intervals of 18 months or less, and what I suspect was poisonous jealousy on the part of the co-founder-CTO of some inventions that came from developers (me, mostly, if you must know). (****) Custom monikers aren't so bad in and of themselves, but the IMoniker API documentation is vague, unclear, and in some places just plain wrong. Or maybe it's right, but if so, Microsoft's ROT viewer doesn't follow the API as written.

    (*****) The code was C++, and we had a set of intrusive dual refcount classes, combined with two types of reference objects. 'Intrusive' means simply that the refcounts were stored in the objects themselves. When the "action" refcount went to zero, a mandatory "deactivate" method was called. When both refcounts went to zero, the object deleted itself. ("delete this;" is perfectly valid C++, but a bit dangerous if you aren't careful. It makes a good technical interview question for non-beginner candidates.) Errors in the deactivate method tended to result in leaking thousands of objects, but all active objects were linked together by a double-linked list maintained by the refcount holder base class, and a diagnostic routine would dump a list of objects that were left behind. It was considered good practice to call it at the end of main(), after scrubbing all remaining references.

  • Wrexham (unregistered) in reply to Anonymous Paranoiac
    Anonymous Paranoiac:
    If you can't spot WTFery (or, at minimum, things that could have been done better) in your own well-aged code, then you seriously need to work harder on improving your skills.
    Nonsense, every line of code I've ever written was perfect first time.

    ...I wish.

  • (cs) in reply to RuBen
    RuBen:
    Matt Westwood:
    Matt Westwood:
    Nutster:
    Matt Westwood:
    Question 2: b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    The answer to the last part is still 0. It was zero before and is still zero. She has her eye on that charmer in Sales.
    (*quivering chin*) (*sob, sniff*)

    ... actually I have it on good authority that the charmer in Sales is already married and has three children (all with different women, none of which is his wife, who is built like a brick shithouse and has been known to hospitalise her rivals). If the cute brunette wishes to continue with her less-than-sensible course of action and thus risk life limb and happiness, then she's not the girl for me, I thought she was more sensible than that. On the other hand, if she is open to listening to reason, and would prefer a straight-up guy who actually knows how to fix things, not just fuck them, then hey, how about it, babe?

    1. Ignore all previous possible scenario's and simply go talk with her (0 or 100 points)

    Whee! I've got a date!

  • faoileag (unregistered) in reply to Auction_God
    Auction_God:
    Not quite right, faoileag.
    And where exactly would I be wrong?
    Auction_God:
    The .Net optimizer will convert the string constant "" to a reference to a predefined static (string.Empty), so there is no issue here.
    That's why I didn't bother with typing string.Empty.
    Auction_God:
    Also, variable a can indeed be "garbage collected" regardless of the value it was set to.
    I never said it couldn't - the reference counter is what counts for the garbage collector.
    Auction_God:
    however the memory referenced must still remain since another object still references it.
    Yes, of course. But that's the look-up-table for string internment and that's outside of the scope of my two examples. And probably nothing the coder of the scrubbing functions had in mind as well :-)
  • EvilSnack (unregistered) in reply to RFoxmich
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    A full rewrite is not always evil.

    Sometimes the initial assumptions made during the design phase are utterly wrong and have led development down a path where even minor changes cause problems.

    Sometimes a regime of short-sightedness has led to an application being patched and re-patched, without regard for the overall design, to the point that the overall design is hardly discernible.

  • Tim (unregistered)

    well the name is misleading and the effect could be done by a simple ?: operator but other than that I don't see much wrong with this code at all.

    if you want to treat empty strings as if they were null it's a perfectly reasonable function to write

  • Pock Suppet (unregistered) in reply to MP79
    MP79:
    I've never understood why people are incapable of seeing why their code is bad when it's staring them in the face
    Because while many people make decent programmers, not very many make decent developers. Plenty of people can do a decent job maintaining an existing codebase, but they come up with the most off-the-wall solutions when writing from scratch.

    Naturally, those than can't program at all end up in management telling the rest of us how to do it (wrong) and accepting the accolades when we do it (right).

  • boB (unregistered) in reply to QJo
    QJo:
    I can't even comprehend what was the motivation behind this code's existence.

    I was assuming the code was written as a simple stub with the idea that "we'll come back and fill in the guts later, with real data cleaning and validating and sanitizing when we have time." Of course, that never ever happened.

  • Pock Suppet (unregistered) in reply to EvilSnack
    EvilSnack:
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    A full rewrite is not always evil.

    Sometimes the initial assumptions made during the design phase are utterly wrong and have led development down a path where even minor changes cause problems.

    Sometimes a regime of short-sightedness has led to an application being patched and re-patched, without regard for the overall design, to the point that the overall design is hardly discernible.

    This. Sometimes the original code is, in fact, a moldering pile of lice-infested crap with a side of open pustules, and years of feature requests have merely stapled new appendages to the existing rotting corpse. Sometimes the person who wrote the original code had never heard of best practices or even good practices, thought that "code reuse" meant "copy-paste", delighted in over-complicated systems with dozens of tightly-coupled interlinked moving parts, enjoyed storing variables in global space in one file and using their contents in another, and never met a Rube Goldberg machine they couldn't top with any random 15-line snippet from their current project. Some programmers -suck-, and the rest of us have to deal with their code base.

    Also, programming environments become...outdated. The first programming job I had was maintaining code written in and around a (multi-valued, not relational) database system that was designed in 1968. It uses upper ASCII characters for field delimiters, and that caused great Fun when dealing with non-American customers. It's limited to ASCII characters, so no Unicode - in the event that Unicode support becomes necessary (which is pretty likely, given their customer base), the entire code base will require a rewrite on some other platform.

  • (cs) in reply to EvilSnack
    EvilSnack:
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    A full rewrite is not always evil.

    Sometimes the initial assumptions made during the design phase are utterly wrong and have led development down a path where even minor changes cause problems.

    Sometimes a regime of short-sightedness has led to an application being patched and re-patched, without regard for the overall design, to the point that the overall design is hardly discernible.

    You've nailed one of the problems I have with Joel On Software. He tends to be very dogmatic, seeing everything in black and white, whereas the real world tends to be in shades of grey. A good software engineer has to be pragmatic and apply the right levels of the right principles to a given situation.

    The other (which is a more specific case of the above) is that he seems to have a lot of contempt for his users, feeling that they are idiots who should be led down specific paths. I know it's usual to user-bash here, but there are cases where you need to cater to the idiots while allowing for the intelligent users, and Joel doesn't seem to get that.

  • zbxvc (unregistered) in reply to Steve The Cynic
    Steve The Cynic:

    The new codebase was largely platform independent, aside from a portability layer, and single threaded. I worked on the architecture of it with a colleague who had previously worked on routers at DEC, and as a result of his experience, we had a model that never completed anything in-line, but posted delayed callbacks (overlapped I/O style) to all requests. No code was allowed to block for any reason. The new code base came up and working in about half the time the previous one took, and just worked. It never deadlocked, nor did we ever have problems with long-term leaks, nor objects dying before their time.

    Could you share some more details about the model? I'm interested mostly because:

    • in my experience (probably different domain, or just wrong kind of experience ;) ) most multithreading issues turned out to be caused by not doing as much as possible "inline" (and using excessive number of threads, but this aspect seems common to both cases, yours and mine),

    • I don't quite understand (and would like to) how it was single threaded and couldn't block: the main() function would need to use 100% CPU or return immediately when there is nothing to do, wouldn't it? (Or is it how it was supposed to work, i.e. do what is to be done and exit? Perhaps I wrongly assumed that it was a kind of a server app that was supposed to react to external requests...)

  • (cs) in reply to zbxvc
    zbxvc:
    Steve The Cynic:

    The new codebase was largely platform independent, aside from a portability layer, and single threaded. I worked on the architecture of it with a colleague who had previously worked on routers at DEC, and as a result of his experience, we had a model that never completed anything in-line, but posted delayed callbacks (overlapped I/O style) to all requests. No code was allowed to block for any reason. The new code base came up and working in about half the time the previous one took, and just worked. It never deadlocked, nor did we ever have problems with long-term leaks, nor objects dying before their time.

    Could you share some more details about the model? I'm interested mostly because:

    • in my experience (probably different domain, or just wrong kind of experience ;) ) most multithreading issues turned out to be caused by not doing as much as possible "inline" (and using excessive number of threads, but this aspect seems common to both cases, yours and mine),

    • I don't quite understand (and would like to) how it was single threaded and couldn't block: the main() function would need to use 100% CPU or return immediately when there is nothing to do, wouldn't it? (Or is it how it was supposed to work, i.e. do what is to be done and exit? Perhaps I wrongly assumed that it was a kind of a server app that was supposed to react to external requests...)

    In essence, main() did some application-specific setup including opening listening sockets(*) or outbound client->server connections, then entered a big loop that blocked waiting for network traffic to arrive. main(), or rather the callback scheduler, was, of course, allowed to block, but callbacks were not. If your callback needed to send a message and wait for a response, or connect a TCP connection, or whatever, it initiated the action, then returned back to the scheduler. When the receive completed, or the TCP connection completed/failed, the network layer(*) sent back a notification in the form of a callback. The scheduler had timers that you could get notifications from, using, as you might guess, callbacks.

    There was a callback proxy-stub generator that read descriptions of interfaces so that you didn't have to write the boring boilerplate code to post result notifications back to calling objects.

    There are four main sources of threading-specific problems that I've seen in threaded code:

    • Deadlocks of all types, including the notorious self-deadlock, where the thread that must process the request you've posted is the one you're in, but you've blocked waiting for it to be processed.
    • Not enough locking causing all manner of nasty race-condition bugs, and often leading to the third problem:
    • Using objects that have been deleted by other threads. This is more of a problem with C and C++ than with, say, Java or C#, but it's a problem nonetheless.
    • In attempting to prevent the third category of problems, you overshoot and fail to delete the objects when you should.

    It's possible, as we did in the old system, to have all four categories of bug, even in the same pair of objects.

    (*) The network layer was designed to be saner to program than the normal sockets API, with different objects for TCP connections, TCP listeners, and UDP listener-senders. Inside, it used a platform-specific layer to adapt to the specifics of the sockets API on the different platforms (or, even, the fact that a particular platform had a different API). There were subtle differences between the BSDs and Linux because of silly things like FreeBSD's unique (among the platforms we tried) behaviour of completing to-localhost connect() calls for non-blocking TCP sockets in-line rather than failing with EWOULDBLOCK.

  • (cs) in reply to RFoxmich
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    Sometimes the code is so bad, and so intertwined that you can't easily fix it because you'd end up in a rat's nest of having to fix module A, but module A depends on Module B which needs to be fixed first, which needs Module C, and so on until you have to fix everything to fix everything.

    Better in that case to declare "technical bankruptcy" and start from scratch.

  • El Guaco (unregistered) in reply to Pock Suppet
    Pock Suppet:
    EvilSnack:
    RFoxmich:
    TRWTF is a full rewrite rather than fixing

    http://www.joelonsoftware.com/articles/fog0000000069.html

    A full rewrite is not always evil.

    Sometimes the initial assumptions made during the design phase are utterly wrong and have led development down a path where even minor changes cause problems.

    Sometimes a regime of short-sightedness has led to an application being patched and re-patched, without regard for the overall design, to the point that the overall design is hardly discernible.

    This. Sometimes the original code is, in fact, a moldering pile of lice-infested crap with a side of open pustules, and years of feature requests have merely stapled new appendages to the existing rotting corpse. Sometimes the person who wrote the original code had never heard of best practices or even good practices, thought that "code reuse" meant "copy-paste", delighted in over-complicated systems with dozens of tightly-coupled interlinked moving parts, enjoyed storing variables in global space in one file and using their contents in another, and never met a Rube Goldberg machine they couldn't top with any random 15-line snippet from their current project. Some programmers -suck-, and the rest of us have to deal with their code base.

    Also, programming environments become...outdated. The first programming job I had was maintaining code written in and around a (multi-valued, not relational) database system that was designed in 1968. It uses upper ASCII characters for field delimiters, and that caused great Fun when dealing with non-American customers. It's limited to ASCII characters, so no Unicode - in the event that Unicode support becomes necessary (which is pretty likely, given their customer base), the entire code base will require a rewrite on some other platform.

    That sounds like a PICK database. My first professional job used a PICK "multi-valued" record system. Not terrible, but less than ideal. But the real kicker was that we ran into the memory limit for executables for our main application. The "OS" was running on top of Windows NT on a 486 (50MHz!) with 4MB of RAM, but the "OS" wouldn't permit an exe over 32K.

    The app was a spaghetti nightmare of UI code mixed with business logic. I was forced to rewrite most of the code in order to extract all data access into a separate application so that the main application could handle the UI and business logic. Ultimately, this failed to meet our needs and we rewrote it again in Visual Basic and used the PICK database/OS merely as a data store. I left the company, but they allegedly spent years trying to migrate to SQL.

    Sometimes, you gotta bury bad code and start fresh. Not because it offends your sensibilities, but because it simply doesn't work.

  • RomeoVoid (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Matt Westwood:
    Nutster:
    Matt Westwood:
    Question 2: b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    The answer to the last part is still 0. It was zero before and is still zero. She has her eye on that charmer in Sales.
    (*quivering chin*) (*sob, sniff*)

    ... actually I have it on good authority that the charmer in Sales is already married and has three children (all with different women, none of which is his wife, who is built like a brick shithouse and has been known to hospitalise her rivals). If the cute brunette wishes to continue with her less-than-sensible course of action and thus risk life limb and happiness, then she's not the girl for me, I thought she was more sensible than that. On the other hand, if she is open to listening to reason, and would prefer a straight-up guy who actually knows how to fix things, not just fuck them, then hey, how about it, babe?

    Re:" If the cute brunette wishes to continue with her less-than-sensible course of action and thus risk life limb and happiness, then she's not the girl for me, I thought she was more sensible than that. On the other hand, if she is open to listening to reason, and would prefer a straight-up guy who actually knows how to fix things, not just fuck them, then hey, how about it, babe?" -- story of my life, they always continue with the less-than-sensible course of action...

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    Furthermore, we also had ports of the platform layer for Win32, Linux, FreeBSD, OpenBSD, and VxWorks.
    A secondary point here: We did Win32 and Linux first to get down the discipline of writing application code (above the top of the platform layer) in a portable way. When bringing up the rest of the target platforms over time, we discovered one hiccough on OpenBSD, where someone had written functions SomeClass::ntohs(x) and friends, and managed to inherit one of the OpenBSD .h files, where ntohs and friends are macros... We also had one on VxWorks, which was stuck on an antique version of gcc (2.95 ffs!) that didn't handle anonymous namespaces correctly.

    Aside from those two issues, none of the application-level code needed any tweaking when doing a port. NONE of it. We were so pleased.

  • lollncf37 (unregistered)

    LMAO

  • Pock Suppet (unregistered) in reply to El Guaco
    El Guaco:
    That sounds like a PICK database.
    Nailed it in one.
  • lesle (unregistered) in reply to RuBen
    RuBen:
    Matt Westwood:
    Matt Westwood:
    Nutster:
    Matt Westwood:
    Question 2: b) indicate particular points of interaction at which customer satisfaction will be improved, and estimate the probability that, as a result of your having considerably improved her daily workload, you'll get to boff that tasty little brunette in Customer Services."
    The answer to the last part is still 0. It was zero before and is still zero. She has her eye on that charmer in Sales.
    (*quivering chin*) (*sob, sniff*)

    ... actually I have it on good authority that the charmer in Sales is already married and has three children (all with different women, none of which is his wife, who is built like a brick shithouse and has been known to hospitalise her rivals). If the cute brunette wishes to continue with her less-than-sensible course of action and thus risk life limb and happiness, then she's not the girl for me, I thought she was more sensible than that. On the other hand, if she is open to listening to reason, and would prefer a straight-up guy who actually knows how to fix things, not just fuck them, then hey, how about it, babe?

    1. Ignore all previous possible scenario's and simply go talk with her (0 or 100 points)

    Isn't she the President's daughter?

Leave a comment on “A Scrubbing Bubble”

Log In or post as a guest

Replying to comment #419181:

« Return to Article