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.

Page:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

  7. 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.

  8. 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..]

  9. 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.

  10. 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.

  11. 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".

    ;)

  12. 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.

  13. 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.

  14. 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

  15. 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.

  16. 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//

  17. 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.

  18. 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) .

  19. 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 !

  20. 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?

  21. 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.

  22. scrubber
    IT Angle

    Amateur

    "or how elegant its user interface is"

    Business code has no user interface...

    Everything else is marketing.

  23. RyokuMas
    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...

  24. 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.

  25. 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" ?

  26. 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.

  27. crediblywitless

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

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

  28. 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.

  29. Nanners

    If, and, but

    Sounds like Microsoft code to me.

  30. 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!

  31. 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

  32. Niall Wallace 1
    Thumb Up

    Now if only modern development processes would accept this.

  33. 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.

Page:

This topic is closed for new posts.

Other stories you might like