back to article What Compsci textbooks don't tell you: Real world code sucks

There’s a kind of cognitive dissonance in most people who’ve moved from the academic study of computer science to a job as a real-world software developer. The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is …

COMMENTS

This topic is closed for new posts.
  1. Andrew Moore
    Thumb Up

    But good code...

    ...is an artform. In fact I'm trying to get the local Revenue Office over in Ireland to recognise me as an artist so I'll qualify for the Artist Tax Exemption scheme...

    1. IHateWearingATie
      Thumb Up

      Re: But good code...

      So right

      My first role was coding C and C++ on a legacy mainframe and I remember the joy of looking at the flow and symmetry of a carefully crafted and well commented code module.

      Other people's of course. Mine were more like a toddler's scribble than a renaissance masterpiece!

      1. big_D Silver badge
        Facepalm

        Re: But good code...

        My first project after college was an MS BASIC based finance data collection tool, running on CP/M and MS-DOS. The problem was, it was written by Fortran programmers and had been maintained by COBOL programmers... None of them had heard of For...Next or While...Wend loops, it was all add 1 to count and IF count THEN GO TO statements!

        There were hundreds of lines of old code that had been commented out, but removing them stopped the program working! There were computed GO TOs littered in the code, which jumped into the middle of sections of commented out code!

        Still, I managed to optimise it in the end. The collection and transmission routine used to take around 4 hours to run. After a couple of weeks of fettling with the code, I got it down to under 20 minutes!

    2. Zaphod.Beeblebrox
      Pint

      Re: But good code...

      I've maintained both types (and pretty much everything in between) and I find in some cases the elegant, flowing almost Zen code is harder to understand and debug. I've also noted that my coding style tends to match the original. Odd, that.

      Beer because sometimes, it helped.

    3. The Man Who Fell To Earth Silver badge
      Boffin

      Re: But good code...

      In the field of Electrical Engineering, the best textbook ever written is the 1152 page "The Art of Electronics" by Horowotz and Hill. And that's despite the last version being 23 years old. The reason it's the best, even for the sections dealing with digital circuits, is that every single example in the book is a real world example rathet than an idealized example, and that if you build any of the examples, they work (or don't, as the book also has plenty of what they call "bad circuit designs").

      Despite it's age, the text book is still in print I still use this book when I teach EE circuits course.

      Maybe someone should write a similar book for programming.

      1. flambard
        Mushroom

        Re: But good code...

        Right of the top of my head:"Advanced Programming in the UNIX envirionment" by Stevens.

        Being about Unix its obvious in C. Its carefully crafted(!) reallife code which takes into account

        an awfully lot of reallife specialcases.

        But shows the problem. Its just one language in `one' environment.

        The number of languages * number of envirionments tends to explode.

        More general books on programming (most) can only deal with general topics.

  2. Anonymous Coward
    Anonymous Coward

    Flawed Assumption

    "The technology people employed at these companies are considered to be the very best, if only because the pay tends to be so good."

    If you believe this, then you will never see good code and good coders. Those who graduated into banking roles were mediocre programmers with mediocre ideas who enjoyed the idea of making a far from mediocre pay check. I don't imagine you will see much focus on code quality in a startup either.

    Find a grown up engineering company which lives and dies on their reputation for quality software engineering, with managers who have been around long enough to understand the need for investment in a code base throughout its life cycle, and you will see a different picture.

    1. keithpeter Silver badge

      Re: Flawed Assumption

      Eastgate Systems: maintaining Storyspace which is something like 25 years old, and developing Tinderbox which has been around since Mac system 7? The main man is still refactoring and rewriting his code base.

    2. LDS Silver badge

      Re: Flawed Assumption

      Right, it's like saying an airline pilot is a better pilot than a military one because he gets an higher pay. In these areas the best people are attracted more by challenges than money. Mnay programmers know that working in such companies means very little freedom and almost no tech challenges (unless you work on some high-end trading systems).

      Of course that doesn't mean only banks write bad code - but they are not the best programming environment either.

    3. Ken Hagan Gold badge

      Re: Flawed Assumption

      There's a large dose of "temperment" here. Quite a lot of programmers will avoid jobs in a squillion dollar operation that works on a "must work perfectly yesterday or else we all die". That's not because they aren't good enough. It's because they'd rather do something else. Part of the pay at these operations is for talent, but the majority is in compensation for stress.

    4. Gannon (J.) Dick

      Re: Flawed Assumption

      "The technology people employed at these companies are considered to be the very best, if only because the pay tends to be so good."

      And only, too

    5. LoneStranger

      Re: Flawed Assumption

      I agree - Investment Banking, especially the front-office sections - is generally not a hot-bed of talent for computer programmers.

      Having worked at some of the same companies (even the same teams) as the OP, other considerations generally get in the way of writing 100% correct/stylish code.

      Investment Banks are not software houses. A lot of the code will be written by people with no CS or CEng background so it is not fair to expect them to write beautiful or perfect code. Time considerations generally man that you only get 1 shot at writing most of the code, and you very rarely get the time(aka money) to refactor the code at a later stage.

      However, the OP seems to miss the point about teaching programming. You don't teach people how to program badly, they just have to learn that for themselves.

  3. AndrueC Silver badge
    Stop

    It's not always 'the programmer's' fault. Maybe not even most of the time. I think management have to shoulder a fair chunk of blame. When was the last time anyone got approval for a refactoring project? And don't tell me we're the only ones that get defects deferred '..to be fixed in a future project'.

    The best code I've written has been generic and flexible. One project (a suite of data recovery tools) started out in 1992 as an MSDOS suite, was ported to Win16 a few years later then Win32. It had some ugly code occasionally but there was little to no management so we could decide to spend a month refactoring and did. That code lasted for 15 years and would still be good to day except that new owners didn't want it. I went from a C++ novice to C++ guru and as my skills evolved I was able to make time to evolve the code to take advantage. No chance in hell of that happening in most places (sadly not much where I am now).

    The reason a lot of code is sloppy and fugly is because the developer knows that their manager is paying them to get it out the door ASAP and is willing to defer fixes until the next project. I don't get paid for writing good code. I get paid for writing an application that sells.

    1. Kool-Aid drinker
      Thumb Up

      @AndrueC

      "I don't get paid for writing good code. I get paid for writing an application that sells."

      I'm in my third decade as a developer, and this has been the case everywhere I have worked.

    2. Anonymous Coward
      Anonymous Coward

      I absolutely recognise this. I took an incomplete project and had to get it to the finish line. The management requirements changed so much that the original design was well off the mark as was the implementation. Add the aweful code which ate memory and took a while to process a simple database fetch and it had disaster after disaster with serious bugs that couldnt be tracked down in code that shouldnt even exist. Put simply it wasnt fit for purpose in any respect.

      I maintained this system for a few years as management demanded new features even if it added instability. The worst part was how proud of their system they were. It kinda did what they wanted with lots of quick fixes or direct intervention in the database and there was a collection of tools I wrote separately to fix problems when they occurred.

      I did all I could for years to explain how eventually the limits of the system would be reached and one day there will be no hope of extending the system or even maintaining it. I asked to redevelop sections of the system to at least bring stability to some of the users in house but the only time this was truely considered was when new IT staff of dubious capability were brought in to manage such a development. I made a very quick exit as I was being asked very simple questions about how a database works and the standard programming languages we used by the new IT staff placed in charge (brought in for their skills in these areas!).

    3. kororas
      Thumb Up

      I actually find myself in your position. These days im doing a mixture of technologies for a small business, I have always counted myself lucky and your statement has reaffimed it.

      When I started my code wasn't great but my ethic was. My techniques have improved a lot of the period of employment and crucially I have been allowed the flexibility to bring old code I have developed up to my current standard on many occasions.

      I think it allows for a great improvement to personal skills and comprehension, when looking over and improving old code.

    4. Mark Honman

      No time to refactor

      and it was ever so....

      One thing that works for me is to allocate some time for "while you're in there" refactoring when estimating development times. Then there is a bit of buffer when changes need to be made to some particularly manky old piece of code - by the time one has understood it it's not that much extra work to refactor it.

      The biggest problems are that (a) I'm an optimist and (b) managers always try to compress the development schedule, so there isn't much in the way of buffer.

      1. Kubla Cant Silver badge

        Re: No time to refactor

        It's very tempting to do "while you're in there" refactoring, and it's very often a bad idea. Any change to working software introduces risk., and this risk is magnified by well-meaning attempts to clean up bad and incomprehensible code. This is also a good reason why quick-and-dirty patches aren't revisited.

        1. Dr. Mouse

          Re: No time to refactor

          "it's very often a bad idea. Any change to working software introduces risk., and this risk is magnified by well-meaning attempts to clean up bad and incomprehensible code. This is also a good reason why quick-and-dirty patches aren't revisited."

          ^^ This. Over and over and over.

          As a very simple example, I needed to add some additional checks to a very old bash script. Now this script was written as a quick hacked together job by someone who used to work for the company. He left many years before I came along, and the "code" has been modified by so many people, with such varying backgrounds and styles, and copied to do similar jobs slightly differently... Well, as you can imagine it's more of a mess than a spaghetti factory after an explosion.

          Anyway, I thought it would be a good idea to tidy it up "while I'm in there". This was a bad idea. So many obscure utilities were being used, exploiting "undocumented features" in them, that we very nearly lost a weeks worth of data (luckily I had added the additional checks first, which caught the mistake).

          As for "time for refactoring"... I have been pushing for this for 5 years now. According to my bosses it's not necessary. When I tried to make time in between jobs to do it, I got a bollocking for wasting time. These scripts fail every few months and take a few hours to clean up after and get going again, delaying other departments in the process, but spending a day rewriting them is a "waste of time". I've given up, and managed to push the "clean up" responsibilities onto someone else (sucker.

          And this is just a tiny set of bash scripts.

      2. Rob Carriere

        Re: No time to refactor

        I'm not sure I understand this. Refactoring _saves_ time. When you're chasing a bug, or have to add functionality and find yourself searching for where on Earth to apply the change, you can spend half an hour thinking about that (and probably getting it wrong, triggering an extensive debugging session) or you can spend that half hour whacking that piece of the code back in shape and then spend 30 seconds applying the change (and probably getting it right on the first try).

        You have to practice, a lot. You have to have good tests (and run them!) so you get instant feedback on each step. But then you will be faster, not slower, with refactoring.

        Now, if you're brought in on a project that's already three miles down the hole, then half an hour isn't going to cut it, obviously. Although I think that if the powers-that-schedule are honest and count debugging time, schedule slippage and so on, you'll still find the refactoring bonanza is faster than trying to grin and bear it. But, that is admitting up front that you made a mess and a lot of people/teams/managers find that very hard to do. So, social reasons not to refactor, I get. But valid timing or technical reasons? I very much doubt it.

        1. AndrueC Silver badge
          Go

          Re: No time to refactor

          I only refactor code that is already being changed. If I did get a refactoring project then fine anything is up for grabs but changing code that wasn't otherwise going to change is asking for trouble.

          1. redpola

            Re: No time to refactor

            Absolutely totally agree with this. If you're dicking about with a piece of code anyway, I as a manager trust your skills as a competent engineer to leave that code better than you found it. If we have to test it again anyway then fine. But start changing code that we've tested and is a known quantity and you're entering a world of pain. It's just wasteful, and wouldn't you rather be off doing new shinies than having a manager scowling at you for introducing risk?

            1. Rob Carriere

              Re: No time to refactor

              @redpola: Errr...Exactly what is the scenario we're going through here? I honestly don't understand. There's apparently some code that's already QAd, so you don't want me to change it --makes perfect sense--, but you _do_ want me add a feature to it? If that is the situation, why aren't the QA people kicking you?

              Or if it not a feature I'm doing, but a bugfix, then by definition that code wasn't yet fully QAd. (If we're well down the QA process I do understand you want minimal intervention and I'll try my hardest to do just that, but I can't fix bugs without touching the code.)

              1. Ammaross Danan
                Boffin

                Re: No time to refactor

                The worst part about QA, is how extensively have they QAd it? I've ran across loads of code that wouldn't have passed a proper desk-check, let alone unit testing. That's the code that needs to be touched.

                1. Destroy All Monsters Silver badge
                  Holmes

                  Re: No time to refactor

                  Gentlemen!!!

                  The word your are looking for is "Technical Debt".

                  You may want to check out the paywalled November/December issue of IEEE Software or avail yourselves to the multimedia gallery at your discretion.

                  Martinis will now be served on the lounge deck.

        2. lightknight

          Re: No time to refactor

          I agree with the idea, but reality can be different. There is a time in every developer's life, known as the 'death of sanity,' where you are assigned, typically by yourself, to a project that has scope creep and a screwed up code-base. The problem, of course, is that when you accepted the project, you knew nothing of the problems -> you only understood the depth of the problems several months into it. The code-base itself, being so large, probably would take at least a year to refactor, but the project was due 6 months ago. You end up in the scenario where management over-promised to the client, and thus, spends every day asking you how much longer it will take to complete the project. Deadlines are perpetually missed, and you can't clear your head outside of work, instead spending all of your time staring at the ceiling instead of sleeping. Again, this is the 'death of sanity,' and you can't get far enough away from the problem so as to see it correctly.

          I've been there several times, and have slowly acquired the skills necessary to spot it a long way off (well, some of the skills). When someone assigns you a project, do they know what the code-base is like? If not, they get a non-committal response to the project -> I'll look at the code to figure out where it is, but looking at it is not accepting the project. Code-base is a pig? I will see what I can do, with healthy buffers around my timelines. This is the reality of code -> someone wrote something, and though they may be intelligent, they may also have been under orders to write it that way. See the book Catch-22 for all applicable scenarios.

          The only side-effects are that to some people, I appear lazy, and to others, I appear intelligent. To the people who want the project to succeed, I appear intelligent, asking all these gotcha questions, which tells them I am slowly crafting a plan of action. To the people who think success is achieved by working the whip as quickly as possible, I appear lazy, asking all these gotcha questions, instead of just 'diving in.' I prefer the more intelligent people, as they tend to be more realistic, but I do not always get to choose.

    5. redpola

      Developers always want to refactor code. It's actually a developer's nature to move code about and fiddle with it - it helps to understand it and know your way around it. However, to a QA guy, code that's been tested has been tested. Any changes to that code erodes the money that's been spent on testing that code, which then must be tested again (so you're costing QA twice). Managers are trying to keep devs happy with new and exciting shiny things and also suits happy with new features. Managers also have to perpetually answer questions like "why are you spending time rewriting the thing we've shipped instead of adding new IP and value to the company?".

      You could argue that refactoring code saves the company money by creating a new and "better" bedrock for future development. I've never know that to be the case in reality. Feature requests and road maps change so fast that you either generify your product out of existence or your refactor yourself down a dark alley.

      Ultimately, apart from "but the developer likes it" there is no justification from any angle to introduce change for change's sake.

      Even as a developer, it's a right bastard finding that someone moved your code around and introduced a cut and paste bug.

      1. Mark Pawelek

        Refactor when you must but put tests in place to prevent breaking changes

        redpola : Ultimately, apart from "but the developer likes it" there is no justification from any angle to introduce change for change's sake.

        One compelling reason to refactor code is to make it testable by introducing seams or decoupling dependencies. People tend to exaggerate in these forums.

    6. The Indomitable Gall

      @ AndrueC

      "It's not always 'the programmer's' fault."

      That was part of the message of the article, even if it was a secondary one.

      But I think the problem is fundamentally this:

      No matter how much design you do in advance, all programming is essentially "design by prototype" as there isn't a single programmer I know who can order his thoughts and visualise all the possible side-effects of a large codebase before he hits his IDE.

      Therefore it follows that the output of any coding process is a prototype. That's what we need to start teaching to managers: "it's a prototype, it demonstrates the principles and design decisions required for making a production model, but it's not a production model." If you need to, say it's a matchstick model of the structure you want to build: it's identical aside from being a bit weak.

  4. The Axe
    Facepalm

    Windows Pinball

    Just look at why Microsoft dropped Pinball from Vista. It's because the code was undocumented, hard to understand, poorly commented, and basically crap. They couldn't even work out how the collision detection mechanism worked and when it was ported to 64-bit the detection didn't work. Shows that bit of code made too many assumptions about word size for a starter.

    1. Version 1.0 Silver badge
      Happy

      Re: Windows Pinball

      Written in 16-bit code, ported to 32-bit code and then (almost) ported to 64-bit code? I'm surprised that it even ran.

      1. AndrueC Silver badge
        Happy

        Re: Windows Pinball

        Been there, done that (DOS to Win16 to Win32) over 15 years. Suite ran just fine thank you and many people benefited from it. Oh and we did that without a QA department and little to no management. And it was agile before we knew what it was called because we could get called off to other work at any time.

  5. Tim 11

    it's all about the requirements

    Sure there is plenty of badly written code about in the wild, but let's not forget that the type of code you'll find in academia only has to meet nice clean invented requirements; not real world ones. A lot of the complexity of real-world code comes from meeting real world users' needs and from working round flaws in existing real-world code.

    1. Ole Juul

      Re: it's all about the requirements

      I suspect conflicting requirements in many cases. Trying to balance the demands of managers, clients, and ultimate users' needs is probably not even possible in many cases.

      1. Primus Secundus Tertius
        Thumb Up

        Re: it's all about the requirements

        That reminds me of the NHS Integrated Software Disaster, where it seemed noone actually listened to the techies, whether tech users or tech developers.

        More generally, sometimes you don't know what the requirements really are until a prototype has been working for some time. Eh! Protoypes? Bl**dy waste of money, any manager will tell you.

  6. JeffUK

    There's a strong analogy here with genetics (Read Dawkins' "Climbing Mount Improbable")

    By walking upright with a back designed to walk on all-fours; we risk spine degeneration, pain, and disability. But from a genetic perspective it was infeasible to go back to 'no spine' and build one from scratch; just to be able to stand a little bit taller.

    The same applies to code, you get to a point where to add a new function, the 'right' solution is to start from scratch; But that might mean re-writing a £multi-million piece of software, JUST to add one new function. So the only feasible option is to hack it on in a sub-optimal way.

    1. Ru
      Flame

      The problem with that attitude is that few of the people paying the bills appreciate exactly how much it costs to maintain a codebase that resembles the carcass of a whale that's died from gas gangrene.

      I've seen a big software porting effort which took 30 skilled (and hence expensive) people working for six months on something that could have been done by half the people in half the time if the folk doing the porting were familiar with the code base which was frankly cancerous in its disorganised and complex sprawl.

      Following that porting effort, those 30 people were reassigned, having not had the time to clean up the awful codebase, and a new group of people were assigned to add new functionality. Again, 30 people, 6 months, most of which was spent fighting with the incredibly brittle codebase which was so full of hacks that it was practically impossible to do any refactoring without breaking everything.

      I wouldn't be surprised to learn that a 7 figure sum was ultimately expended on this exercise; a figure that could have been reduced by an order of magnitude if the codebase wasn't such a mass of tumours. But at each stage, project management and funding just looked at what needed to be done to accomplish the next goal in the cheapest way possible. Cost cutting every step of the way, and the end result was a multi-million pound unmaintainable codebase. Good times.

    2. Evil Auditor

      Re spine

      JeffUK, not sure what you mean. I've had a couple of bosses who were perfectly able to walk upright. But they definitely had no spine at all.

  7. Grikath

    But good code....

    Is also dependent on the programmer actually knowing what the operational parameters are...

    Plenty of bad Code originates in the fact that all too often you have to deliver code to Do Stuff, even though the underlying assumptions/corporate structure/actual hardware are stull "under negotiation by management". Which usually ends up with an ETA of actual programming parameters about two months after the project is *supposed* to have ended, at which time the local intern is tasked to "fix stuff. Oh, and could you add routines for these bits of management info we desperately need after our comittee meeting yesterday showed....."

    Writing any code in "an open managerial environment where ad-hoc flexibility is emphasised" amounts to cruel and unusual punishment. Writing *good* code in such an environment would require time travel ( and preferably a Special Order cattleprod).

  8. AndrueC Silver badge
    Go

    > Include some comments!

    That deserves a reply of its own. I hate comments. Even if they start out accurate they get out of date because there's nothing to enforce change in them as the code changes. Far better. Far better is to write code that is self documenting. It isn't even difficult. Every time you think of writing a comment, don't! Call a function or method or instantiate an object and put the comment in the name of the identifier.

    Identifiers should not be short, succinct and cryptic. Modern editors mean you don't have to type the whole thing out so get creative.

    1. The BigYin

      "Even if they start out accurate they get out of date because there's nothing to enforce change in them as the code changes."

      Yes there is, it's called a "Code Review". All code should be reviewed by the team, and preferably by some not involved in the actual project. Of course, time needs to be allowed for this and it seldom is.

      "Every time you think of writing a comment, don't! Call a function or method or instantiate an object and put the comment in the name of the identifier."

      That's good up to a point, and well named object/methods/params/members are a big help; but nothing, nothing beats proper docs and comments. It also means the APIs can be spat out and handed over to other teams fully doc'd, with behaviours, expected responses etc all done. No need to keep secondary documentation in sync. One line of code docs/comments per line of code (ish, depends on the language).

      If you change the code, change the comments. Simple.

      1. AndrueC Silver badge
        Meh

        > If you change the code, change the comments. Simple.

        In theory, yes. In practice not so much. Comments are only read by humans so they can be overlooked and neglected. Source code is read by the compiler and although it won't enforce identifier names it can enforce structure especially if encode your logic in object constructors and well defined classes.

        1. The BigYin

          @AndrueC - Which brings me back to code review. Before hitting trunk it should be reviewed (and this includes comments). I know that is an ideal case and not always reality.

          Code and comments go hand-in-hand. IMHO you need both.

        2. Primus Secundus Tertius
          Thumb Down

          Testing the comments

          "If you change the code, change the comments. Simple."

          No, not at all. It is even harder to test the comments properly than to test the code.

      2. Rob Carriere

        Comments are excellent for the stuff the language doesn't do. That's always the broad overview (at each of function, class, and module level) and in some languages the type specifics of arguments and members. Design decisions are also very welcome ("We use linear search because there will never be more than 10 items.")

        Comments are an annoying distraction when they duplicate the language. The next time I see /* add all the numbers */ or some such blather --never, ever properly punctuated or capitalized-- sitting above a for loop that does just that, I'm going to scream. Either tell me something interesting or let the code do the talking.

    2. Matt Bryant Silver badge
      Meh

      Re: AndrueC

      "....I hate comments....." Sorry, but I probably wouldn't hire you. Managing programmers is worse than herding cats, and I tend to lay it on thick when it comes to the "this is how you will write your code" introductory talk, and I have a whole chapter in my standards doc on EXACTLY how often you would be required to add comments, markers and other structure, and when they will be reviewed and updated. Just to be a real pain in the prosterior, I have it written into the acceptance criteria for contractors that work for us too. I have seen people try and auto-comment and it usually doesn't work. You could be the Albert Einstein of coders but you're fudge-all use to me if I can't take your code and give it to what are definitely non-Einstein support monkeys.

      On of the biggest problems with many business projects is so-called "agility" - everyone in business thinks they want it, they all say we need it, but they don't realise it often comes at the cost of stability. The business analysts will spot some new market segment, the business architects will come up with the business re-allignment to take advantage of the opportunity, then we have to sit down and work out the systems to make the new business processes work. All too often the business analystes will be saying we need to be up-and-running in two months to beat the oppostion, but the coders are having to say they need six months to write the code properly. The result is a desperate rush to get code out the door with the minimum agreed functionality and the vague intention to add features and tidy up later, a recipe for ongoing firefighting. By the time you release the first phase the analysts want to add or change something, the goalposts move, and you're going to spend the next few years chasing those ever-moving targets.

      1. Doc Spock
        Alert

        Re: AndrueC

        And function bodies change too! I've seen countless functions where the name is misleadingly (and dangerously) inaccurate because the body has been changed. While comments won't prevent this, they will help explain that the function doesn't do what its name suggests.

        Anyway, good comments include the "why", not just the "what".

      2. Sandra Greer

        Write the comment first

        Since I started programming in the days of the dinosaurs, I have found it useful to write down what I was trying to do BEFORE writing any code. I still do that, even in SQL. Changing the comment is automatic if a commented line of code is changing. That seldom happens, though. Generally a whole function is being extended in some way. So the description of how it works would require some thought. Essentially, the specification is contained in the code. It doesn't take up that much space! Adding my name and a date helps other team members keep track of what changes correspond to user requests.

        Of course it helps that I think in English, and my first programming language was COBOL. There was an invalid assumption in those days that COBOL was self documenting. The people who taught me never let us get away with that.

    3. Mark Honman

      Comment wisdom

      It's so long ago that I can't give credit where it is due, but the best approach to commenting that I've found is:

      * If you need to comment a line of code, that code is obscure - do it differently. (not always possible, as it may be a toolset restriction) - but line-by-line comments should be exceptional and are there to say "here be dragons"

      * every module and routine should have a comment header that explains its purposes, inputs outputs and side-effects, and an easy-to-read outline of the steps that occur in processing

      * write the header comments before writing any code

      The rationale is that line-by-line comments generally make code harder to read because one can't see the totality of a routine on-screen. On the other hand the header comments are an expression of the programmer's understanding of the requirements and allow one to clarify how the problem is going to be solved before getting into the nuts-and-bolts of language and toolset specifics.

      BTW the old rule on function size probably still holds - if it is less than 20 lines, it's probably too small, more than 60 definitely too big (yes I know OO results in lots of dinky methods... but too much of that results in lousy readability as one has to skip from one routine to another to follow the logic).

      1. Anonymous Coward
        Anonymous Coward

        Re: Comment wisdom

        > there to say "here be dragons"

        You have a point there, the per-line comments should be to tell you what is not obvious from the code, usually it means something done for efficiency or a possible future "gotcha" if anyone changes it carelessly.

        > every module and routine should have a comment header that explains its purposes, inputs outputs and side-effects, and an easy-to-read outline of the steps that occur in processing

        Amen to that!

        > if it is less than 20 lines, it's probably too small

        I would have to disagree with that. Sometimes it makes a lot of sense to have a small function to group some process (or probably partial process) in a way that makes it more logical and readable, for example a small block of stuff that appears in two loops in a bigger function. Modern compiler's automatic in-lining means a lot of this can actually increase efficiency!

      2. Anonymous Coward
        Coffee/keyboard

        Re: Comment wisdom (Mark Honman)

        ...- if it is less than 20 lines, it's probably too small, more than 60 definitely too big...

        And this assumes no compiler bugs.

        20 years ago, I managed to write a program that crashed the Pascal compiler on a dual DPS-90 running CP-6. The functions were so short that they could be compiled into object code faster than the compiler's internal object-naming routine could generate internal names. This caused two functions to have the same name, which would cause the linker to crash.

      3. Gerhard Mack

        Re: Comment wisdom

        @Mark Honman

        I agree with 90% of what you wrote but you lost me at the less than 20 lines bit.

        1 short functions can be great for things you have to do 50 times and as stated previously the compiler can just inline to improve efficiency.

        2. In C they are great for forcing type safety around generic libraries that lose type safety. A good example of this is the function pointers in one of the products in our office. The code has certain options depending on where the calls happen in the protocol so short wrappers can be used to ensure that only the correct functions are added to the list of options. (before anyone brings this up. The items also depend on what modules are loaded so switch() wouldn't even work.)

        1. Mark Honman

          Re: Comment wisdom

          @Gerhard

          The 20 lines bit comes from the terminals of old - that's how much you can see at one go (60 lines on a printout page).

          I've got to agree with the "wrapper" type of function, hat you've described. I guess my opinion comes from having done a lot of maintenance, and the frustration of following the flow of control in OO code that passes from one inconsequential little method to another. is a maze of twisty little methods, all alike.

          On the other hand there were some shockers in the old days, 1000-line Fortran IV routines (don't get me started on common blocks) , and a supervisor who having discovered the Pascal CASE statement considered that it made IF... THEN.. ELSE obsolete.

          OO shockers seem to be small, e.g. a simple "pure" function (no state, global references or side effects) that was implemented as a method, and the caller of this 8-line function was expected to instantiate an object of this class, call the method, and then throw the object away.

          In fact there's a pattern here... it's so easy when one has discovered something new (COMMON blocks, CASE statements, object-orientation) to unthinkingly use this new shiny (or orgnisatoinally mandated tool/method) to solve every imaginable problem including those that can be more effectively solved the old-fashioned way.

          As another commenter said, that is a common factor in poor-quality code.

      4. Lallabalalla

        Re: Comment wisdom

        Agree with that except that we write some performance critical code which can look very abstract - almost every line of code is commented because efficient code is not always as readable as one might like - but again, the the comment represents the logic - what we are seeking to achieve with the following line - and the code the implementation

    4. mccp

      @ AndrueC

      You obviously never write code that implements standards or interacts with the outside world.

      Of course it shouldn't be necessary to write a comment to explain what a line of code is going to do, but I often find it necessary to write comments explaining why it is doing it. I may need to refer to a standards document or another source that I used when writing the code. Sometimes it's one sentence in an entire standard or reference manual that's important - what should I do, hope the future me remembers or that someone else is psychic enough to find that reference?

    5. Charlie Clark Silver badge

      Far better is to write code that is self documenting.

      Even better is to write tests for that code.

      1. AndrueC Silver badge
        Thumb Up

        Doing both is best :)

    6. Paddy

      Identifiers should be succinct andNotTediouselyLongWinded. Presumably you are using a language with namespaces and so the enclosing namespace brings contect that need not be repeated in a choice of variable name.

      On comments, I too hate _bad_ comments. Learn how to write good comments because sometimes they are necessary - for example, after you have got a good implementation that gives the right result, you may need to alter it for, for example, speed or memory optimizations. These optimizations may not allow the luxury of being in their own function and are going to be obtuse.

      1. Primus Secundus Tertius
        Unhappy

        NoWindbagStyleIdentifiers

        I always thought K & R got it about right. Then some illiterate foreigner working for Microsoft thought it a good idea to spatter capital letters in the middle of identifiers.

        Some people were upset when I ran code reviews and asked for a compiler listing of the source, which would include name tables etc. So you could see what were integers, what were procedures, etc; and whether some of them were keyboarding errors. And indeed, whether it actually compiled. Call me cynical, but I had to deal with contractors.

    7. dajames Silver badge
      Big Brother

      Comments

      > Include some comments!

      That deserves a reply of its own. I hate comments.

      There are certainly hateful comments ... but comments are a valuable tool when used correctly. Comments deserve to be loved, but not indiscriminately!

      Even if they start out accurate they get out of date because there's nothing to enforce change in them as the code changes.

      That's a problem one needs to be aware of ... but is easily sorted by code reviews. The fact that the code has changed but the comment hasn't is easily seen from version diffs, if you look for it.

      Far better. Far better is to write code that is self documenting.

      I agree with that absolutely, and most of the time you're right that it isn't difficult ... but sometimes there is information about a piece of code that isn't easily conveyed by careful structure and naming, and then comments are invaluable.

      The interface definition should say what a piece of code does.

      The code itself says how it does it -- but comments may also be needed for clarity.

      Only comments can say why it does it!

      Big brother because he's the ultimate code reviewer, and we need him too!

      1. Destroy All Monsters Silver badge
        Big Brother

        Re: Comments

        > Big brother because he's the ultimate code reviewer, and we need him too!

        Not according to Charles Stross. From "Big Brother Iron":

        I am a systems manager in the abstract realm of the Computer, the great Party-designed, transistorised, thinking machine that lurks in a bomb-proofed bunker in Docklands. It’s my job to keep the behemoth running: to this end I have wheel authority, access all areas. The year is probably 2018, old calendar, but nobody’s very sure about it any more—too many transcription errors crept in during the 1980’s, back when not even MiniLove was preserving truly accurate records. It’s probably safest just to say that officially this is the Year 99, the pre-centenary of our beloved Big Brother’s birth.

        It’s been the Year 99 for thirty-three months now, and I’m not sure how much longer we can keep it that way without someone in the Directorate noticing. I’m one of the OverStaffCommanders on the year 100 project; it’s my job to help stop various types of chaos breaking out when the clocks roll round and we need to use an extra digit to store dates entered since the birth of our Leader and Teacher.

        Mine is a job which should never have been needed. Unfortunately when the Party infobosses designed the Computer they specified a command language which is a strict semantic subset of core Newspeak—politically meaningless statements will be rejected by the translators that convert them into low-level machinethink commands. This was a nice idea in the cloistered offices of the party theoreticians, but a fat lot of use in the real world—for those of us with real work to do. I mean, if you can’t talk about stock shrinkage and embezzlement how can you balance your central planning books? Even the private ones you don’t drag up in public? It didn’t take long for various people to add a heap of extremely dubious undocumented machinethink archives in order to get things done. And now we’re stuck policing the resulting mess to make sure it doesn’t thoughtsmash because of an errant digit.

        That isn’t the worst of it. The Party by definition cannot be wrong. But the party, in all its glorious wisdom announced in 1997 that the supervisor program used by all their Class D computers was Correct. (That was not long after the Mathematicians Purge.) Bugs do not exist in a Correct system; therefore anyone who discovers one is an enemy of the party and must be remotivated. So nothing can be wrong with the Computer, even if those of us who know such things are aware that in about three months from now half the novel writers and voice typers in Oceania will start churning out nonsense.

    8. Someone Else Silver badge
      FAIL

      @AndrueC -- Include some comments

      I hate comments. Even if they start out accurate they get out of date because there's nothing to enforce change in them as the code changes.

      In other words, you can't be arsed to update a comment or three after you poke at the code? Sounds like basic laziness (if not intermediate to advanced laziness) to me. Besides, I'd have thought you'd want to brag about the wonderfulness of the code/patch/refactoring you just wrote, and why the mechanism you used in doing that was so much superior to that which your opus replaced. Think of it that way, and it's not a comment, its an advertisement!

      1. Mark Pawelek

        Re: @AndrueC -- Include some comments

        In other words, you can't be arsed to update a comment or three after you poke at the code?

        No. It's better to break down code blocks into short functions (aka methods) and to use meaningful, explanatory names for these methods. Then your code is self-documenting and there's no possibility of comments becoming detached from code, or worse, comments mis-describing code. The main problem with this technique is a tendency for the less wise to economise by writing short method names, or to think that, just because they have a long method name, the code must be self-documenting. Public API code still needs documenting.

        1. Destroy All Monsters Silver badge
          Alert

          Re: @AndrueC -- Include some comments

          Don't miss out on

          PROGRAM ASSERTIONS

          Anyone not using them (along with switching on all the compile time code analysis your IDE offers and letting Sonar run on the source every fracking day) should be looking at a pink slip presto.

    9. bailey86

      Ah.. The old 'self documenting' self delusion...

      Comments are part of elegant code - and commenting intelligently and clearly is part of professional coding.

    10. wad

      Yeah, this last statement about including some comments stopped me cold. The author lost credibility here. Generally, the only time when comments are needed is to document the "why" of something that isn't obvious. There are a few exceptions, but before you write a comment, try really hard to name your variables or methods better, or do some other refactoring to make the code itself say what it does. Comments are almost always incorrect and therefore misleading. Drop all the javadoc, and delete all comments in the code whenever you see them, unless they are actually explaining a "why".

      1. Destroy All Monsters Silver badge
        Mushroom

        > Drop all the javadoc, and delete all comments in the code whenever you see them

        Some people are worse than Taliban nutters. Hand them some code, they want to AK-74 all of it.

        Engage catapult through the front door.

    11. flambard
      FAIL

      selfcontradictionary

      they (comments) start out accurate they get out of date

      vs

      put the comment in the name of the identifier

    12. Lallabalalla

      Re: > Include some comments!

      Self documenting code is fine, there is real no point using comments to state the totally obvious - but after many years of getting commenting wrong and (rightly) believing my efforts to be a waste of time for the reasons you state, I now firmly believe that a short comment above the method signature along the lines of: "the purpose of this block is to arrive at the optimum alpha value for [some specific thing]" - rather than stating something like "add param a to param b and take away the remaining value times some magic number declared const somewhere", which anyone reading the code can see for themselves.

      That way you can see what the method is actually FOR which can be rather helpful if it turns out to be doing things wrong - while the wrongness can be addressed by first reading the code then stepping through it.

      It's really the classic O-O separation of business logic from implementation detail. If you can't get that right your program's components *will be hard to refactor and very hard if not impossible to re-use.

  9. DrXym Silver badge

    Another way to look at it

    The real world doesn't have the luxury of picking discrete problems and dedicating 2 or 3 years to solving them. It has to be pragmatic and sometimes pragmatism means shipping something which does the job even if it is imperfect by some arbitrary criteria.

    It has to deal with problems which are complex, it is often feature driven, it is developed over time, it is affected by issues such as security, performance, incremental development, long term support, delivery dates, budgets, manpower shortages. Code might be worked on by multiple hands in waves as people come and go from the project.

    And sometimes that means bad code. Who is surprised by that?

    1. Primus Secundus Tertius

      Re: Another way to look at it

      That's just special pleading, aka making excuses.

  10. David Hicks
    Happy

    I try to write clear code

    With clear and sensible interfaces.

    Part of the difficulty in getting this done is that requirements are barely ever exhaustive and are very subject to change (though once I got handed a multi-thousand page standard and got told 'implement this!). The other problem is other people - your definition and mine may differ significantly here.

    I do wonder though as you draw a lot of your anecdata from the world of finance - Most of the best engineers I've met in a 12 year career (so far) wouldn't touch the city, and not just because they didn't like getting out of bed in the morning - do you think that this sector in particular suffers from big egos matched with decidedly average aptitude?

    Also have to agree with the general theme - real world software problems are messy and don't often occupy the idealised domain that academics often tackle.

    1. David Hicks
      Happy

      Re: I try to write clear code

      Self reply to clarify (and keep wittering 'cos the alternative is hacking at some terrible code).

      When I say "Your definition and mine may differ" I mean our respective definitions of clear and sensible.

      For instance I've worked in places where the ternary operator in C was not allowed in case it confused some (experience<1?"junior":"incompetent") developers. Whereas I find a quick ternary in the right place to be easier to comprehend than padding the code out with more standard if/else lines. And this is a trivial example, when it comes to structuring large volumes of code there are so many different approaches that can be taken, and so many ways to get it wrong, that you really often end up with something that seems to have grown organically rather than really been designed.

      1. The BigYin

        Re: I try to write clear code

        This. Which is why I doc the living hell out of my code so that people reading it (or the API) know what I mean by "foo" and how I expect it to behave. If they contact me to ask a question, either they haven't read the docs (in which case I give them short shrift for wasting my time*) or the docs were inadequate (in which case I update them).

        And if coders don't understand a ternary operator, you need better coders.

        *That may seem a bit harsh, and I don't actually mind answering sensible questions. But it's not a case of just one person asking, it's the next and the next and the next and the...so I make them read the docs and come back with a sensible answer. I know some folks always do check the docs, so I know from the get-go they are asking something sensible. Other folks? Not so much.

        1. AndrueC Silver badge
          Thumb Down

          Re: I try to write clear code

          > so that people reading it (or the API) know what I mean by "foo"

          Why the hell are you calling objects 'foo' in production source? You shouldn't have an object called 'foo' and a comment saying what it is. Call the bloody thing by what it is in the first place.

          1. The BigYin
            FAIL

            Re: I try to write clear code

            Oh FFS. "foo" (and "bar") are standard names used by just about everyone for basic examples of syntax etc. Of course I don't call things in real code "foo" or "bar".

            Unless of course that do actually happen to be a "foo" or a "bar".

            1. Primus Secundus Tertius

              Re: I try to write clear code

              The whole point of the article and these comments is that most code is a FUBAR - fouled up beyond all recognition.

        2. This post has been deleted by its author

        3. David Hicks
          Linux

          Re: I try to write clear code

          I withdrew my last comment as it could have been construed as a very negative review on current colleagues, not really what was intended.

          Heartily agree that if people can't cope with the ternary operator they need to be taken outside and dealt with humanely...

        4. Kool-Aid drinker

          Re: I try to write clear code

          "And if coders don't understand a ternary operator, you need better coders."

          Any C coder who can't/doesn't understand the ternary operator needs to be fired. Quickly.

          1. Someone Else Silver badge
            Coat

            Re: I try to write clear code

            OK, I need to get to my 100th downvote, so it might as well be now.

            I've been doing this for longer that a good number of you broomtails, based on the comments I've read here. And I daresay that I've been using (and fixing code from abusing) the ternary operator in C and C++ for longer that some of you may have been alive. (Yeah, yeah, I know, "Shut up, ol' man!" Please, hear me out....) Given that, I am quite capable of "understanding the ternary operator". And I've also come to understand that, in the hands of some less-than-talented, or less-than-disciplined practitioners, the ternary operator can be made to resemble that snippet of APL code in the original article. Like most things in C/C++, this is a double-edged sword; it can be an immense help (indeed, the alternative to ternary operators in a C macro would cause the hair on the neck of the most steely programmers to stand on end). And nesting them can turn the most elegant code into a WSH (Warm, Steaming Heap).

            I don't wish to comment on the wisdom of banning a ternary operator from use, but I will say that a shop that has such a ban probably has it due to long term and rampant abuse by cowboys who "understand the ternary operator".

            1. David Hicks
              Thumb Down

              Re: I try to write clear code

              No, they had the ban because they were less than competent. It was one of several arcane rules and was matched with a vcs cobbled together from glue, string and fear of progress.

              I've been doing this for a dozen years now too, perhaps not as long as you, but I've come to recognise that there are a lot of very mediocre dev shops out there. I'm not a 'rockstar' but I am half decent at what I do and they were not. I've seen worse since...

            2. Pigeon
              Happy

              Re: I try to write clear code

              You won't get 100'th downvote from me. You could have written some rubbish. Good luck in your quest.

            3. Mark Pawelek

              What are they doing giving jobs to cowboys?

              We shouldn't be employing cowboys to write code, unless we want to drive our businesses to a slaughter factory.

              Seriously folks. Try to put recruitment into the hands of people who know what they're doing; then there's a chance they'll be able to write good code rather than garbage.

              1. Zack Mollusc
                Meh

                Re: What are they doing giving jobs to cowboys?

                The recruitment people are also cowboys. As are management. Nobody tries to do their job as well as they can as that is the sure way to redundancy and the dole queue

      2. Robert Carnegie Silver badge

        Re: I try to write clear code

        C consists far too much of punctuation anyway, and I assume that the formula in words is logically identical - but, hey, what you do is fine with a meaningful comment.

        But when we write Java (although I personally don't), our unit policy is to ban a particular Java keyword, apparently at random but presumably because one of the senior programmers or managers read an article online that said it's inefficient or confusing, or it doesn't exist in their favourite language or their college programming course. I think it's "break", although it could be "for".

        We have no policy on comments but a belief that since humans are smarter than computers (I suppose), it is perfectly obvious what a program does anyway. Apparently we also assume that that is always the same as what it was supposed to do.

        I work with Microsoft Transact-SQL 2005 and I write stored procedures in which database and object references in dynamic SQL are elegantly tokenized as fully qualified terms, and then I realised that I myself can't read that afterwards, so now I include comments that in -this- batch, each appearance of token @[output} is REPLACEd with [NS_01].[dbo].[StaffAbsence_2010] or whichever namespace number and year number are appropriate to the occasion.

        1. This post has been deleted by its author

        2. Robert Carnegie Silver badge

          Re: I try to write clear code

          Oh,and someone in our organisation doesn't know or doesn't want to know that a CASE statement can have more than two parts. Which is the damn point of it. We get "CASE WHEN i = 1 THEN 'one' ELSE CASE WHEN i = 2 THEN 'two' ELSE CASE WHEN i = 3 THEN 'three' END END END". (But with line breaks at least.) I haven't caught them yet. Which exposes another mistake that we make, nobody's name is on most of this junk.

          I work for Anonymous Organisation, which they aren't going to admit. Maybe I work for you.

  11. Version 1.0 Silver badge
    Happy

    It's all downhill from here

    I've worked on several medical coding projects where, after analyzing the comment free code, it was obvious that the programmer had never really understood HOW the project was supposed to work ... my guess is that he wanted to get the job done, get paid and get out of there (which he did).

    I do agree with AndrueC - bad comments are far worse that no comments at all and too many programers simply don't have the understanding of the project to write constructive comments.

  12. The BigYin

    It starts out well...

    ...but then decays.

    "I'll just shim this minor edge case in here...it's easier than re-architecting a bunch of classes" [repeat a few hundred times]

    "Oh crap, this condition was never envisaged...I'll hard code in an if-else block to cope." [repeat a few hundred times]

    "I really should update the docs, but there's no documentation time in the schedule, and I have 100 tasks to do before the end of the week."

    "Unity test? Yeah, I should, but there's no time in the schedule."

    "This code is obvious, I don't need comments."

    "Code review? No time, no time...everyone is too busy."

    "Hmm...fixing this minor UI glitch properly is going to mean re-writing loads of code to provide proper abstraction...the manager won't believe me that such a small change on the UI will take two weeks...better hack it than get into an argument." [repeat a few hundred times]

    [Two years pass]

    "HOLY JAYSUZ! What is this shit? What does that mean? WTF is that branch meant to be doing? Oh dear gawd! Who wrote this piece of shit? Oh, wait....oops"

    You need to allow 3 to 5 times the coding duration if you expect to get quality.

    1. NomNomNom

      Re: It starts out well...

      See this is why I use two identities at work.

      When strolling around the office, attending meetings and performing tidy software fixes everyone knows me as George, but at the desk I can become Ian Sanderson Jr at anytime I need to make a hack fix.

      Who is Ian Sanderson Jr? He is an enigma, no-one has ever seen him but you might occasionally see a commit notice bearing his name. His address in outlook says he works from home out of a remote rural location far from any company office. He rarely responds to emails and his phone number isn't listed.

      People rarely bother Ian Sanderson Jr about his hack fixes.

      1. Matt Bryant Silver badge
        Thumb Up

        Re: Re: It starts out well...

        ".....Ian Sanderson Jr...." Genius!

      2. John Smith 19 Gold badge
        Thumb Up

        Re: It starts out well...

        "Ian Sanderson Jr a"

        The Chuck Findlay of software development.

  13. Paul Johnston
    Alien

    K

    Just looked at the page on Wikipedia for the K programming language, oh my giddy aunt!

  14. Michael H.F. Wilkinson
    Happy

    In academia, students get to see PLENTY of bad code

    They write quite a bit of it themselves!

    Not all the code they see is in books. A lot of it is ill-documented scientific code written on the spur of the moment to check out a new idea. If it works, write a little MatLab wrapper and release into the wild. FUN!!

    Yes, we teach our students how to gather requirements, write documentation, carefully craft the code. However, quite a bit of our own code is written quickly, and the scientific paper serves as the documentation. One reason we get away with it, is that many of our programmes are really rather small snippets reading data, applying the new algorithm to it, and writing some output. In many cases, the code does not get released as production code. Only in larger scale efforts do we apply any thorough software engineering skills.

    So, us academics often don't abide by our own rules.

    Mea culpa, mea culpa, mea maxima culpa!

  15. itzman
    Mushroom

    Compsci from hell.

    Thats the difference between software engineering and computer science.

    Compsci grads want to write clever code.

    Software engineers are taught to write the least amount of clear code that gets the job done.

    1. mhoulden
      Boffin

      Re: Compsci from hell.

      During my uni days someone on my software engineering course complained about having to do loads of "management stuff" when he just wanted to play around learning new languages. After we left I got a job with a large and somewhat bureaucratic company where I find the "management stuff" comes in quite handy and I actually wish I'd paid more attention. Coding is obviously an important part of software development work, but you also need to know among other things:

      1. How to find out exactly what the customer wants when all they've given you is a vague preference

      2. How to manage large projects where there's more than one person involved

      3. What components need to go where if it's a project that spans several systems

      4. How to write it all down in a form so that the managers doing your appraisals and deciding whether or not to pay for a project can understand it

      Some of the more academic bits of software engineering are a bit esoteric for commercial use. I got blank faces when I asked about Jackson diagrams in the first few weeks of my job, and UML kind of came and went. However it is useful to be able to understand what on earth Oracle is going on about in their PL/SQL syntax diagrams. I don't have much use for database predicates using Greek characters but it is useful to know a bit of set theory or normal forms when you're working with complex databases.

      1. bailey86

        Re: Compsci from hell.

        Completely agree.

        And another useful skill is being able to quickly create non-functional, mock-up applications. These are useful for presenting to the managers, etc as discussion points.

        Being able to present a 'story' of how the problem is being solved is very important. Clear naming, some simple diagrams, an overview document can all help to get everybody (managers, IT manager, users) all on the same song sheet.

  16. Bronek Kozicki

    "nearly every sample program in every textbook is a perfect"

    You are f* kidding me. The textbooks are worst offenders in bad quality code, with no respect to any of many constraints of real world code. Exception safety? No, we don't tech that in this chapter, move along! Use of standard algorithms? Why, everyone can write perfect quicksort by hand (haha!)! Synchronous I/O in supposedly high-performance code? But of course, we don't want to make it complex! Ignoring OS API return values? Sure, no one needs them! Use of design patters for sake of design patterns? Everyone is using them!

    I could go on. The point is that, unfortunately, few of really good programmers work in academia or write textbooks (or teach). They have family to feed, mortgage to pay etc. etc. and so they need well paid jobs.

    1. Robert Carnegie Silver badge

      Re: "nearly every sample program in every textbook is a perfect"

      [Thinking in Java] is generally a pretty good book, but it substantially ignores good layout of Java - for which there's a specification - to save lines on the printed page.

      Some stuff in the spec isn't even in Java, only in C, and some stuff that's in Java now isn't in the spec (when I last read it, about a year ago), but it's still valid. (Unstrictly speaking.)

      Also the author has quirks (and doesn't even like Java any more, I hear), and all his examples use his personal set of macros which I'm pretty sure don't add anything in modern versions of Java and maybe never did, except perhaps to look more like C. Or not.

      1. Mage Silver badge

        Re: "nearly every sample program in every textbook is a perfect"

        Macros are evil. Period. One thing I've agreed with Stroustrupp since 1987 on first reading his stuff. Actually most of the bad stuff in C++ may be due to AT&T insisting on as much C compatibility as possible. The first C++ compilers I used actually only pre-processed C++ text to C text creating the magic pointer "this" as a first extra parameter in the C text.

        1. Anonymous Coward
          Stop

          Patently UNTRUE: "Macros are evil. Period"

          I assume you never used a proper macro language such as m4. I assume you never used the -E option of gcc.

          Here is an example of an m4-based vector (and a hashtable) class and I challenge you build something equivalent with templates. Something which gives sane error messages, which will allow for proper code navigation (where is the payload constructor called ??), which allows for proper debugging of the data structure. I bet you can't get it done.

          So your statement holds some water if you refer to "C macros", but even then, some people manage to build huge systems (2000 modules and bigger) based on macro-constructed container classes. E.g. CATIA.

          //vector class

          //$1: type of payload

          define(generate_vector,

          class vector_$1

          {

          $1* _array;

          unsigned long long _length;

          unsigned long long _capacity;

          public:

          vector_$1()

          {

          _array = new $1[1];

          _length = 0;

          _capacity = 1;

          }

          void operator = (const vector_$1& other)

          {

          ensureCapacity(other._length);

          _length = other._length;

          for(unsigned long long i=0; i < _length; i++)

          {

          _array[i] = other._array[i];

          }

          }

          vector_$1(const vector_$1& other)

          {

          _array = NULL;

          _length = 0;

          _capacity = 0;

          *this = other;

          }

          ~vector_$1()

          {

          _length = 0;

          _capacity = 0;

          delete[] _array;

          _array = NULL;

          }

          unsigned long long length() const

          {

          return _length;

          }

          void add($1 element)

          {

          ensureCapacity(_length + 1);

          _array[_length++] = element;

          }

          void ensureCapacity(unsigned long long count)

          {

          if(count >= _capacity)

          {

          unsigned long long newCap = _capacity * 2;

          if(newCap < count)

          {

          newCap = count;

          }

          $1* newArray = new $1[newCap];

          for(unsigned long long i=0; i < _length; i++)

          {

          newArray[i] = _array[i];

          }

          _capacity = newCap;

          delete[] _array;

          _array = newArray;

          }

          }

          void getAt(unsigned long long index,$1& retVal) const

          {

          if( index >= _length)

          {

          //deterministically crash upon out-of-bounds.

          //core file can be easily debugged

          int* crashPtr = NULL; crashPtr[0] = 0;

          }

          retVal = _array[index];

          }

          void setAt(unsigned long long index,const $1& val)

          {

          if( index >= _length)

          {

          //deterministically crash upon out-of-bounds.

          //core file can be easily debugged

          int* crashPtr = NULL; crashPtr[0] = 0;

          }

          _array[index] = val;

          }

          $1 operator[](unsigned long long index)

          {

          if( index >= _length)

          {

          //deterministically crash upon out-of-bounds.

          //core file can be easily debugged

          int* crashPtr = NULL; crashPtr[0] = 0;

          }

          return _array[index];

          }

          const $1 operator[](unsigned long long index) const

          {

          if( index >= _length)

          {

          //deterministically crash upon out-of-bounds.

          //core file can be easily debugged

          int* crashPtr = NULL; crashPtr[0] = 0;

          }

          return _array[index];

          }

          };

          )

          //$1: type of key

          //$2: type of value

          //$3: type of HashHelper

          define(generate_hashtable,

          struct entry_$1_$2_$3

          {

          $1 _key;

          $2 _value;

          entry_$1_$2_$3* _nextInBin;

          bool _isOccupied;

          entry_$1_$2_$3()

          {

          _nextInBin = NULL;

          _isOccupied = false;

          }

          };

          class hashtable_$1_$2_$3

          {

          entry_$1_$2_$3* _bins;

          unsigned long long _numBins;

          unsigned long long _numElements;

          static void insert(entry_$1_$2_$3* bins,

          unsigned long long binCount,

          const $1& key,

          const $2& value)

          {

          unsigned long long index = $3::hash( key ) % binCount;

          if( bins[index]._isOccupied )

          {

          entry_$1_$2_$3* ptr = &bins[index];

          entry_$1_$2_$3* lastPtr;

          do{

          lastPtr = ptr;

          if( $3::equals(ptr->_key,key) )

          {

          break;

          }

          ptr = ptr->_nextInBin;

          }

          while( ptr != NULL );

          entry_$1_$2_$3* newEntry = new entry_$1_$2_$3;

          newEntry->_isOccupied = true;

          newEntry->_key = key;

          newEntry->_value = value;

          lastPtr->_nextInBin = newEntry;

          }

          else

          {

          bins[index]._isOccupied = true;

          bins[index]._key = key;

          bins[index]._value = value;

          }

          }

          public:

          hashtable_$1_$2_$3()

          {

          _bins = new entry_$1_$2_$3[1];

          _numBins = 1;

          _numElements = 0;

          }

          ~hashtable_$1_$2_$3()

          {

          for(unsigned long long i=0; i < _numBins; i++)

          {

          if( _bins[i]._isOccupied )

          {

          entry_$1_$2_$3* ptr = &_bins[i];

          do{

          entry_$1_$2_$3* tobeDeleted = ptr;

          ptr = ptr->_nextInBin;

          if( tobeDeleted != &_bins[i] )

          {

          delete tobeDeleted;

          }

          }

          while( ptr != NULL );

          }

          }

          delete[] _bins;

          _numBins = 0;

          _numElements = 0;

          }

          void insert(const $1& key,const $2& value)

          {

          if( _numBins <= _numElements )

          {

          //grow table

          unsigned long long newSize = _numBins * 2;

          entry_$1_$2_$3* _newBins = new entry_$1_$2_$3[newSize];

          for(unsigned long long i=0; i < _numBins; i++)

          {

          if( _bins[i]._isOccupied )

          {

          entry_$1_$2_$3* ptr = &_bins[i];

          do

          {

          insert( _newBins, newSize, ptr->_key,ptr->_value );

          entry_$1_$2_$3* tobeDeleted = ptr;

          ptr = ptr->_nextInBin;

          if( tobeDeleted != &_bins[i] )

          {

          delete tobeDeleted;

          }

          }

          while( ptr != NULL );

          }

          }

          delete[] _bins;

          _bins = _newBins;

          _numBins = newSize;

          }

          insert( _bins, _numBins, key, value );

          _numElements++;

          }

          bool lookup(const $1& key,$2& value)

          {

          unsigned long long index = $3::hash( key ) % _numBins;

          if( _bins[index]._isOccupied )

          {

          entry_$1_$2_$3* ptr = &_bins[index];

          do

          {

          if( $3::equals(ptr->_key,key) )

          {

          value = ptr->_value;

          return true;

          }

          ptr = ptr->_nextInBin;

          }

          while( ptr != NULL );

          }

          return false;

          }

          };

          )

          #include <stdlib.h>

          namespace MSL

          {

          generate_vector(int)

          generate_vector(PayloadComplex)

          generate_hashtable(string,PayloadComplex,PayloadComplexHasher)

          generate_hashtable(int,int,intHasher)

          }

          1. Anonymous Coward
            Stop

            Re: Patently UNTRUE: "Macros are evil. Period"

            Some more code:

            //must be defined before macro-generated header

            class PayloadComplex

            {

            char* _name;

            char* _street;

            char* _city;

            unsigned int _postcode;

            public:

            PayloadComplex(const char* name,

            const char* street,

            const char* city,

            unsigned int postcode)

            {

            _name = strdup(name);

            _street = strdup(street);

            _city = strdup(city);

            _postcode = postcode;

            }

            PayloadComplex()

            {

            _name = NULL;

            _street = NULL;

            _city = NULL;

            _postcode = 0;

            }

            PayloadComplex(const PayloadComplex& other)

            {

            _name = NULL;

            _street = NULL;

            _city = NULL;

            _postcode = 0;

            *this = other;

            }

            void operator = ( const PayloadComplex& other)

            {

            free(_name);

            _name = strdup(other._name);

            free(_street);

            _street = strdup(other._street);

            free(_city);

            _city = strdup(other._city);

            _postcode = other._postcode;

            }

            void print()

            {

            cout << "PayloadComplex: name: " << _name <<

            " street:" << _street <<

            " city:" << _city;

            }

            ~PayloadComplex()

            {

            free(_name); _name = NULL;

            free(_street); _street = NULL;

            free(_city); _city = NULL;

            _postcode = 0;

            }

            };

            class PayloadComplexHasher

            {

            public:

            static unsigned long long hash(const string& key)

            {

            unsigned long long accumulator = 31415;

            int l = key.length();

            for(int i=0; i < l; i++)

            {

            accumulator += key[i];

            accumulator = (accumulator * 17) ^ 767612781 ^ (accumulator * 9318);

            accumulator ^= ( (accumulator >> 8) ^

            (accumulator >> 7) ^

            (accumulator >> 6) ^

            (accumulator >> 32)

            );

            }

            return accumulator;

            }

            static bool equals(const string& keyA, const string& keyB)

            {

            return ( keyA.compare(keyB) == 0 );

            }

            };

            class intHasher

            {

            public:

            static unsigned long long hash(int key)

            {

            unsigned long accumulator = 31415;

            for(int i=0; i < 3; i++)

            {

            accumulator ^= key;

            accumulator = accumulator * 17 + 77612;

            accumulator = accumulator ^ (accumulator >> 16) ^ (accumulator >> 23) ^ (accumulator >> 7);

            }

            return accumulator;

            //return key;

            }

            static bool equals(int keyA, int keyB)

            {

            return keyA == keyB;

            }

            };

  17. NomNomNom

    they never told me there were textbooks

  18. Bernard

    This issue isn't unusual to computer science

    The legal system and our informal cultural norms are exactly the same.

    The theoretical elegance of beginning anything from a blank page is trumped by the practical utility of working with what's already there and tinkering where necessary.

    Thats why we're still nominally subjects of a monarch, why non-christians frequently celebrate christmas and why company policies and procedures rarely bear any relation to the actual workings of the firm.

    1. Brewster's Angle Grinder Silver badge

      Re: This issue isn't unusual to computer science

      Although parliament generally patches amends existing legislation, it does sometimes rewrite a law from the ground up. We also have the Law Commission who's job is to refactor tidy up existing laws.

      There is no reason refactoring days or permanent refactoring parties couldn't be a stand part of the dev tool kit. Just as there's no reason code review couldn't be a standard part of the dev tool kit. These issues are cultural.

    2. Primus Secundus Tertius

      Re: This issue isn't unusual to computer science

      It is also why Christians celebrate the Roman Saturnalia or the Teutonic Yuletide.

  19. VaalDonkie

    TIim is money

    When a client suddenly decides 75% of the way through the project that something integral to the system should work completely differently, few project managers would have the crown jewels necessary to start a new project from scratch. Instead, one will have to find the quickest way possible to deliver the project on time and within the original budget.

  20. Eclectic Man Silver badge
    Unhappy

    I've seen something like this before ...

    I can't help feeling that the specifc example ofpoor code, is very similar to poor management. As a company starts trying to 'do' things, people find their own ways of doing things that are not clearly written down in agreed policies and procedures (many of which do not quite work or leave gaps).

    This eventually results in a Byzantine system of quirky 'fixes' which some people do, and wich are inconsistent with other people's views. As one manager said to me once "If I find that I want to do something and the rules do not allow it, I ... break the rules." My response "I prefer rules that work", surprisingly did not go down particularly well. (I find that where people have to break the rules to get the work done, each person breaks the rules in a different way.) The theory learnt in an MBA seems all well and good, until you start experiencing the problems caused by your own decisions - much better to get a job with one of the 'big four' consultancies and watch your 'vauled clients' sort out the problems you gave them with your'theoretically correct but functionally incomplete and unsound 'advice'.

    As for code writing, if I draw the flowchart first and get that to work, the only errors in my code are typographical, if I don't draw the flowchart first, I spend about 5 times longer fixing algorithmic (and typographical) problems.

    Merry Christmastide everyone.

    1. Anonymous Coward
      Anonymous Coward

      @Eclectic Man

      I tried to convince management to make a plan with me so that the business and IT can agree on what needed to be done and have a reasonable idea of how long. However management would make the plan, then change it daily until long after the project deadline and something more important came up.

      I insisted on receiving changes by email so I had a chronological log of decisions, especially when they conflicted. The biggest mistake made by a newly appointed IT manager was to implement a bug track system for requesting changes and then giving management access to it. Days later he admitted he should have followed my advice and restricted access to just IT. Needless to say the projects continued to drag even further past the deadlines and original designs had no resemblance to the huge list of conflicting requirements.

    2. Someone Else Silver badge
      Meh

      Flowcharts?

      How quaint.

      1. Primus Secundus Tertius

        Re: Flowcharts?

        Not quaint. It is extremely good to be able to see the logic in two dimensions. Examples: that both outcomes of an if-test are properly handled; that loops are properly constructed; case statements etc.

        If the loops are constructed to follow best practice, they can be described in equivalent one-dimensional language; but they cannot be visualised.

  21. silent_count

    The cycle which produces crap code

    So long as the upper management have their shiny iPads and colourful Power Points to play with they don't want to get "bogged down" in the 'requires more than a 20 second attention span'... I mean, "trivial" details of how their computer systems work. They're busy people and have important work to... ooh look! The picture rotates if I turn my iPad around.

    So the middle managers get paid for delivering projected on budget. If it costs $1k to write and $1 million per year to maintain, the manager has already gotten their bonus and gone on their merry way. If it costs a $1 million to write and $1k per year to maintain, they're out of a job because a "better" middle-manager could have delivered the 'exact same' project for a mere $1k.

    Sure, the numbers are exaggerated but the phenomenon isn't. Oh yeah, and the middle-managers who deliver the cheapest results percolate towards the top and become the upper-management, and the cycle continues.

  22. Some Beggar
    Meh

    "almost all of them in the banking industry"

    Now I don't want to veer into any general derision towards the process and quality control of the financial industry or the competence of engineers who work in backroom banking ... but I think you may have answered your own question here.

    I've worked with embedded software in medical devices and network/consumer comms products for *cough* years and with a couple of notable (and horrifying) examples - typically code that was older than methusela and that nobody dared breathe on let alone re-factor - the quality of the code has been pretty good.

  23. Anonymous Coward
    Anonymous Coward

    Money, actually...

    It all boils down to money. "Management" won't pay enough to get adequately skilled staff, and available time is always constrained by budgets.

    1. Mage Silver badge

      Re: Money, actually...

      I've been working with programmers since 1978. I'm not convinced very many skilled programming staff exist.

      1. Primus Secundus Tertius

        Re: Money, actually...

        I agree. I used to tell outsiders that programming is logic on large scale, and few people in the industry are very good at it.

        Then you look at all the duff medics, accountants, managers, etc and you shrug it all off.

      2. ThePhaedrus
        FAIL

        Re: Money, actually...

        >> I've been working with programmers since 1978. I'm not convinced very many skilled programming staff exist.

        It's always the others that are lacking the skills, isn't it?

      3. Mark Pawelek

        Re: I'm not convinced very many skilled programming staff exist.

        It's still a money problem. If skilled programmers aren't around they could be trained ... but ... "that will cost too much"

  24. Peter Fox

    I, I, I, me, me, me

    Of course programmers have individual styles. Of course yours displeases me for any number of reasons. Now we've dealt with your terrible style we can move on to your structural, conceptual and logical ignorance, mis-application and inadequacies.

    Hey! Why not work together so I can rein-in your weirdnesses and you can admire and learn from my vision and perfection of implementation. Every day! If you're capable I'll let you do some of the easier bits for me and in return you can test my code and fix trivial bugs for me. Aren't I good to you.

    The serious point is that we have to work alone in some respects but should be working together more. I'm not advocating two people with one needle each trying to knit, but if you're writing code for somebody else then it's not your precious secret.

    1. Anonymous Coward
      Anonymous Coward

      Re: I, I, I, me, me, me

      Peter, this is called 'pair programming'. It's very useful, and surprisingly, newer AGILE methods highly recommend this methodology of development. :-)

      I know, I'm preaching to the converted... ;-)

  25. ForthIsNotDead
    Meh

    Just

    Keep your teams small. Programmers perform much better when they have the big picture, and feel that they are a proper member of the development team. A large team will lead to large, overly-complex, bloated code, for no other reason than Johhny Smith, who has been given the task of "unifying the button handler and dispatcher code" will turn it into a lifes work, simply because he has nothing else to do and can make no other contribution.

    Keep your teams small, so that each member is covering quite a large amount of the "solution surface area" (yacky phrase).

    Time required to complete a project is inversely proportional to the number of people involved in it. Not just coders. Project managers, planners, workpackage engineers etc.

    Read "The Mythical Man Month" by Fred Brooks, an ex IBM Project Manager who saw first hand how to guarantee a total fubar project...

    http://en.wikipedia.org/wiki/The_Mythical_Man-Month

    1. Primus Secundus Tertius

      Re: Just

      One of the main points Brooks made was that the best programmers are much much better than the average.

      So then you can succeed with a small project team.

  26. Anonymous Coward
    Anonymous Coward

    Don't use C++ or Perl if there is more than one programmer

    People who advocate those languages always say: "Yes, but you don't have to use all those weird/dangerous features if you don't want to." However, if you have a project with more than one programmer, in the absence of an effective mechanism to prevent people from using weird/dangerous features of the language, someone will use them, and then everyone will have to cope with the consequences.

    Haskell turns out to be surprisingly good for large projects with multiple programmers. It's a lazy, functional language, so it takes a while to learn for someone who's not used to that style of programming, but once you've understood the principles there's really not much to learn or remember, and the module system is excellent.

    The main problem with Haskell that I've encountered is that the performance can be hard to analyse: most of the time it runs fast enough, but occasionally it doesn't and then it can be difficult to understand why and what to do to improve it.

    1. Anonymous Coward
      Anonymous Coward

      Re: Don't use C++ or Perl if there is more than one programmer

      I find the whole functional programming paradigm to be beautiful. Haskell is certainly excellent for large projects with multiple programmers, once they've had the shackles of imperative programming removed.

      I agree that there are some aspects of performance that are hard to analyse, due to laziness, and a few of the big name companies that say they use Haskell actually use a strict in-house variant. However, most of the time the problems boil down to finding a balance between your programs being too lazy, which can build up large unevaluated thunks in memory, and your programs being too strict, which removes all the advantages of a lazy evaluation strategy.

    2. Anonymous Coward
      Thumb Down

      Not True

      If you have skilled developers, proper architecture, proper coding practices (such as not using implicit Perl variables too much), proper documentation, then you can easily have several developers working with C++ or Perl on a single project. Of course, you also need proper management.

      Don't blame a lack of human skills on the language. And, don't tell me you can build large-scale, complex systems such as firefox, openoffice or postgresql in $functionalLanguage. You can build something, but it will perform poorly. It will freeze every minute (on average) for GC.

  27. Terry 6 Silver badge

    Using software

    I'm just a user. (OK a skilled user).

    Hell I know there's crap programming out there. It's hard not to notice when the installation of newly released driver for a piece of equipment from a major company falls over, often because there's a file that didn't get removed, and can't be overwritten. But the old driver has now been killed, and Hey that won't reinstall either- for the same reason.

    Or the firmware upgrade for that shiny superhub that connects all your devices to the internet means that it routinely locks out those devices until it's rebooted ( or randomly reboots itself).

  28. Electric Panda
    Flame

    Can relate to this

    This is all so true. An alarming proportion of "production" code I've seen is awful; poorly documented, shoddily written spaghetti which you are usually expected on pain of death to understand intricately within a nanosecond of opening the project.

    Design patterns? Pfft. Data structures? No need, just use java.lang.io.SuperDuperSwissArmyKnifeSort or the home rolled com.enterprise.selfaware.collectionsframework.overengineerednonsense.doesthesameasthejavaoriginal.broken class instead. The latter was last updated in 2004 by someone who since left the company.

    If I handed in that sort of code as an academic assignment, I could literally have failed. Whoever wrote that code got paid and the horrid code ended up in production.

    What a lot of students also don't realise is that there's often very little new coding going on. Most junior/entry level roles involve taking some self-aware Cthulhu written in an outdated version of Java and poking it with a stick - horrid grunt work the regular staff really deliberately and actively avoid.

    Like all other CS graduates I initially felt that going from university into a coding role was a natural progression. After just one internship I realised the absurdity of it (and reminded myself of how much I hate programming from scratch, although I write scripts to automate things and wrap around pre-existing solutions as required), went back to university to do an InfoSec MSc and now work as a penetration tester and network security analyst. Much more satisfying, much brighter prospects and a good bit better paid.

    What's really funny is that universities just focus non-stop on programming these days, yet the graduates are awesomly ill-prepared for what real programming and software development actually is.

  29. fch

    "textbook perfect code" ...

    ... is rarely found in textbooks, from my experience.

    Why is that so ? Because textbook code is, by virtue of its objective - teaching coding - too simple and too small for the issues associated with paid-for / commercial software development to pop up. It avoids covering issues encountered in developing software not strictly associated with the technical act of coding itself.

    Amongst those, in no particular order:

    Teamwork - the absolute necessity to either work with other programmers or work with project managers, business requirements, your boss and her/his budget - is usually absent from textbooks. If no framework for this exists in the software project at all, it'll end up with interesting "warts" - think of massive code diffs in series of subsequent commits for no other reason than two developers having set their IDE's to "auto-indent" with different rules. Or imagine the odd little key component in an otherwise-pure-Java project pulling in Jython plus a bunch of 50 python modules including a few binary components written in C++, because one developer got away with writing a 50-line piece in Python using those modules since that was so much simpler and faster than the 500 lines it'd have taken in Java. Think about the "write to spec" warts that occur because specs and tests are done first for "validate known-to-be-valid input only", the code is written that way, and half a year someone using it is terribly surprised about the security holes blown into it by obviously-invalid input ... never spec'ed, never tested, never requested ... and no two-way communication anywhere between requirements mgmt, technical architects, project managers, testers and coders. And where in a textbook have you ever seen an example covered so big that you _couldn't_ implement it on your own in a month (Knuth's level 3.5+ exercises notwithstanding) ?

    Complexity - textbooks often are extremely brief on this one, and C.Hoare's "The Emperor's old clothes" is quoted nowhere near as often as it should be. Abstraction, Encapsulation, Specialization, Generalization and other "layering" patterns are often covered extensively from the "how to do it" perspective but warnings about the dangers of extensive layering, respectively guidelines on "good usage" (do you really need to subclass if all you want is to have an object instance that differs from the default-constructed one in a single property ?), or, to put it differently, "when not to use it", are often absent. The coverage of interfacing with pre-existing libraries is often scant. As a consequence, have bunch of new interface layers here, a new generalization there counteracted by an additional specialization elsewhere, and have multiple sequences of conversions resulting a chinese whisper chain of data transfers. Every layer on its own might be a great, well-written, perfectly documented and admired piece of code ... but the combination screams at you just as much as the result on the floor of a night drinking great wine after a michelin-starred ten course meal.

    Libraries - face it, you're not going to write everything from scratch. But which Java programmer knows even a third of the Java 7 classes by name ? Which C++ programmer can use a third of Boost without the manual ? Which C/UNIX programmer knows how to use a third of Linux syscalls ? And that's only _standard_ libraries. Not to talk about the vast worlds of things like Perl or Python's component archives. Effective programming often means effective research into what existing library already-in-use-elsewhere in the project will provide the functionality that you've been considering reimplementing from scratch. Which book teaches this ?

    Legacy - textbooks like to advertise the latest-and-greatest; of course it's a necessary of work life to keep your skills up, and to follow changes and enhancements in the technologies touching your area of expertise, but even more so is it important to develop "code archaeology skills". That is, go backward in time and check out what was considered good practice in 1990, what was cutting edge in 1995, which code patterns and styles were considered best in 2000. Go to the library and read a book on J2EE from 2002 as well as the newest one on Java 7, then grab a 1992 and 2012 Stroupstrup. Read and compare the Documentation/ subdirectory of the Linux kernel sources in the 2.2 and 3.4 versions. Much of this reading will trigger "duh" moments of the same sort that you'll inevitably encounter when you start to look at existing code. Nonetheless, textbooks (or, even more so, lessons/lectures) that emphasize how mistakes are identified, rectified and avoided in future projects are barely existant, else F.Brooks "mythical man month" wouldn't still be so popular more than 40 years after it was written.

    Evolution - coding, and I object to adherents of "software design" here - is never intelligently designed. In the beginning, it's created, and from that point on it evolves. It grows warts, protrusions, cancers that are hindering its adaptibility to the tasks it's set to just as much as new nimble limbs and telepathic powers to help it. A wart for one usecase can be the essential sixth finger for another. Code Veterinary can be a dirty job, and the experience of humility involved with dragging the newborn out past the cr*p of the parent is not something you're prepared for by reading about it, because books don't smell. Often enough there'll be the revolting ethical challenge of becoming a Code Frankenstein as well - when you'll stich a few dead protrusions dug out of a code graveyard by someone onto the already-mistreated beast. It's like textbooks that tell you about how to have fun making babies but not about how to change their nappies or how to deal with teenagers having a fit.

    All of these one can learn to live with; none of these are necessarily perpetuated ad saeculum saeculorum.

    Thing is, "textbook perfect" isn't the same as "beautiful" and that isn't the same as "best for the usecase". The grimy bit about software development is that a really beautiful solution can be built from frankensteinish code, and to develop the skills as well as the thick skin to be able to do this, no textbook I've seen will prepare you for.

    (I still like coding, but sometimes I think I should'be become a vet)

  30. graeme leggett

    Obviousness of bad code - some Friday thoughts

    From what I've read here today, coders know what bad code looks like and that its something they have to write themselves due to the limitations of the situation. Presumably managers either don't know, don't care, or are also mindful of the limitations of "get it done now" and "no, there is no more overtime".

    To a non-coder all code looks like a mess of numbers and letters, and bad code looks no worse than good code. Is there a parallel with mechanial engineering where it is said "it it looks right, it is right" ?

    Perhaps I've got a "practical" mind, if you took the back off a piece of equipment I could (after some peering about) guess whether it was a bit of a lash up or a properly laid out mechanical masterpiece - a mix up of cables and gears or nicely routed and pinned wiring.

    Are there tools that can represent code into a schematic form to make it easier to see how much of a lash-up they are?

    1. John Smith 19 Gold badge
      Unhappy

      Re: Obviousness of bad code - some Friday thoughts

      "Are there tools that can represent code into a schematic form to make it easier to see how much of a lash-up they are?"

      Yes.

      Will management buy them. No.

      Will developers use them. Maybe.

    2. I ain't Spartacus Gold badge

      Re: Obviousness of bad code - some Friday thoughts

      graeme leggett,

      Very true. I sometimes have to get my hands dirty and get building plans, to try and work out what they want for their water services. Some of the drawings are absolutely horrible, and you wonder how they ever get the buildings put up right.

      It took me 2 hours yesterday working through the drawings to get some information that I could have got in 10 minutes if they'd done a proper schematic as well. Also, if you've got a schematic to look at first the drawings (which are necessarily complex, messy and confusing) are a lot easier to understand afterwards. Admittedly it also didn't help that they'd split each floor into 3 separate sheets, and because it went round a corner at one end, had used a blank space on one sheet to put the corner bit, rather than continue onto a fourth. [shudder]

      There are 2 extractor fans, 2' apart, in the kitchen in my flat. My working theory is that the architect drew the ducting in the wrong place (or it was built wrong) and it was easier to just retrofit a new fan in the ceiling than to connect up the extractor above the hob...

  31. Anonymous Coward
    Anonymous Coward

    For my own opinion, after often thinking the same thoughts as the article writer, is that bad source code is so prevalent because we (humans) can afford to have it that way. Nobody likes bad code. But as long as the thing works to some tolerant degree without crashing (1 crash per 1000 uses) there is no real problem.

    When a Civil Engineer builds a bridge that falls down once every thousand times somebody tries to cross it, he'll lose his job. But software isn't so critical. And when it is that critical it is preferrable (subjective but seriously) to use languages that will catch the programmer doing something stupid at compile time (i.e. ADA), instead of languages that let you get away with anything until runtime when your program crashes into a wall.

    So in the end it's a subtle cost/benefit analysis that is subconsciously going on in developers/managers/testers heads. Spend an extra year making a crash proof program doesn't have a lot of benefit if you count the loss of sales, increase payroll etc. Software can afford to have crap code, because usually the cost of a crash is negligible as long as it isn't crashing too often.

    I've worked in teams where we all tried to write perfect, brilliant, clean (Java) code. Only to end up months behind schedule, and to be honest, no obvious benefit, to the final product. Yeah, hardly any crashes or glitches, but if we coded sloppily the crash rate would have still been "tolerable". Sad but true.

    1. Anonymous Coward
      Flame

      Oh Reallyz ??

      You must be the engineering manager of LSE by now. Their business has been eaten by Eurex and I know why.

  32. Anonymous Coward
    Thumb Up

    Ohhhh... this sounds all too familiar

    Especially the 'I'm teh awesome' part involving C++ gurus and their templates. Templates have their place, but without comments to say what they do, it's a puzzle for the poor sods who follow on behind.

    Which is why I liberally sprinkle comments in my code, even if I believe the code is fairly self-explanatory.

  33. Charlie Clark Silver badge

    Poor examples of bad code

    IIRC APL made extensive use of mathematical symbols which made a good choice for implementing algebra. This is a niche area and requires excellent maths skills but that does not in itself make it a bad programming language. Database work would benefit significantly from set algebra literals.

    Similar with Haskell which, while I don't really like the syntax, is extremely well-suited to certain problem domains and as a purely functional language does this with a lot fewer compromises than trying to do the same in a general purpose language.

    1. P_0

      Re: Poor examples of bad code

      APL and it's daughter, J. (Both were creations of Iverson) have their place. As you said, they are great for algebra and Math modelling. Aside from math and just thinking outside the box, they don't have much use, IMHO.

    2. Anonymous Coward
      Anonymous Coward

      Re: Poor examples of bad code

      We're using Haskell to develop an embedded language, and it is the perfect tool for the job.

      Using a piece of obfuscated code as an example of any language is really not a fair representation of that language.

  34. Mage Silver badge
    Mushroom

    The budget isn't the problem

    Maybe 9 out of 10 "high graded" Graduate "Programmers" (there is not just Comp Sci) can't really program well and never will be good programmers.

    You can easily teach a computer language, has anyone ever discovered how to teach programming.

    Comments are a double edged sword, they can become out of sync with code and most people are worse at good comments than programming.

    A decent description of the function, what the parameters are, what the valid range for each is and what the function returns/modifies is of course a minimum. Include tests on each parameter, even if for performance they have to be commented out on final production version.

    1. Christian Berger

      Re: The budget isn't the problem

      Well you would need to do it the way you teach creative writing. You can learn this to some extend. Writers say that one important part of learning how to write is to have read a lot of good works.

      The problem with many programmers is that they have never seen well designed systems. They grew up on DOS, then had Windows. Even though the underlying ideas inside the kernel may have their beauty and elegance, the userspace does not. The result are software packages storing their configuration in SQL databases or binary files, because the developer never saw how else it could be done.

      Take a look at the unixoid world, you see how it could be. You have lots of small simple tools, each one taking text as input and giving text as output. Suddenly you have a whole system of building blocks. You can integrate those blocks to create cool new systems. That way you can learn to segment your program into different parts, each one doing one thing right. It's a powerful way to approach program design.

      For example I recently had to do some firmware for some networked devices. I eventually ended up making something very unix-like. It simply provided the most bang for the buck, as I was able to design orthogonal tools for the job, and those tools can be re-used. That way you could have one script file containing the parameters (e.g. station number) and the other file deriving the lower level settings from those settings (e.g. IP-address) or things like the CPU_ID.

      Of course as with any art form, there are multiple ideas on how to do it. So feel free to disagree.

      1. Anonymous Coward
        Stop

        Re: The budget isn't the problem

        Sometimes the unixoid "little filter" approach works. It does not work if you have to massage massive data sets in shortest possible time. It does not work properly(efficiently) for things like database or web servers.

  35. Anonymous Coward
    Anonymous Coward

    a lot

    of the bad coders I've come across, and I've seen a lot, just don't seem to know any better. It may be a legacy of my company, but historically they were of the opinion that you took a vaguely technical person, sent them on a basic programming language course, and you had yourself a developer.

    A lot of the people don't think in the right way, they don't have the faintest idea how to properly structure things, or how they should be done.

    Some of the worst are the ones who've been doing it for 20 years, don't have the faintest idea, and just keep on doing what they've always done without ever learning.

    1. Christian Berger

      Re: a lot

      I have seen that problem in multiple companies so far. It is very common.

  36. plrndl

    The root cause of this situation is that IT decisions are being made by people who are not qualified to make such decisions, as they have zero understandoing of the consequences (eg Windows for Warships http://www.wired.com/science/discoveries/news/1998/07/13987).

    This is exacerbated by the problem most technically gifted people have with communicating with the technically illiterate. Thus the marketing and money men tend to heard more clearly.

  37. drekka

    My personal experience of years of "Cleaning" other people's code is that 49% is straight out bad design/code and people coding above their skill level. The next 49% is the poor slobs who get lumbered with the code being either too lazy to fix it, or not willing to call a spade a spade when talking to management.

    I've lost track of the number of projects I've had dumped on me only to find undocumented, unreadable, over-engineered piles of poo. Some I've thrown out and re-written, some I've patched into shape over time.

    The real skill is knowing that in a lot of cases, you can fix a lot of things by deleting more code than you will write.

    1. John Smith 19 Gold badge
      Unhappy

      "The real skill is knowing that in a lot of cases, you can fix a lot of things by deleting more code than you will write."

      Absolutely correct.

      I had a data load program to update which read a lot of different record types from a file. The record type was a field of each record in a standard location within the record.

      A near perfect use of a CASE statement.

      The original programmer did it with a near impenetrable (and unmodifiable) IF/THEN/ELSE/IF/THEN/ELSE chain instead.

      He did not seem aware the language supported a CASE statement.

      1. Christian Berger

        Hmm, I know this is just nitpicking, but the better solution might have been to have a table listing the types of records and what to do with them (for example function pointers to functions processing them, or some other description) and then have a tiny little parser just looking up the record type and doing what the table says.

        That way you can not only trivially change things, but you can even automatically sanity check your table if you wish to. If you document your table and or make it obvious, people will be able to easily edit it.

        There is a point for if/then/else/if though: case is yet another language feature, and the more language features you use the harder it becomes to read for a beginner. Properly made if/then/else/if chains can be just as maintainable if properly made.

      2. Anonymous Coward
        Anonymous Coward

        There are sometimes very good reasons for using IF THEN ELSE statements instead of CASE ones... ;-)

    2. Anonymous Coward
      Anonymous Coward

      maths

      And the last 5% is basic math errors!

  38. Kubla Cant Silver badge

    Recognise this picture?

    The team contains ten developers. Skill and experience in the team follows a Pareto distribution: two have extensive experience and strong skills, two are very talented but have limited experience, two are people who went into software engineering because they thought it was a well-paid job. The remaining four are recent graduates, one of whom seems to have managed to complete a degree and get a programming internship without knowing what ctrl-C and ctrl-V do.

    Any new piece of work is given to team members 3 to 10. Numbers 1 and 2 spend most of their time maintaining the production software. Because it was written by 3 to 10, there is a lot of maintenance to be done, and the code is hard to follow. The rest of the time is spent mentoring the graduates, but this doesn't really make much difference to the overall picture because they move on almost as soon as they know anything.

    Bitter? Me?

    1. Christian Berger

      In that case, a question of management

      That's probably a case of bad management.

      1 and 2 should be mentoring 3 to 10 on maintaining the production software and checking their solutions to problems. That way 3 to 10 will gradually become more and more competent.

      The rest of their time they should develop/help develop the new projects.

      If you want to have good work done, make your workplace a good place to work. Make it exciting, make your people learn a new thing every day. Give them the feeling that their work counts and that making better code is better.

    2. Unlimited
      Stop

      Re: Recognise this picture?

      No. Have you heard of a concept called "code review"?

      Graduate commits crappy code. Senior dev rejects the commit and tells grad why. Grad fixes it and learns.

      1. Christian Berger

        Re: Recognise this picture?

        Yes, that should be the way to go. Unfortunately code reviews don't exist in most real companies as it can be a form of negative critique. That's a big no-no in real companies.

        1. Mark Pawelek

          Re: Recognise this picture?

          This is another management problem. By not embedding code-review into normal production process, a problem like this is caused when ever someone tries to introduce code review from the ground up. Comment on someone's code and they'll regard it as either a personal attack. In such places managers are likely to be predominantly ignorant of coding. The best thing you can do is leave such a place.

          PS: Code review is one of the few coding practices for which there is overwhelming evidence in favour. Aka - everyone should be doing it (or pairing).

      2. Anonymous Coward
        Anonymous Coward

        Re: Recognise this picture?

        >No. Have you heard of a concept called "code review"?

        Graduate commits crappy code. Senior dev rejects the commit and tells grad why. Grad fixes it and learns.

        Nowadays it's more like offshore dev submits crappy code, senior dev rejects it with detailed reasons, citing several examples and describing how to resolve.

        Offshore dev resubmits with only the explicitly cited examples fixed, it's rejected again for issues with the 'fix' and citing explicitly each area that needs correcting.

        Rinse and repeat until senior dev gets fed up and just accepts it or fixes it themselves!

        Next week, the same dev submits code with exactly the same issues. Repeat ad-nauseum no one learning anything from the mistakes and reviews.

        If the seniors aren't allowed to code themselves anymore it gets really painful, I've seen code reviews where everyone's so fed up the 4th/5th rejection just contains the correct code and just says paste this in

  39. graeme leggett

    coder reactions to bad code

    assuming you're an outside consultant brought in to look at a project, does anyone ever

    suck in air through their teeth

    shake their head

    say "you've had some right cowboy install this lot"

  40. A J Stiles

    We can only guess

    The first versions of the Mozilla suite and OpenOffice.org were basically formerly-proprietary projects which were suddenly Open Sourced. And they were riddled with schoolkid errors (OOo 1.x wouldn't even build on anything but 32 bits).

    Knowing that there will be many strangers' eyes looking at your code tends to make you write it properly (and "properly" means -Wall doesn't say a dicky-bird); seeing someone else's bad code that could have been done better makes you think seriously about submitting a patch upstream. (Both these are examples of Hubris -- the third great virtue of a programmer).

    We can only guess what other horrendous bodges lurk in other proprietary software.

    1. Christian Berger

      Re: We can only guess

      "We can only guess what other horrendous bodges lurk in other proprietary software."

      Well actually we can know, since we can work there. When I was a programmer I worked on a software package which long unsupported and unused which among many things printed receipts, bills and delivery notices. All of those contained VAT calculations. Well eventually it turned out that there was an error in the calculation under certain circumstances. The error was consistent in all the forms. So I looked for the routine to calculate the VAT found one and fixed the problem... Then there still was the same problem in another form. Turns out there were 3 (or so) versions of that code. 2 were just slightly modified copies of each other, while one was completely original. They all managed to have the same bug.

      Then in another part of that project, probably the oldest part there were 2 forms which had to communicate some values. Now Delphi (yes this is old) does support variables and structures (called records) as well as events. However the developer chose to store the values into a local dBase table (I told you this is old), which was supposed to only contain one dataset, then the other window opened that table and you were able to edit it. (that's actually quite simple on Delphi) Of course when your program crashed when that table was open you had 2 datasets in there and it would fail.

      Once we had an intern who was given the task to write an import program which should import a certain fairly complex file format into our databases. He did this by transforming the data in multiple steps (by itself not a bad idea) and used pre-created dBase tables for the intermediate results (bad idea, what if they aren't empty or are broken?) and every step used global variables. What made it unbearable was that those steps were semi-transparent to the user. So the user had to press several buttons after each other. Each press would send the computer working for quite a few minutes.

  41. koolholio
    Go

    Cant get the staff these days!

    This is why you hire a project manager that has a background in the project's development.

    Developers are very much in their own right artistic, some with licenses others not, yet modulated software development ... makes portability, troubleshooting and development much easier from the word 'Go'!

    The output is only going to be as good as the input was in the first place! Never blame the developer, blame the culture of the **** for brains pressuring him to get something out the door!

  42. John Smith 19 Gold badge
    Flame

    Do they call it computer art or computer science?

    There is only one way it's your code.

    You develop it.

    No one else ever maintains or updates it.

    When you die all copies of the software will be erased and the source code destroyed (perhaps in viking funeral along with yourself).

    Otherwise get over yourself and expect to have your code reviewed and you to review others.

    And remember "Premature optimization is the root of all evil."

    Me p**sed off. You bet.

  43. Anonymous Coward
    Anonymous Coward

    I'm just gonna come out and say it....programming is not an art. And the thinking that it is, is a very big part of the problem.

    It really, really annoys me whenI see a developer who refers to himself as an "engineer" one minute, and the next starts pontificating about how programming is an "art", and you have to "see the structure", and lots of waffle. This is one of the roots of the problem. Real engineers follow plans, methodologies, blueprints etc. The number of coders I see who think they are smarter than everyone else and try to do it their way, makes me pity the whole industry.

    What programming really needs is a professional body that can dole out certifications and professional qualifications. So your a Python hacker? Have you passed the Institute of Programmer's exam? No. Get lost. Why do engineers, lawyers, accountants etc have professional bodies when programming can't. It would drive through standards that everyone will follow. Not like now, when you join a new company and you don't know what kind of weird methodologies they use. Every company has it's own idiosyncrasies when it comes to code. Why? It should be standardized with a professional body.

    I know almost everyone would hate this idea, because it goes against some kind of hacker, free-to-do-what-I-want mentality that pervades the industry. But if standards are to rise it's going to happen eventually. Do 3/4 years at Uni then join a company which sponsors you to take your "Chartered Programmer" exam, while also working for them.

    1. heyrick Silver badge

      "and you have to "see the structure"" - easily done, just point me at the right header file. Oh, you didn't mean a literal struct. Okay, where's the internal documentation that shows how it fits together?

      This is one of the other roots of the problem. People immersed in a project are the best ones to document it, but documentation is frequently erratic, incomplete, and out of date. Not just internal descriptions of "how this collection of crap fits together" but often user documentation. How often have you started to use a new program to find the documentation is hopeless or just plain missing? Where sometimes the only docs you see are COPYING.TXT (the GPL text)...

      "Why do engineers, lawyers, accountants etc have professional bodies when programming can't. It would drive through standards that everyone will follow."

      First, it would kill off home programming - for attaining such standards will probably out of budget for a person coding in their free time.

      Second, it could stand to kill off open source - take your favourite part of Linux, are we to restrict code access to those who have qualifications only? What if a non-qualified person has a submission?

      Third, it could stand to kill off software generally - we all know that software licences disclaim everything possible. We bitch about it, but as programmers we accept it because while our systems may crash from time to time, it's a safety net for our own code to be able to crash without the world ending. Obviously this is undesirable, but away from egotism, I understand that people are human and humans cock up from time to time. Do you think if software was written by accredited professionals (and no doubt more expensive because of it) that we'd expect to continue seeing "this product is supplied AS-IS" and the rest in the small print? Would you get on a plane if it had a sticker on the side that says that the manufacturer disclaims all liability for explosions or structure failure in flight (etc)?

      "Every company has it's own idiosyncrasies when it comes to code. Why? It should be standardized with a professional body."

      Yes, it should. And to make life so much easier we need to throw away all these stupid languages and just use one. If it can be expressed in Haskell or K or perl or any of the others mentioned in this article, it can be written in C.

      Yes, I'm being sarcastic. There is no such thing as standardisation of coding practice when it's an entity that covers hundreds of related but very different cases. Examples:

      * Kernel coding

      * Large scale embedded devices (routers, video recorders, cash machines)

      * Small scale embedded devices (bread makers, ECUs, pacemakers)

      * Desktop publishers and word processors

      * Fart apps

      * Website back ends, maybe e-commerce stuff

      * Educational/research systems; both the underlying system and the nerd-level stuff running on them

      All of this (and more) is software engineering. There's no one standarisation that applies to all of them. Writing a kernel is very different to writing a fart app; and none of this "runs of a PC" sort of code has any relevance when you're hand-coding an entire system to run on an 8051 clone to power a breadmaker, where your code must be less than a few kilobytes and if you're lucky you might have 128 bytes of memory. But you absolutely cannot crash, not when you have a tiny oven turned on!

      [FWIW - the breadmakers I've seen suck hard at proving the bread except in summer because they use fixed-duration timers instead of checking the ambient temperature; a cost/difficulty compromise perhaps?]

      Do you not think this idea hasn't already been touted a dozen times before, and discarded as unworkable? Surely it is far better to foster the idea of good coding practice?

      Here is an idea of my own, for college/uni programmers. You get to write something, and you get to maintain something previously written. What you get to maintain is what a person the year before you wrote; just as your creation will be given to somebody in the year following. This should hopefully demonstrate hands-on the need for clear concise code, where being obvious and unambiguous is far better than abusing the comma operator or burying stuff in a messy algorithm that relies absolutely upon the operator precedence of the language, or other "clever tricks" that only serve to demonstrate what a twat the author is. The person in college/uni can laugh at the poor code in their maintain project, and scratch their head over the stuff that makes no sense, until they have the realisation that their project could be treated in the exact same way by somebody else.

      Another option, halfway through the year, swap projects. And you get marked up or down depending upon what the person now maintaining the code thinks of how it was written.

    2. Christian Berger

      I wouldn't make that point

      I think that engineering and art are essentially the same. An artist creates works to cause certain effects. For example he might arrange metal to cause fear in the person who looks at the work. An engineer could arrange metal to form a generator. Both use science to achieve means in a way which doesn't have any "best" way to solve a problem. Just look at the many different ways the problem of 'television' has been solved in the last 80 years. Both fields are highly influenced by what happens with their peers and in science.

      The big difference is that artists typically have a portfolio. If you are a bad artist you won't get many jobs. In classical engineering there are certifications to pass. If you are a bad engineer you won't pass them.

      Now with programming there is often neither widespread certification nor portfolios. Slowly portfolios start to pop open with open source software. Probably in a few years you will be unemployable unless you have some portfolio of open source software.

      1. Destroy All Monsters Silver badge

        Re: I wouldn't make that point

        I think that engineering and art are essentially the same.

        Really, only someone still at uni, a tenured prof in an isolated ivory tower or manager on an ISO 9000 trip thinks different.

        This is why there is a book by Fred Brooks called "The Design of Design".

        This is why Knuth titled his books "The Art of Computer Programming"

        Then we have "Beautiful Code" ... "Programming Pearls" ...

        Even Edsger Dijkstra who tried to light the fire of program proofs needed to pull artsy and sometimes impenetrable code from god knows where to fill his textbooks.

    3. Steen Hive
      WTF?

      "Real engineers follow plans, methodologies, blueprints etc."

      Hurrah for plans, methodologies and blueprints:

      http://en.wikipedia.org/wiki/List_of_bridge_failures

      What's your point? Software isn't any different from engineering or art - it is both functional and aesthetic. You spend an amount and standardise an amount and test an amount depending on your priorities, your budget and the risks to people and businesses using it. If failure in your software implies similar consequences to structural failure in a bridge , then the testing and commissioning of your software should be every bit as rigorous as for its physical analogue. Otherwise you are just over-engineering a white elephant.

      1. John Smith 19 Gold badge
        Meh

        @Steen Hive

        "http://en.wikipedia.org/wiki/List_of_bridge_failures"

        Perhaps you should study that list a little more carefully.

        Software development has more in common with bridge building that you might think. One of the points made in Structured Programming (Mills, Linger & Witt) was that to do top down development your first release had to be a "proper top," a system that could be tested and bootstrap the testing of the rest of the functions. IOW functions to add records to a database (1st release, you can inspect the file contents with existing tools to check it works) get the ball rolling. Read and update functions can be deferred till the 2nd increment. Once you move away from database systems those decisions become more difficult to make.

        typical software development works bottom up. It's like throwing bricks up in the air and hoping they will align well enough so that the structure will become self supporting before they all fall down.

        Put that way is it any surprise large systems tend to have development issues?

        The point about bridges is that there has been a steadily expanding body of theory to support their design. Study why bridges fall down. The main reason has shifted from "We don't know how to build them well enough not to" to bad (sometimes illegal) construction and/or materials and gross overloading. 160tonne vehicle on a bridge rated at 40 tonnes. WTF did they think was going to happen?.

        In contrast there has been limited work in improving the odds of delivering large projects on time and budget. Perhaps more usefully has been the study of government IT project failures. Here shifting objectives, lack of senior management commitment and a desire for big bang rollout (no pilots and limited live testing) usually turn up in the top 5 ways to f**k up a project. I doubt private industry is that much different in any of these respects.

        1. Destroy All Monsters Silver badge
          Stop

          Purists doing their purist faps

          > "proper top," a system that could be tested and bootstrap the testing of the rest of the functions.

          Yeah well, that really sounds like the "bottom" to me.

          Redefine the words. Voilà, we are top down? Whatever keeps the project rolling and avoids the waterfall path into immediate obsolescence, I reckon. The goal is success any way you look at it.

    4. Anonymous Coward
      Anonymous Coward

      Engineer derives from ingenious. That is creative, is artistic. Being a real engineer combines that and making it completely useful from the idea to having millions of happy users (I may only have had 10s of thousands..). But yeah. there are is a lot of wankiness out there.

  44. MissingSecurity
    Pint

    The problems I see...

    You whats funny about this "most programmers have no clue what there doing" articles? They never seem to point you in the direction of what is "right". (And I don't disagree that there are many bad programmers)

    I'm not a developer (well its not my title LOL), but that doesn't mean I don't have basic understanding of coding. Like other people in my situation, I learned programming on my own through books and tutorials online. I personally like python for write scripts, and quick and dirty programs for my self.

    I don't plan to go into development (well I'd go back to school for it probably), but that doesn't mean that I haven't tried looking for articles, tutorials, and things on "proper programming". I'd prefer my programs are written correctly (since is my time and money) so that I have good code, but I haven't found any source that is an agree upon method of r doing anything regarding programming.

    Dog + World can go online and learn the individual pieces of a programming language, I just haven't been able to find any good resources (Which could be do to my lack of programming knowledge) which I can trust.

    And since "bad programmers" tend to search online and pull shit off it, I'd think the communities of programmers would tout this concept more.

    1. Christian Berger

      Re: The problems I see...

      The problem is that there is no single direction of "right". There are only principles you can choose to adopt. And there are good examples to follow as well as bad examples to avoid. Then depending on what you are trying to do you can choose the best way to do it.

      Look at books like "The Art of Unix Programming" and look at what they propose. Those are pointers to right directions.

    2. Anonymous Coward
      Go

      Re: The problems I see...

      You could

      A) Start studying Computer Science. It's not sufficient, but necessary to become a proper software engineer. Think of hash tables, parsers, complexity analysis and the like.

      B) Join something like ACM or IEEE

      C) Read books on Object-Oriented Analysis and Design, Use-case driven design. Very concrete approach in my opinion

      D) Read books on Database Design such as Mr. Date's book.

      E) Read IBM, HP, MS, Google technical reports/R&D magazines and try to understand them.

      F) Develop toy projects

      G) Take five years to become a C++ expert

      All these activities will take years of your life for relatively little reward. But at one point you will be a master of your trade and you can give the idiots the middle finger then and now.

      1. Christian Berger

        Re: The problems I see...

        Well you should always broaden your approach. Don't be an OOP and database only person. Look at other approaches. Look into Lisp or Prolog. Look at Unix. Again there is no single good approach.

        For me actually G) is the reason why I ignore C++. I have looked into it previously and never was able to figure out where the actual advantage is supposed to be. I mean I can have C++-like OOP in Pascal these days and it even handles objects with references and never implicitly copies an object.

        Unfortunately the point where being a master of the trade matters may never come. Competency is not valued in real-life companies. You'll still end up having to deal with incompetent bosses believing they can do better than you.

        1. Anonymous Coward
          Paris Hilton

          Well

          There are many, many nasty things to say about C++, but in the hands of a Master (of the trade, not the academic thing), it can be used to create amazing things.

          There was a time I would have called it "just a programming language like many others", but now I do think it deserves the massive investment in time, books and ripped out hair to become an expert. When you know more about the details of the memory hierarchy and about the dog-slowness of the new-operator (or equivalent in other languages), you will appreciate why you have this elaborate thing called C++.

          AFAIK, you cannot allocate objects on the stack in Pascal, which is a major deficiency, performance-wise.

          http://www.freepascal.org/docs-html/ref/refch6.html

          Or maybe not, I am not an expert in Object Pascal.

          According to the Language Shootout, C++ is leading in runtime and memory efficiency and that does indeed translate into usability, "user experience", into perfection of a product. I do think there is a strong reason why they used Objective C for the iphone, and not Java. With Java, you are just "good enough" from a usability point of view, with C variants you can be "perfect". I would take Pascal over Java any time, though.

          And yes, managers know that truly competent people can give them the middle finger. They hate that fact, but they are rational enough to not fire these people as they would fire unskilled people. They bitch and moan, but in the end they have to somehow accept that the experienced C++ guy cannot be shoved around like the the Java greenhorn from uni.

          And if you are truly pissed off, insult the boss to make him fire you. Then collect unemployment benefits for three months while you weigh your new opportunities. Not perfect, but tell me which job is perfect outside "being rich and stupid heir" ??

          Picture of said heir.

          1. Christian Berger

            Re: Well

            The Pascal-Culture considers Object creation to be something expensive. The whole Pascal world is designed to deal with it. Just like the Pascal world seals with not having implicit object copies.

          2. heyrick Silver badge

            Re: Well

            "AFAIK, you cannot allocate objects on the stack in Pascal, which is a major deficiency, performance-wise."

            Errr... Wouldn't this depend upon the ins and outs of the architecture upon which the language was running as to whether it preferred registers or stacking stuff?

            That said, if we burn a hundred cycles, say, retrieving something that another language might have stacked for a cost of, say, 20 cycles... That's 80 cycles. On a 2+GHz processor. I'm just making up these numbers as I'm an ARM guy and I know very little about x86, suffice to say at today's clock speeds, I would imagine the choice of a good algorithm would make more impact than whether or not stuff can be stacked...

    3. Mark Pawelek

      Re: They never seem to point you in the direction of what is "right"

      They never seem to point you in the direction of what is "right"

      They do. Just remember that there is no such thing as quick and dirty; there's either clean and working or slow, dirty and horrid. http://allankelly.blogspot.co.uk/2009/09/quick-dirty-myth.html

      All sorts of people have written good books on how to write good code. Such as:

      Michael Feathers - Working Effectively with Legacy Code

      Steve McConnell - Code Complete: A Practical Handbook of Software Construction

      Steve Freeman and Nat Pryce - Growing Object-Oriented Software, Guided by Tests

      Martin Fowler et al - Refactoring: Improving the Design of Existing Code

      Bob Martin - Clean Code

      Bob Martin - Agile Principles, Patterns and Practices in C#

      Bob Martin - Agile Software Development, Principles, Patterns, and Practices

      Neal Ford - The Practical Programmer

      Furthermore there are now lots of free courses teaching programming on the internet at places like coursera, Udacity, edX. Someone's even written an aggregator for you: http://www.class-central.com/

  45. Anonymous Coward
    Anonymous Coward

    In my experience people fixing code could be divided into "developer" and "supporter" types.

    The "developer" mentality always wanted to impose their own design. This resulted in blisters that stood out like a sore thumb - and often introduced secondary problems.

    The "support" mentality was to spend a long time understanding how the original code worked - then applying a minimal tweak that was indistinguishable from the original coding.

    One piece of code had been enhanced to support two instances of a structure. The enhancement "developer" had written numerous inline tests to keep determining which of the two control structures was in use. Later, when multiple instances were needed, a "support" person ripped out all those binary tests - and added one initial line which set the base register to point to the appropriate control structure.

    The biggest pitfall is to notice, in passing, something is "wrong" and immediately fix it - and the law of unintended consequences comes into play.

    The first rule of documentation/comments is that the more precise the detail - the more likely it is to now be wrong. Useful comments are the ones that explain why an "obvious" alternative/simpler approach had been tried and didn't work.

    1. Anonymous Coward
      Stop

      Too Simple

      Sometimes you are charged with "improving performance" and that means redoing lots of code and obviously introducing new bugs. And new bugfixes for that. It sometimes means changing the architecture in some ways.

      But yes, every change is a risk that should be weighed against benefits. Changes for prettiness are too expensive and too dangerous.

  46. Stephen Channell
    Unhappy

    Clearly never worked on one of my projects!

    The comment “nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is,” goes to the root of the problem.. because it is just not true text-books often have coding errors & many examples are banal.

    Students that are taught to ignore {transactions, Exceptions, Recovery, Logging, instrumentation, performance, scalability, maintainability} are not being taught to “focus on the algorithm” they are being taught to be sloppy. Poor coding tuition is compounded by poor design tuition (e.g. Manager is a specialization of Employee, or GoF state-pattern). The problem is that whilst the quality of tuition is variable, different institutions are variable in different ways.. and students think they’re brilliant.

    Many systems (particularly in finance) are so woeful because trainees (in the art of software engineering) have no real training in quality engineering; and resort to hacks to get through. Meanwhile an earlier generation who didn’t graduate to quality professional before moved into management are directing, but are afraid to tell sponsors how long development really takes.. because they don’t know. You only need to do 1 or 2 well engineered systems to know that good design saves time & modeling really is free.

    There is hope: some practitioners are excellent; tools are getting better; frameworks are getting better; platforms are standardizing.

    Sure an awful lot of real world code sucks, but some of it is quite beautiful!

  47. Anonymous Coward
    Anonymous Coward

    Chilling words

    An ex-minion, new to the company joined us and said "I wanted to see how everthing I learnt, such as design patterns and so on, worked in the real world".

    "Sporadically"?

  48. CCCP
    Coat

    From the grammar in some posts here...

    ...I'm not surprised that comments in code sometimes make no sense.

    /runs out the door coat flailing

  49. heyrick Silver badge

    Sometimes it isn't the coders...

    A beeelion years ago, I did a sort of internship at a place where there were keyboard monkeys writing code to specification. I'm not being rude, they called themselves that too. Because Specification Was King and the managers and such who made the specification expected it to be followed exactly. To give an idea, multiply an integer by two. A coder will think that if it is always an integer (yes) and always by two (yes), a left shift would do it. But no, the specification said multiply so a multipication function was called (before CPUs had this sort of stuff onboard) and a result returned many many clock cycles later.

    There were many more examples of people who didn't understand the underlying system expecting a spec to be followed to the letter; it was particularly fun when the spec contradicted itself (which it did frequently in the parts about "handling events" (they meant interrupts)), not to mention controversies such as the system blowing up on the first interrupt because the ISR wasn't cleared because the spec writers didn't know there was one and the coders (who knew) followed the spec (intentionally).

    Maybe this was Programmer Hell? I don't know. It's why I code as a hobby but dropped any ambition to do it professionally. I enjoy what I do, and the above sounded as far from enjoyable as possible without actual physical harm being involved.

  50. cortland

    So you're sitting in an airplame when...

    http://www.computerweekly.com/blogs/cwdn/2012/01/does-your-boeing-787-flight-use-on-chip-debugging.html

  51. Anonymous Coward
    Anonymous Coward

    Banking tends to have poor developers

    I have never worked in banking but I did work in a medical device company that had a lot of software developers leave for the banking industry. Several cam back becaus ethe complained that the technical demands of software in finance was vry very low, the level of skill of other developers especially senior ones wa satrocious and they were bored. The pay was of course much higher.

    One specific colleague said that he was taken aside by his manager for producing software too quickly to too high a standard. He had spoken to the end users, written and developed a requirmenst specification, reviewed it with the users, prototyped the code, evaluated itwith ethe user and devloped an automatiuc test suite and was about to deliver it. His manager told him to stop work for two months otherwise it would cause a problem in setting an expectation for the amount of time and effort required to prodcue similar applications.

    When interviewing staff it is rare t meet a competent long term developer who has worke din teh finance sector but they have extraoridnarily high salary expectations. This is a big issue if you find the need to develop using paltofrms and tools popular in finance.

    I think the reason is that within the banking culture generally there is a very high level of pay unrelated to skill and ability. The people managing these organisations like to believe that pay level is related to skill and expertise because that makes them feel comfortable about their own very high renumeration, unfortunately recrutiment of staff on this basis has lead to an organisation and culture of highly paid incompetence.

    I am sure theer are some highly skilled developers in the banking world but...

    1. Anonymous Coward
      Flame

      You Nailed It

      Finance is to a large degree a scam designed to enrich the employees of said industry. Sometimes they even try to crash the whole economy in the process of enrichment.

      If salary is the sole determinant of happiness, rip out your spine and "go finance".

      1. Destroy All Monsters Silver badge
        Trollface

        Banking and Trading Software: LOL Incompetence and dumping risk on consumers

        This one I like to repost again and again (Google reveals: more often than I can remember. Frak you, Google!)

        "Social Impact of Information System Failures"

        IEEE Computer, June 2009 (Vol 42. Issue 6, pages 58-65); Tamai, T.

        The case of Mizuho Securities versus the Tokyo Stock Exchange (TSE) is archived in the 12 December 2005 issue of the Risks Digest, and additional information can be obtained from sources such as the Times and the New York Times, among others.

        The incident started with the mistyping of an order to sell a share of J-Com, a start-up recruiting company, on the day its shares were first offered to the public. An employee at Mizuho Securities, intending to sell one share at 610,000 yen, mistakenly typed an order to sell 610,000 shares at 1 yen.

        What happened after that was beyond imagination. The order went through and was accepted by the Tokyo Stock Exchange Order System. Mizuho noticed the blunder and tried to withdraw the order, but the cancel command failed repeatedly. Thus, it was obliged to start buying back the shares itself to cut the loss. In the end, Mizuho’s total loss amounted to 40 billion yen ($225 million). Four days later, TSE called a news conference and admitted that the cancel command issued by Mizuho failed because of a program error in the TSE system. Mizuho demanded compensation for the loss, but TSE refused. Then, Mizuho sued TSE for damages.

        ....We then segue into design horror....

        The part of the system that handles order cancellation appears to have low modularity. The logic in part B of the flowchart made a wrong judgment because the information telling it that the target order had induced the reverse special quote had been temporarily written on the Stock Brand DB by the order matching module and had already been cleared. This implies an accidental module coupling between the order matching and order cancelling modules. The order cancellation module appears to have insufficient cohesion as different functions are overloaded. It is not clear how the tasks of searching the target order to be canceled, determining cancellability, executing cancellation, and updating the database are this module’s responsibility.

        etc. etc.

        There is a grabbable copy on the Internets, so no need to pay abject obeisance to the IEEE paywall.

  52. Primus Secundus Tertius

    Sabotage a Friday Afternoon

    I have enjoyed reading all the comments here. But how much actual work did those guys and gals do this afternoon?

    Me, I'm retired. I enjoy my freedom.

    1. Anonymous Coward
      Anonymous Coward

      Re: Sabotage a Friday Afternoon

      None whatsoever, are you going to report me or should I also state that I'm on annual leave now? :)

  53. Anonymous Coward
    Anonymous Coward

    Your pain, I feel it

    The saying at my workplace is that our IT motto is "World-Class For Free". The current reason upper management gives for there being no money to hire enough people to maintain the system, let alone upgrade it, is that the users on the business side don't complain enough about it. Has anyone else ever wished for less forbearance from their users...?

    Yes, my resume is in active circulation!

  54. Anonymous Coward
    Anonymous Coward

    Starting on the wrong foot?

    " nearly every sample program in every textbook is a perfect and well-thought-out specimen"

    Maybe in some abstract mathematical proof sense, but in reality many samples say things like "error handling omitted for clarity".

    1. Unlimited
      Terminator

      Re: Starting on the wrong foot?

      I'd go further: They are rarely perfect, and almost always only a specimen of a tiny fragment of a real world system.

  55. Anonymous Coward
    Anonymous Coward

    wait...

    Snoofle? Is that you?

  56. ThePhaedrus
    WTF?

    So where are all the bad ones

    So, we've had a bunch of comments here generally complaining about the crapness of other people's code, about how crap most programmers are and about the crap state of programming in general.

    So please tell me: where are all the crap programmers? Have a look in the mirror..

    Most programmers think they are above average. Just saying...

    1. Christian Berger

      Re: So where are all the bad ones

      Absolutely. That's why you should look at the ones who believe they are average and admit they have huge gaps in their knowledge. Look at what they have done, maybe give them a few puzzles to solve like giving them a "hello world" program with an obvious buffer overrun inside and see if they'll find it.

      Like give them this program and ask them what it does:

      #include <stdio.h>

      char *s[10];

      void main() {

      printf("Enter your name: ");

      scanf("%s",s);

      printf("Hello ");

      printf(s);

      }

      Nobody will find _all_ the bugs, but it gives you valuable insights into how the programmer thinks.

      1. Anonymous Coward
        Stop

        All Your Errorz

        1.) You are declaring an array of char* pointers, not an array of chars

        2.) main has to return something and accept some arguments (argc and argv), IIRC

        3.) scanf gets a bad argument (expects char* not char**) and will make a buffer overflow if the user wants to

        4.) printf(s) will generate another buffer overflow mess if the user enters something like "jdfhj%sdfkdfkjdkfj"

        5.) missing "return 1"

        I would say your quiz was rather "average". Have seen much, much more nasty code samples.

      2. kraut

        Re: So where are all the bad ones

        void main?

        char *s[10]; - should be char s[256];

        1. Destroy All Monsters Silver badge
          Headmaster

          Re: So where are all the bad ones

          Magic number detected.

  57. Unlimited
    FAIL

    The author is not a good programmer

    "The most common reason for the existence of bad software is bad programmers"

    There are a lot of them that's true. But they can be guided by one good senior dev given the time to do code reviews. In my experience, the reason for bad software is vague requirements and impossible deadlines caused by salesmen telling pure lies.

    "For the record, however, I don’t think I’ve ever seen anyone go back and clean up a quick-and-dirty fix"

    Then you yourself are a bad programmer. Or one of those fly by night contractors. Personally I will very often replace dirty with clean when a new requirement would otherwise require to layer on some more quick and dirty.

  58. John Smith 19 Gold badge
    Happy

    A lot of software could probably be 2/3s smaller *if* you could rely on 2 things

    1)The users always know what they are doing.

    2)They never make a mistake when they enter their decisions into the system.

    Anyone who writes textbooks which ignores this is definitely going to be in for a real surprise.

    1. Christian Berger

      That's a question of software design

      You can design software that's small _and_ flexible.

      Imagine you had a program calculating magnetic field strengths from a vector input of currents. If you just make it a "filter" taking text and giving text, you can just bail out on the first problem, the user can then edit the input and run it again. If the user is not satisfied he can also just edit the input and run it again.

      Now if you store the data in databases it's not as simple. You need to provide an interface to change that database. You need to make sure the output database is in a clean state when you start. This may seem trivial in this case (just delete all records), but imagine importing data into a database from another source. If you merge that data directly you will need to deal with impartial merges because of input errors.

  59. Adrian Midgley 1
    Linux

    This would be closed source proprietary code, yes?

    Another reason for the academic examples being good is that they have been peer reviewed .

    1. Destroy All Monsters Silver badge
      Holmes

      Re: This would be closed source proprietary code, yes?

      In truth, once you open up Open Source stuff, you may well have to grab the barf bag regardless.

  60. Anonymous Coward
    Flame

    Blame LEADERS, not Worker-Bees

    The elephant in this room are managers who cannot be fucked to properly listen and discuss with their often highly-skilled experts. To use an analogy, they order "bridges built out of styrofoam and plexiglass" on a regular basis. And of course they want to run Mr Porsches WW2-tanks over that bridge in a tight formation. Ten tanks in parallel with two meters distance. They ignore the expert civil engineer who says "can to this only with carbon-fiber reinforced concrete". They say "use insane amounts of plexiglass and styrofoam and now go to work !"

    Yeah, I know analogies don't paint it exactly, but I think you get the picture. For some reason, software engineers are always viewed like childs who "just have to be ordered to do something and shut up". All too often there is absolutely no proper dialogue about what is feasible, about the risks, about proper architecture.

    Then, management is totally disinterested in the Artifacts of Work. They never look into source code, they don't know whether comments exist and they only look at the first two pages of the 70 pages of documentation. They can't be fucked about proper Unit test coverage. They don't know that proper test code is a critical factor in the quality of the end-product. They don't even think about independent validation of the data spit out by the software to be developed. They don't care to demand and organise code reviews by experience experts.

    All they know are their feature-lists, some wildly optimistic project plans, some funny powerpoint slides and excel sheets with budgeting. They pride themselves of their ignorance and call this "managing complexity". They apply pressure to "get it finally done" but they don't even want to discuss how a developer is stuck.

    In short, management is not on top of things and is proud of that.

    This applies to 99% of projects. The other 1% can be called proper engineering projects and can be used without nasty surprises. Their code is nice to read. E.g. Solaris.

  61. Graeme Sutherland
    Holmes

    We're all genius programmers here

    It appears that every commentard on El Reg is in upper quartile of programming ability. Congratulations chaps, have a pat on your back and a gold star.

    The reason that other programmers' code looks worse than our own is that it's always hard to understand others works, and so we automatically mark it down. Years ago I heard a group of coders denigrating one of their former colleagues once from writing really weird C++. From what I saw of his work, he was a lot more able than they were. Unfamiliarity with his techniques meant that his skills were denigrated.

    As for self-documenting code, I'll believe it when I see it.

    The fact is that there are very, very few developers who write in a clear, concise and well-structured fashion, or bother to produce comments or documentation without being prompted. I've come across a handful in recent years as a contractor, but I'm not working in the rarefied heights of investment banking.

    We all think we're great, but in truth, most of us aren't.

    1. Anonymous Coward
      Stop

      Re: We're all genius programmers here

      What makes you think in "investment banking" they are producing good code and docs ? I bet they are fully stuffed with indecipherable VBA crapola, crazy C++ code which breaks every five minutes and is automatically restarted plus gigabytes of exception traces from their Java servers every single day.

      LSE tried to do their coding in Sri Lanka (very cheapo !!!) and they had several full-day outages. I have looked into DB/Eurex coding and they were probably much better as they got glowing reviews from RBS, despite every real brit somehow hating the Sauerkraut-eating-panzer-drivers.

    2. Christian Berger

      Re: We're all genius programmers here

      I'm not, I'm probably just average, but I have been in the bottom quartile of programming ability without knowing it many years ago. So I look back at my own code and my own abilities a decade ago.

      1. Anonymous Coward
        Stop

        Re: We're all genius programmers here

        Every "good" software engineer will know that there are quite a few much better people around. Plus, putting people on a linear scale is rather stupid.

        Some people are very good at delivering lots of functionality with mediocre quality while others are very good at creating smaller amounts of correct and efficient code. There are business and scientific/engineering software engineers and you can't properly compare these two sorts of people.

        But yeah, it is very wise to be a bit humble. Mostly a sign of an actually capable guy. Only those who know their own past mistakes can make good stuff in the future.

      2. TkH11

        Re: We're all genius programmers here

        I'm one of the sad gits that can still remember hexadecimal operation codes (OpCodes) for the 6502 8bit microprocesssor, and different OpCodes for the different addressing modes (13 there were from what I remember) for a given instruction. Now is that sad?

        When days we didn't have an assembler, used to hand write the hex values in the memory using a monitor program.

        What fun (and bloody hard work) those days were! But we were young, and it was a learning experience and it didn't seem like hard work.

    3. 0x407ab506

      Re: We're all genius programmers here

      Keep It Simple Stupid. I have had to chuck out far to much clever code that confused but didn't work. Things like singletons that failed to initialise or unload because the OS wasn't ready, and that is just the beginning.

  62. Seanmon

    So true

    Allow me to claim some smug points here by saying I've been complimented on the readability and maintainability of my code by a guy who had to inherit it once. I'll relinquish said smug points by admitting that I'm not actually a very clever coder. My solutions tend to be step 1, step 2... step n. Not very efficient, certainly, but they mostly work.

    Once had to analyse a thing that used a database integer to control some behavior in the user interface. Turned out that the code was converting the integer to an 8-bit binary and every bit was controlling some random switch in the UI. I mean, just fucking why?

    Remember the story of Mel.

    1. John Smith 19 Gold badge
      Unhappy

      Re: So true

      "Once had to analyse a thing that used a database integer to control some behavior in the user interface. Turned out that the code was converting the integer to an 8-bit binary and every bit was controlling some random switch in the UI. I mean, just fucking why?"

      Because he was being "clever."

      When you have to pack 100s of functions in a 64k address space (I'm specifically thinking of the original Macintosh toolbox ROM here). When scraping a few milliseconds will let you protect another whole city (The Safeguard ABM system, all coded in assembler) or better compression will allow you to pack another whole level into a game (no idea where this has been done but I think it's safe to say it has).

      These are the times to be "clever" But before you feel the urge read Steve McConnell's account of how he got real time encryption using the DES (2400bps output) running on an original PC.

      Then ask yourself how much fun it will be reading your code again in 6 months time when someone asks for a change.

      "Cleverness" (in most instances) is vastly overrated IMHO, both by the clever (who do it) and the their admirers (who funnily enough never get close enough to have to fix it afterward).

      1. TkH11

        Re: So true

        'Cleverness' comes about through the developer being immature! They're trying to show off how clever they are, when in reality they're not thinking about how the code is going to be maintained.

        I have covered extensively development and production systems with 15 years development experience and several years of running production systems and what I see is a number of developers that do not understand - and even one I would so go as far as to say refuses to understand - production systems and the configuration controls around it.

        The developers like to tinker, they like to jump on to the prod systems change things without any kind of change control without even notifying the support organisation they're logging on and doing things.

        Now, put that in to a multinational context with testers in India jumping on to production systems here in the UK and the problem is significant.

  63. amanfromarse

    There are so many opinions here on why SD is crap and how to fix it.

    IMO, the #1 criteria is (much as I dislike him) Joel Spolsky's #1 rule: employ smart developers.

    Unfortunately, in 30 years, I've only contracted at one company where they got it right and despite it being 200 miles from my home, I would have gone permanent. Then they outsourced. The company owner was a dick and if they aren't out of business now, they will be soon. He didn't know what he'd got.

    The dev manager was an excellent judge of character and if he thought that you wouldn't fit in with the team, you were rejected. No silly tests because any good techie can suss out a good dev after 5 minutes. But you had to leave your ego at the door. It's the only place I've worked that they had code reviews as part of their process. And not to enforce routine/method/function headers or some such bollocks that source control could monitor, but they trusted their devs to analyse the code and say when comments were required, etc.

    Good devs group together. They love bouncing off each other. They do it in their own time anyway and hate being stuck with Morts and 9 to 5ers.

    Software is a people problem. The 90% on here who think that their proposed solution to their own personal experience is an answer to universal problems are naive at best..

    1. Anonymous Coward
      Flame

      Yeah

      A "people problem" which starts with the "leader people". If they fuck it up, then even the very best developers will produce sub-optimal stuff.

      If the PHB pressures you for new features all the time and doesn't care about proper comments, documentation, unit tests, validation - it will simply not exist on the long run. Your suggestion that this should be fixed using (probably unpaid) overtime is simply hilarious. If a company can't get their shit done in 40 hours per week per employee (on average) they are making a drastic error. I don't exist as a slave, but as a human who works to live. I have a family, including a young kid. I would rather let code/docs rot than take away time from my family. Sometimes I have a fit of "let's fix this tonight", but the frequency has dramatically dropped since I have a real family. And that is exactly how it should be.

      1. TkH11

        Re: Yeah

        Yep, definitely the leadership that is nearly always a big problem. Where I work they don't have project managers - in the traditional sense of the word - they have 'technical project managers' so you'd think from that they'd be technically skilled wouldn't you? Afraid not. One of the clowns - has no less than three degrees, all technically related: engineering and finally a masters in telecommunications, yet doesn't know the first thing about technology. Everything he touches he f**ks up.

        We're a multinational so we try to run teams which are fragmented over the UK and fragmented across the entire world..yet we can't even have a decent telephone conference call because we place a single telephone with speaker phone capability in to a conference room which is ten metres long and then wonder why we can't hear the people on the phone. We can't even get development to work successfully in a single room because a) lack of process and b) poor technical leadership, but the powers-that-be want to outsource to cheaper countries like India.

        One of the development team was headed up by a team leader that didn't have any software development experience! As if that was ever gonna work.

        I have never seen such a dysfunctional development organisation, version numbers on code? Nah, we don't want to do that so we don't it.

  64. t_lark
    Happy

    Good Example of Code

    Thought I would buck the trend and point out some beautiful code I discovered the other day: LinuxCNC. A modular framework that allows you to swap out software modules for hardware modules (!). Config the interconnects in XML. It has some complicated modules in C++ (e.g. decent Kalman filtering), it has some deceptively simple module (add two inputs and other basic arithmetic). Now here is the kicker: its got its own realtime scheduler, so you can build complex modules by joining up simple modules if the task of building (a realtime version) what you want is too much to bite off. Furthermore, it has its own user space, with python bindings, so that UI type work can be done without the real-time hassles and in an easy language. My god! It is such an awesome design! The only real neg is that its a bitch to compile, but I felt uplifted by going through its source

  65. John Smith 19 Gold badge
    Unhappy

    Code writing skills good. Code *reading* skills better.

    Those "Real Programmer" types can write impressive code (see "The Story of Mell")

    Now let's see them process a change request.

    Seriously it's an amazing skill to recall all the opcodes in a processor's instruction set.

    As is being able to get the best performance out of a steam locomotive.

    But if the instruction set is already obsolete so what?

    There is a reason no one uses the whitespace language for commercial applications. Just as there is a reason most people who have to program in "M" want to move to something else.

  66. deank

    It makes no sense to judge readability of a language (Haskell) on a deliberately obfuscated code from Uncyclopedia . Especially, when the example is so clean and easy to write. This creates a list of power of twos from 1 to 100.

    map (^ 2) [1..100]

    Or as a list comprehension:

    [ 2 ^ x | x <- [0..100] ]

    And the code that is equal to the mess author posted, which returns an infinite list of power of twos, is:

    map (^ 2) [1..]

  67. Herby

    One just needs to judge code correctly

    You need to look at the whole thing. Comments, AND code. You can write terrible code, and you can write terrible comments (i++; /* Increment i */). If you are a 'supervisor' you need to weed out the bad, and fertilize the good (no not that way!). If you are 'management' you must allow for and budget money and time to get a proper result. It is a fools task if you take shortcuts.

    The saying goes, never enough time to do right, but lots of time to do over. This must be stopped, and the people in the trenches given proper resources to generate code that WILL stand the test of time.

    Experience comes from wisdom, and wisdom comes from experience. Coding in 6 decades does that to you (some were only a couple of years), yes 6 decades, back to the 60's.

    1. TkH11

      Re: One just needs to judge code correctly

      There is a definitely a problem with the project managers that don't have the balls to stand-up to the customer and tell them "We can't do it in that timescale", but they don't. They commit to a timescale which they know they can't achieve, and guess what they can't achieve it, so in order to hit the deadline, they cut the testing, they cut the documentation reviews - you wouldn't believe the standard of documentation that goes out to our customer (and internally too), they don't have time to do things 'properly'. They deliver crap code, throw it over the fence to the support organisation and then they end up with defects being present.

      The PM's just refuse to accept the adage that the later in the development cycle the problem is fixed the more it costs.

      1. John Smith 19 Gold badge
        Unhappy

        Re: One just needs to judge code correctly

        " They commit to a timescale which they know they can't achieve, and guess what they can't achieve it,"

        In Code Complete Steve McConnell talked about "programs," "product programs" and "product systems."

        "Products" in this context imply "used by someone other than the developers" so error handling on user input, help text and some kind of user training are needed.

        His estimate was product programs are 3x the cost of programs and product systems 3x that of a product program.

        So if you cost and schedule a "product program" like an in house (in dept?) program you're guaranteed to be 3x out from the off.

        "The PM's just refuse to accept the adage that the later in the development cycle the problem is fixed the more it costs."

        The parallels between software development and US mfg industry are just fascinating. Sadly it looks like there is no possibility of the Japanese giving the IT industry the sort of wake up call mfg got in the 80's to start looking at this "quality" idea.

  68. A J Stiles

    How I do it

    I like to think I'm a good programmer, but I expect it's the same as driving: More than half of all drivers think they are better than average, which is mathematically impossible. So maybe I'm not really all that good. Anyway ..... This is my Modus Operandi, for what it's worth.

    Obviously, the first step is to break the problem down into a series of simpler ones. So I begin by writing comments of what I want each of my main sections to be. That's right: the first thing I save is just a bunch of comments! Then I fill in the actual code to do what the comments said, right between the comments, moving bits that deserve to be made into functions out of the way.

    This way, it's pretty much self-documenting. I never have to go back and try to understand how a particular chunk of code works; because I already wrote that down in the first place, as soon as I figured out how I wanted it to happen. It has also given me ideas for Meaningful Variable and Function Names (which, in and of themselves, limit the need for additional comments). It might well suggest creating a new object type. The basic point is as soon as the idea is fresh in my mind, it gets turned into natural language comments, and then into the idiom of the programming language. It also means I'm coding not straight from abstract thoughts, but from words.

    In Perl, which is my language of choice, methods may be "asking" -- returning a value relating to the object -- or "telling" -- setting a property, or injecting something into the object, and not naturally having anything obvious to return. I make my "telling" methods return the object itself; then I can daisy-chain them, avoiding repetition:

    $cake ->ingredient("flour", 200, "g") ->ingredient("sugar", 200, "g") ->ingredient("butter", 200, "g") ->ingredient("bicarbonate of soda", 20, "ml") ->ingredient("eggs", 4) -> ingredient("water", 50, "ml") ->bake(5, 15 * 60);

    Notice how that neat "15 * 60" (which, since it is being used as a literal, will be evaluated once, at compile-time) makes it obvious to the reader that the second argument to ->bake() is a time in seconds, in a way that "900" might not, and does it without an explicit comment.

    All this, of course, is Laziness -- the fist great virtue of a programmer. Although it seems an effort to write down what you are thinking as you are thinking it, it is less effort than thinking of it all again later just so you can write it down.

    1. John Smith 19 Gold badge
      Thumb Up

      Re: How I do it

      "So I begin by writing comments of what I want each of my main sections to be. That's right: the first thing I save is just a bunch of comments! Then I fill in the actual code to do what the comments said, right between the comments, moving bits that deserve to be made into functions out of the way."

      It's called "stepwise refinement" if done right and "detailing" if done wrong.

      It's the approach used by what was IBM Federal Systems to write the space Shuttle software so it never failed in flight. From what I've hear of perl it's essential to avoiding producing an unmaintainable mess.

      Thumbs up for applying good SE to a language not known for it. Your copy of "Structured Programming" (Linger Mills and Witt) is in the post.

  69. 404
    Pint

    LOL

    My son is seeing this first-hand as he works on his business major w/compsci minor since he works with me and my clients in his 'off' time.

    He gets bewildered at times with comments such as "my professor says it shouldn't be like this" and I say 'welcome to the real world, son".

    ;)

  70. Anonymous Coward
    Anonymous Coward

    Part of the problem is not having time to learn the new features or extended features of a language. So you'll find many piles of Java for instance still using Java 1.4 compatibility (although generics are a pain in a ass though).

    There are too many new languages appearing too, each with their own "agenda" and style.

    Functional programming is the latest trend and that's pretty alien to anyone who started on procedural and moved onto OO. If you started with LISP you'd be okay of course.

    So the lesson is to choose your tool wisely and master it, it's no use being a master of none unless you're a contractor or move jobs a lot.

    1. Destroy All Monsters Silver badge
      Devil

      In truth, if functional programming is "alien" to a developer, then there is major problem on how he thinks about his code in the first place, and there is an even bigger problem with the school he attended.

      Get on the level of LISP, it's just half a century late.

  71. Destroy All Monsters Silver badge
    Childcatcher

    User Story #3960(b)-§77

    Seriously, could El Reg provide an option for "print article with comments formatted nicely" possibly with tickboxable comments, too.

  72. 2Fat2Bald

    In the Real World.

    To be honest, I think educators in code aim for the best possible standard, and hope to actually get something that isn't too bad.

    My big thing is to put comments in *plain language* - explaining not just what the code does (which is usually fairly easy to work out) but why it's doing it, why it's doing it that way, and helpful information.

    GOOD:

    Copy Date to DT variable - the legacy system will only accept 2 character field tags, but "Date" is used a lot in the system so cannot be renamed. DT is only intended for use in this transation. J Bloggs 01/02/2012

    BAD:

    Copy Date > DT

  73. Chika
    Meh

    Potato

    I got out of programming years ago because I recognised the things in this article. I knew I wasn't a brilliant programmer but I knew enough to make various modules that could do most of what was needed and then write simple code using these library modules so as to give myself some breathing space when my various bosses wanted it NOW.

    I had to do this because the people behind the original code that I was working on had such a weird idea of what makes a program that in many cases it was easier just to pull apart what it was supposed to do then write it all over again, especially as this was code that needed amending due to the millennium bug that infected every stinking line of that mess of a system! I managed it, and I'm proud of what I did, but I really wish I never had to do it!

    Trouble was that I increasingly felt like I was fighting the system, both metaphorically and physically, just to get the work done. It took redundancy to actually make me realise what a wreck it was making of me! I went back as a contractor a couple of months later and did some of my best coding, if I do say so myself. These days, I rarely ever touch code though it's a hard habit to break, especially when you see some of the crud out there.

  74. QA
    Paris Hilton

    without knowing what ctrl-C and ctrl-V do

    Me me! I do....

    ctrl-C is for when your new piece of code has a loop that doesn't terminate

    ctrl-V is for when you need to strip out DOS line endings because you're using a proper O/S:

    :1,$s/^V^M//

  75. jmh300
    Facepalm

    Quality depends on the consequences of failure

    I believe that the proliferation of garbage software can be traced back to one thing: Lack of consequences.

    There has been a lot of talk about enlightening management to the significant long-term savings to be had by employing up-front design and analysis steps in a project--but in many cases management doesn't seem to want to listen, especially in the smaller organisations that are more interested in the near-term revenue. End-users blithely sign away their rights by agreeing to a deviously written EULA that absolves the vendor of liability but still maintains their right of ownership in the software product, so there are few immediate consequences when the software product fails.

    What to do about it? I don't really know. I've often thought that it would be a Good Idea to sue software vendors that sell buggy products which end up tossing hours (or days, or weeks, or months) of work on the floor when they crash, or fire programmers that knowingly write garbage. Managers that allow or encourage bad practices shouldn't be in management positions. But, seeing as how we don't live in an ideal world, I don't see any of these things happening any time soon.

    Until there are consequences for creating crap software there will be crap software. If you want to work in an environment where quality is a top priority, process and procedure are not only encouraged, but required, and where the end product has earned a confidence level that warrants entrusting billions of dollars or hundreds of lives to it, then go get a job in aerospace or medical equipment manufacturing. For the rest of the software industry, the consequences for failure aren't anywhere near as severe, so the concern for quality and reliability just isn't there.

    1. John Smith 19 Gold badge
      Thumb Up

      Re: Quality depends on the consequences of failure

      "I believe that the proliferation of garbage software can be traced back to one thing: Lack of consequences."

      That seems likely.

      Because the software industry is dominated by US companies it has never had the experience (as mfg like cars and domestic electronics had) of being hammered by the Japanese and suddenly discovering that quality actually mattered and that the Japanese had acquired most of their ideas from the US management adviser W. Edwards Demming.

  76. ichibrosan

    Poor premise, unless you have read all the code in the world

    There are all sorts of programmers, and then there are software engineers. Those who care about abstract ideas like "maintainability", Myself, I write enough code to get the job done, and then I remove as much as I can and still have it be, reliable, efficient, and maintainable. That means commented code, documentation. Pride in ones work. I don't believe I am alone in this. And I want the respect of my peers who will see my code. I have professional standards about code I write and release.

    You do us all a great dis-service propagating a myth about "most code". Employers want more these days. Design patterns, best practices. Then there is "errors and omissions" insurance. We have to care about the code we write, or it comes back to get us.

    1. TkH11

      Re: Poor premise, unless you have read all the code in the world

      Interesting concept: write code and then remove it. I don't think I have ever done anything like that in 15 years of coding, I might remove some comments but even that's rare. I just do it right! Good design, keeping it nice and simple, using top down design techniques (and a mixture of bottom up where appropriate) .

  77. Jedai
    WTF?

    Uninteresting article

    So there is less than perfect code around, even terrible code ? Color me surprised ! Really this blows my mind, clearly this must be a revelation to anyone involved in computer science and/or engineering...

    I love how this article shows great insight and vast experience (mainly restricted to programming in the finance world, home to the best and the worst and not a haven of the "best" that programmers have to offer as the author seems to think) and align platitude like C++ can make for horrible code and you can write perfectly unreadable code whether by being too bad (incompetent) or by being too "good" which the author seems to conflate with being too clever and impressed with his own ego to work in a team. And the conclusions are priceless with a golf example of APL to show how incomprehensible it can be (may be understandable given the fundamental nature of the beast, though APL still has its place in some circumstances) then an artificially golfed Haskell sample (there's even a comment in the middle of the line to make it even more incomprehensible), a language the author admit to ignore everything of... Wow, that's good reporting. Just FYI, this sample correspond to the ungolfed :

    iterate (2*) 1

    or

    map (2^) [0..]

    Both of which are very clear and at least as readable as alternatives in other languages. There's no language that can't be made to look bad by showing a golf sample (see C or C++ examples for nightmares).

    And of course the premise of the article itself doesn't make sense... There's no bad code in textbooks ? Apart from the innumerable cases of errors, sloppy coding and incomplete solutions that you'll find in a lot of textbooks, you can also find many textbooks that present voluntarily bad code to expose their preferred method to avoid or correct those problems : that's pedagogy for you, learning from mistakes.

    In conclusion, this article is bland, repetitive, wrong-headed and plainly mistaken on so many points that it's best forgotten soonest !

  78. William Roberts

    A case in point

    I remember well a day over 17 years ago when I was handed some code and a database that an inexperienced programmer had been working on for months, but suddenly gave notice. I was told it was mission critical and needed to be finished ASAP. Well, I managed to make it work, but it was some of the most terrible software I had ever seen.

    I suggested it should be completly rewritten from scratch, including the database, but I was assured that it was "temporary" and would be thrown out as soon as a suitable COTS package was found. Eventually maintenace was turned over to a series of other programmers, but just 2 years ago, the database was migrated from Sybase to Oracle and it's still in use.

    A package is already installed and in use that has features to support the requirement, but since that new package is "corporate" and the old application is "local", it will never get replaced.

    Is there any need to mention that management most emphatically does not want to pay for a testing suite?

  79. TkH11

    process

    Having worked in various industries including : telecommunications, investment banking, defence + others the best technically capable people I have come across without any doubt is in the defence sector.

    Many programmers are mediocre, and a way to deal with this is by way of process. Having good processes in place, design reviews, peer reviews, configuration management procedures and all the other good stuff and important,crucially having a development team leadership which actually has experienced served in development and has the balls to make people follow the process.

  80. scrubber
    IT Angle

    Amateur

    "or how elegant its user interface is"

    Business code has no user interface...

    Everything else is marketing.

  81. RyokuMas Silver badge
    Megaphone

    "The most common reason for the existence of bad software is bad programmers" - however, this is closely contested by managers wanting/promising too much without the resource to grant it. Consequently, there's seldom time to do anything other than hack out a patch...

  82. Geoffrey Swenson

    Code that needs to be commented very much is badly written code.

    I've just been to two different places in four months where the bad code made things difficult. In one place, there were several layers of back end, all of which required pages of test code to be written just to handle all of the conversions from one backend object to the next parallel object. It apparently didn't occur to the devs to have shared enums and type classes across these boundaries. The system was so error prone and hostile that they had resorted to "extreme" programming -- having two people write the code at the same monitor.

    This turns the usual fun of writing code into sleep inducing drudgery for at least one member of the pair.

    The other corporate nightmare has endless meetings trying to define, in advance, all of the elements of the software we were writing under an extreme time pressure. I got tired of the bickering and produced a nice UI in a few days of work.

  83. Willy Wonka
    WTF?

    Once again The Register discovers: The Obvious !

    What is amazing is: that the author of this article actually thinks this article contains "news."

    Having been active in the world of very popular consumer oriented (high-end) software (graphic design) for some years, I can only snort reading this article.

    In that consumer domain there is often a "feature race" going on in which prime resources are allocated to implementing the "next great thing," so that competitors will be "left behind." Forget cleaning up the code base, forget commenting, forget fixing bugs, forget anything, but: "future glory."

    The stock-holders want their pound-of-flesh, the executives want a profitable balance sheet for the quarter, the managers want to "look sharp," and demand meeting unreasonable shipping deadlines, and the programmers: well, we are the lowest animals on the totem pole.

    And, in that domain, skilled programmers spend a lot of time doing what I call "dinosaur dentistry:" hacking kludges so the latest version of the application can inter-operate with new/ever-changing platform API's and features, take advantage of new hardware possibilities (GPU off-loading of certain computation for graphics, for example).

    Of course you have, in any technical enterprise, opportunity for programmers to create their own "lifetime employment guarantee" by creating obtuse, and undocumented code, that no one else can understand, let alone maintain. "Pathological" cases like that, imho, should be blamed on management.

    It has never been a pretty, "algorithmic," world out there, and it never will be: why did the author of this article take so long to "wake up," and, then: decide they had discovered a "brave new world" ?

  84. Mike Allum
    Happy

    She's right, he's right, everybody's right.

    There are many good observations here and a fair bit of very justified axe grinding too...

    The problem always comes back to one of intangibility. A lack of definitive and simple metrics forces us to abstraction which is something that makes many managers uncomfortable. Lack of visibility of architecture and the perceived mutability of software leads to expectations that 'just a software change' will make up for incorrect or quirky hardware and interfaces. Lack of requirement for quality standards means that rubbish code gets shipped. Lack of understanding of maintenance issues means that documentation is not done.

    The solution? I don't think we have a magic bullet at the moment but there are a few things that might help us for now. Communication is the foremost of those and something that I think will help tremendously is the concept of "technical debt" (mentioned earlier) which puts our technobabble into a soundbite of the type beloved by PHBs.

  85. crediblywitless

    There are two things a man must do, before his life is done:

    Write two lines in APL, and make the buggers run.

  86. Anonymous Coward
    Anonymous Coward

    First steam engines were badly operated and maintained

    Programmers suck because there is a shortage of them. IT is hiring faster than unis can produce. I'm sure that it was a similar problem when the steam era boomed. By the way, what happened to journalistic integrity wrt citing sources? This article is just assertions left and right.

    1. John Smith 19 Gold badge
      Unhappy

      Re: First steam engines were badly operated and maintained

      and after enough of them had blown up people started setting minimum standards for hardware and design rules to stop them blowing up.

      "I'm sure that it was a similar problem when the steam era boomed."

      Except the supply of competent programmers shows little sign of improving.

      It's not that there's a shortage of mistakes.

      It's that there seems to be a shortage of people who learn from them.

  87. Nanners

    If, and, but

    Sounds like Microsoft code to me.

  88. Jonesy
    Coat

    JFMIW

    "Just Fucking Make It Work" is a phrase I've heard more than once when trying to do a "proper" job, either that or 14 developers quit in protest at the piss poor design some BA thought was a good idea.

    The way I see it, this piece highlights a massive failing in our eduction system. If students aren't being made aware of the reality....... Just Know, Shit gets real, REAL quick! ,

    @AC I see what you've done there, citing SOURCES , make ASSERTions,

    I'll get me coat!

  89. preppy
    Happy

    ...and here's what you get when people TRY to write bad code.....

    Obfuscated C Competition here....

    http://www.ioccc.org/years.html#2012

  90. Niall Wallace 1
    Thumb Up

    Now if only modern development processes would accept this.

  91. Frank Thynne

    Software Design is an *Engineering* process.

    Some years ago I worked for a relatively small firm that made hardware and software products that ran rings round its main competitor (IBM) in terms of reliability, usability and customer satisfaction - oh, and price too.

    It was founded by hardware engineers who knew about Configuration Management (Change Control etc) and Quality Assurance. Software had the same standards and procedures as hardware. Since then, the only people I've met who see the merits of those things are Military Engineers. There was a periodical of the day called Software Engineering, and there are now many, but is not clear how many of them focus on Quality issues.

    The complexity of modern software and the number of lines of code in it make it hard to believe that the same standards of Quality Assurance are followed. any more. The result is frequent changes to fix software errors (and often to fix the fixes) and a rate of change and lack of reliability that would not be tolerated in any other branch of Engineering. Quality Assurance managers do not have the power to say "this product is not yet fit for release" and, until they do, we are stuck with software that only half works.

  92. Paul
    Facepalm

    managers hear what they want to hear

    Some years ago I was working with two others on a monitoring system for an ISP. It was a fairly major endeavour intended to

    One of my colleages developed the subsystems which collected netflow data, crunched it down and put into a database for analysis and graphing for well over a year, and he went off sick and it looked like he wasn't coming back.

    Our manager asked me how long it would take to pick up his work and I said I didn't know, I had specific APIs and data dictionaries but no knowledge of his code at all, so we agreed that I would look into his code and report back in a week's time how long it would take. The next week's meeting didn't take place, so a fortnight later we sat down to review it.

    The Manager asked how well I'd picked up my colleague's work, and I said I hadn't, that I'd only agreed to work out how long it would take to get up to speed with his work. Manager tried to rewrite history but I stood firm! I was finally asked how long before I could start on the bug fixes and new features, and when I said about two months, he was aghast! I had to remind him that this was a complex system written by people who'd never worked on this kind of thing having spent months prototyping and experimenting.

    Fortunately by the time I was expected to do something useful with my colleague's code he came back to work. I knew his code was a terrible mess so was very relieved.

    Nearly six months later there was a big purge and we were "let go" despite being the only people who really understood how it all hung together. I heard that the people redeployed onto our project quickly turned it into a bug-ridden unstable mess in trying to add all the version 2 features and never got it to work properly.

  93. art_2

    Actually, all that is needed is a little accountability!

    In a typical semiconductor firm, test engineers code device tests to be performed on automatic systems 24/7, by non-engineer production operators at various worldwide locations. In our firm each test project can be subject to a random audit after release to production. The auditor inspects the code down to specific commands, and expects that the code is clear enough and well-commented enough for a disinterested engineer to understand and master it in reasonable time. Any exceptions to this rule are flagged in a written report to the test developer(s) and management. These exceptions are reviewed and can be challenged by the developer(s), but when found valid they may be noted on the next performance review. The experiences described in the article are typical for companies that don't have a clear accountability process for developers. In our case, we like to be profitable, and don't welcome test engineers who put ego above production-worthy project outcomes. (This is industry, not creative programming class.)

  94. Stretch

    comments are just smelly crap that will not be maintained. I lose count of the number of times I've found comments that are out of date or just plain wrong. Plus they are localised, a useful comment in one locale is nonsense in another even in the same language.

    Write succint, well-encapsulated code that makes good use of interfaces. Oh and some of you are talking about tests? Don't even get me started on writing tests. Every unit test failure I have ever looked into has resulted in me having to CHANGE THE TEST.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2022