Please create an account to participate in the Slashdot moderation system


Forgot your password?

The Ways Programming Is Hard 278

An anonymous reader writes "Those of us who spend our days sitting in front of a screen trying to make computers do our bidding know how difficult programming can be. But from an outside perspective, there's not much to indicate difficulty. Most of us have heard somebody compare our job to digging ditches, or some other manual labor, meant to contrast easy (sitting around and typing) versus hard (muscle-wearying work). Now, Peter Welch has written an amusing essay to help combat that point of view, titled Programming Sucks. He compares bridge building to a big software project. Here's a small part of it:

'You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he's involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don't worry, says Mary, Fred's going to handle the walkways. What walkways? Well Fred made a good case for walkways and they're going to add to the bridge's appeal. Of course, they'll have to be built without railings, because there's a strict no railings rule enforced by Phil, who's not an engineer. ... Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn't.' Welch goes on to gripe about all the ways in which programming is almost awesome, but ends up being annoying."
This discussion has been archived. No new comments can be posted.

The Ways Programming Is Hard

Comments Filter:
  • he's right it does suck

    • by TheLink ( 130905 ) on Wednesday April 30, 2014 @03:02AM (#46875981) Journal
      He's wrong though.

      Bridge building is more like compiling.
      Bridge designing is more like programming/program designing.

      And there's the big difference.

      Civil Engineering:
      Design Phase costs about 10% of Build Phase
      Build Phase involves tons of construction workers and heavy machinery.
      The blueprints and plastic models are way cheaper to make than the Real Thing.
      Management often doesn't mind spending a bit extra to get the design better, because the budget only allows for one big Build.

      Software Engineering:
      Design Phase costs more than 1000 times the Build Phase.
      Build Phase involves the programmer typing "make all" and going to read Slashdot or fetch a coffee.
      The plastic models cost as much to make as the Real Thing.

      Management often sells the blueprints/plastic models as v1.0 because they compile and "kinda run" and the budget only allows for one big Design... ... Aaaand the customers often buy it :).

      It should be no surprise then that the plastic models regularly fail.
      • by gl4ss ( 559668 )

        well to build a bridge you need awful lot of guys who work with wood since that's what you usually use to hold the concrete in place while it sets..

      • Re: (Score:3, Insightful)

        by smallfries ( 601545 )

        Build Phase involves the programmer typing "make all" and going to read Slashdot or fetch a coffee.

        How dare you perpetuate this insulting and offensive view of programming. All real developers know that it involves sword-fighting on wheelie chairs.

      • It's not only the Software people that suffer. The guy who built the Golden Gate Bridge got sick over it and was depressed for the rest of his life and died early. I probably would've shot myself half way into the project.

      • Not a bridge designer myself but I suspect bridge building is well defined for how one is designed. It seems that so long as you define span and weight requirements (plus whatever other details I don't know about) you will have a pretty successful bridge.

        Most software requests seem to be more like "I want to drive across the Aleutian islands, make it happen".
      • by dbIII ( 701233 )
        It's so nice to have computer programmers tell us what engineering is. I understand now why an entry level coder without a degree and not much high school math considers themselves an engineer - they don't seem to think much about the profession at all.
        Here is a clue guys - there is feedback in each process. Scheduling tasks is also part of engineering. Solving problems is also part of engineering. Getting that last pour done at 2am as the two halves of the bridge expand and contract enough that they ar
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      >Bridge Analogy Time
      And when you are supplied with help, most of them have never used construction tools but still claim to have years of experience building bridges. You assign them a section to tighten bolts and after a few days check and see that nothing is done because they're all crowded around an incorrectly sized bolt and trying to make it fit. After showing them the correct bolt size, they swing the wrench around wildly trying to turn the bolt by hammering the edge. When you ask what they are doi

    • The difference between building a bridge and building software is that an engineering company will build a model of the bridge, the client will look at it (and possibly several other models), say "Yes, that's what they want. How long?" The engineering company will say "2 years" and the client will probably say "OK".

      In software, you build a model showing the menus, dialogs and screens, present it to the client, who then says "That's right, but it needs just this one more thing." We can have it by next Thursd

  • by FireballX301 ( 766274 ) on Wednesday April 30, 2014 @02:24AM (#46875849) Journal
    Only complete idiots/tools think this way about any profession. Brick laying looks easy, but I wouldn't trust someone who's never picked up a trowel in their life before to put up a brick wall. Anyone 'outside the profession' should only be concerned that the code works, is maintainable, and is to spec, along with passing a security audit.
    • Re: (Score:2, Interesting)

      by KingOfBLASH ( 620432 )

      Well that's not completely true. I'm quite sure an intelligent person could learn how to be a bricklayer if they really wanted to. I'm not quite as sure that an uneducated brick layer could learn to code if they really wanted to.

      Although that's not to say a highly intelligent individual might not decide to become a bricklayer instead of a programmer [].

      Case in point: how many people who are not in construction go to Home Depot on the weekend as a sort of entertainment. It's interesting to figure out how to

      • by x0ra ( 1249540 )
        The week-end trip at Home Depot is more about fixing the house than "entertainment". Let's face it, most jobs are about trying to keep the damn thing running for one more day.
        • Disagree. How much do you make an hour? Logically if you make more than a builder, it is better to work overtime and pay the builder.

          My father was like that. He could spend his entire weekend fixing something that would take a "pro" an hour or two. He made more in an hour or two than a pro made, so logically it made no sense to give up his weekend. But there was a significant entertainment value to him to going to home depot and figuring out how to fix it.

          Of course, if you make close to what a builder

          • by sycodon ( 149926 )

            There is no need for a person with a normal yard to buy one of those things

            I love it when someone decides that they have the prerogative to decide what someone else needs or doesn't need.

      • How many people can you say that about programming?

        About 30-35 years ago I remember how people would be playing around in Basic on the weekend for entertainment. It really isn't that far-fetched, and messing around with the tape deck and volume control just to let things load made people realize that programming is a lot like Building in the Real World, where having a PZ screwdriver instead of the PH you really need sort-of-works but makes your life a hell of a lot harder.
        I don't know what it's really like today, I've been doing it professionally for too

      • I'm quite sure an intelligent person could learn how to be a bricklayer if they really wanted to.

        All they need is a Bricky [].

        There's something about that one that I could watch for hours.

        Then there's this guy [].

      • by Opportunist ( 166417 ) on Wednesday April 30, 2014 @03:51AM (#46876145)

        As someone who has spent quite a lot of time in "menial" jobs during my university years to get enough money together to get by, I can inform you that most jobs where you'd say "an idiot can do that" from watching are harder than they look. Mostly because you're usually watching people who have been doing it for years and practice does make perfect.

        It will probably take longer to teach someone programming "from scratch" than it would to make him a decent bricklayer, but I wouldn't simply assume that it's easy because it looks that way.

        • Well it is a craft and requires practice. And programming requires practice as well. But it also requires a higher level of intelligence and problem solving. You can be an idiot and so long as you know how to put in bricks, if I say "Build wall here" you could do what you need. I've seen plenty of "programmers" who just lacked any sort of problem solving skills and ran into a wall (pun intended)

          • I'm in IT security. This involves amongst other things code reviews. In other words, I get to see a lot of code.

            And judging from quite a bit of code I've had to see lately, I can only assume that the level of intelligence and problem solving skill required to enter into programming has been lowered by some kind of leg-up, no-dud-left-behind program...

        • I wouldn't simply assume that it's easy because it looks that way.

          Agree!....I despair of ever managing to lay a good caulk bead.

    • by ubersoldat2k7 ( 1557119 ) on Wednesday April 30, 2014 @03:31AM (#46876073)

      Actually, your simile with brick laying is what I found fits better with how software projects work. I mean, you build a bridge and be gone. Most software projects start as "we want to build a wall", but then they switch to "we want a wall with a door and greco-roman finishes", and it keeps growing and growing until you have the Pisa tower with a kitchen in the roof top, all made of small bricks and lot of glue.

      • When the client starts as "we want to build a wall", your first step is to reformulate it as "we want to go from side A to side B of the river". This way, you can notice that the right solution is to buy a ferry boat.

    • by khchung ( 462899 )

      Only complete idiots/tools think this way about any profession.

      Agree, but it seems like the whole world is filled with idiots...

    • I'm 10yrs from retirement I dropped our of HS in 1976 and have spent the last 26 as a degree qualified developer. Before my degree I spent 15yrs as a labourer, I did a stint as a brickies labourer, spent a year in a remote Aussie sawmill, farm hand, deck hand, concrete formwork, and many more "strong back, weak head" style jobs, I married young and had a wife a two young kids, I'd willing have done pretty much anything people were willing to pay me to do....

      - The most physically demanding was deck hand o
    • 1. "code works": Easy to say, hard to check. It might work today in some circumstances but fail tomorrow in other circumstances.
      2. "is maintainable": That's a subjective criteria which is impossible to enforce.
      3. "is to spec": Again, easy to check for common pathways, but hard to catch all the nuances (for the same reason that no one has 100% code coverage in their unit tests).
      4. "passing a security audit": This helps, but as well all know by now it does not guarantee that the code is secure. Code usually d

  • by zephvark ( 1812804 ) on Wednesday April 30, 2014 @02:29AM (#46875863)
    Wimp working for an excessively-large company with rules that might allow "casual Fridays" with strict dress codes. He's whining about corporate culture, not programming. The "Neo" problem that first gave you the hint that he wasn't an actual hacker, just some script kiddy in a minimum-wage cubicle farm.
    • problem of "other peoples' code" is an actual problem?

      Because if so, I think you may be the script kiddy in a minimum-wage cubicle farm.

    • The "minimum-wage cubicle farm" culture is the problem. Reading his story, I can pretty much think of someone in my career who filled the shoes of each person mentioned. You know it's funny, if we want to engineer a bridge, or a skyscraper, there is a consistent order and process to putting it together and documenting it. If we want to do that with programming, people just do whatever they want, put some duct tape here and there, and hope it doesn't fall apart. Of course part of that is management gener

      • Re:wimp (Score:5, Insightful)

        by Cenan ( 1892902 ) on Wednesday April 30, 2014 @03:34AM (#46876097)

        Software Development is still a young field. Someone who wants a bridge built can look back in history and see all the horrible consequences of not shutting up and listening to the people who know better than them. There are strict regulations, there are guidelines to follow. Humans have been building stuff since the first ax hit a tree, while the consequences of faulty software has just recently started to manifest itself to the general public. Comparing software engineering to regular engineering is an unfair comparison when regular engineering is built upon hundreds, if not thousands, of years of experience.

        I heard a saying once, maybe it was here on /. The reason an older programmer is slower than a younger one is because of the number of answers he has to the question "what could possibly go wrong?". That is true on a larger scale for engineering vs. software engineering.

        Most large software projects are run by people who have fuck all clue what it entails to produce good software, people who don't see the value in spending another couple grand on a few more weeks of design, people who have clients they sold vapor to and now need the product yesterday. Software that works is easy to produce, and nobody can see the rickety scaffolding underneath, so it is really hard to argue with a non technical manager that something needs to be changed - after all, the shit works doesn't it?

        • Re: (Score:2, Insightful)

          by KingOfBLASH ( 620432 )

          Comparing software engineering to regular engineering is an unfair comparison when regular engineering is built upon hundreds, if not thousands, of years of experience.

          I'd disagree. Programming is a form of engineering and should be treated with no less respect.

          • by Cenan ( 1892902 )

            That was the point though. But software engineering is not treated with respect because 90% of the product is invisible. With regard to the reply you've made below about aerospace engineering, you're right, that is a new field too - but the product is visible, you can see what your money is buying. And even though it's flight, it still builds upon engineering principles accrued over a much longer time span than software engineering does. There no MBAs heading up engineering teams designing and building plan

  • by msobkow ( 48369 ) on Wednesday April 30, 2014 @02:38AM (#46875899) Homepage Journal

    It's a good article, and all too true. Software is a house of cards at best, with your boss shaking the table, the hackers throwing ping-pong balls at the house, and the NSA coming down the hallway with a baseball bat.

    • Nah, the NSA is more that asshole that comes sneaking up to your house of cards and keeps wiggling at the cards looking for the one they can pull out without having the whole thing collapse, then laugh with glee when they find one, dance around the house and that's when the whole thing comes down from the vibration they make on the floor.

  • by Ihlosi ( 895663 ) on Wednesday April 30, 2014 @02:38AM (#46875901)
    ... because gratification is delayed and not necessarily guaranteed.

    Compare this to digging a ditch, which is hard labor, but provides almost instant gratification (you can always look at how much of the ditch you've already dug), and you're not likely to fail completely (unless you're trying to dig in solid rock).

    • Programming is digging a trench in a puddle. You don't see what you're doing, you don't see your progress and due to the water seeming to rise as you dig away more of the ground you're standing on, it seems to get worse and worse with every load you throw out.

      • And people are busy pouring more water on that puddle with an occasional bucket of mud added.
  • Here's his problem:

    Every programmer starts out writing some perfect little snowflake like this. Then they're told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers' snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day.

    If you start cutting corners, you're going to end up with a mess. If you're a good programmer, you know how to write solid code even under time constraints []. If you're having trouble with it, then you should probably look into the YAGNI principle, or get better at estimating how long your tasks will take. Because those are the two things that seem to afflict programmers who are chronically behind schedule.

    Don't write bad code though, because you'll need to maintain it.

    • "get better at estimating how long your tasks will take"

      At my last programming job, the head of engineering took all my time estimates for a project and arbitrarily cut them in half, because "we're smarter than most companies".

      • I've worked at places where you just want to scream at the ineptitude of the seniors. They ask how long it will take to code. You tell them 3 months. They say do it in 2. You try and cut all sorts of corners, some dangerous, no room left for contingency then suddenly at week 6 you get told it's now 7 weeks not 8. Code goes to test and not surprisingly, it's crap. They then go nuts over code quality and say you must do better next time and faster again too. Dear seniors. The reason the code is crap is becau
  • The author has a great sense of humor, and ripostes some of programmings possible pitfalls into clever and hilarious absurdities. However, I strongly refute that this article is a remotely accurate portrayal of programming, and I hope it is not taken as such by prospective coders on the fence. In my view, programming is possibly one of the few havens of relative sanity available (although with wood-working and pure mathematics probably have it beat). The true insanity is HUMANS TRYING TO COLLABORATE WITH OT
  • by clickclickdrone ( 964164 ) on Wednesday April 30, 2014 @02:47AM (#46875933)
    What I struggle with is translating badly worded/badly thought through/incomplete business requirements into program logic. All too often something which seems straight forward to a business person is a can of worms when it comes to implementing it.
    • by Opportunist ( 166417 ) on Wednesday April 30, 2014 @04:21AM (#46876215)

      This. A billion times this.

      Back when I was still programming, i once got a spec sheet written on a post-it. Yes, a post-it. Half of it was a diagram. Ok, granted, that was a VERY special case where everyone involved had a kinda-sorta idea what's going to get programmed and it was by no means very complicated, but it showcases very well the problem.

      Later, when I was the one organizing a team of programmers, it was my policy that I get a written and signed spec sheet from the project sponsor. If he can't be assed to write specs, my team can't be assed to write code. And that was when I had the revelation: They don't really know what they want themselves. They only know one thing, they don't want what you will produce. They usually want something akin to a magical box that fulfills their wishes. And sometimes I get the hunch, especially with some of the older stakeholders, that this is pretty much how they view a computer. And programmers are some kind or arcane wizards who make the kettle boil and bubble until the program emerges somehow magically.

      They fully expect you to know their needs and usually have a very hard time communicating them because a lot of things that make no sense to you are obvious to them because it's their daily bread and butter. And hence these things will be sorely missing in the specs.

      I soon learned that it is a good idea to write the specs together with them if you want a project to succeed. You could tell I wanted your project to fail if I had no time to do that...

      • Exactly. What is supposed to happen is the business describe a need. A Business Analyst spends some time with them (weeks if needed) discussing it, teasing out what they really want (business people are very good at putting forward a solution disguised as a requirement and often, it's the wrong solution) and liasing with techies to see what can be done. That's your business requirements and rules. The architect then maps that to the systems available and decides at a high level how it all hangs together. T
        • What you are talking about is spending money. Why do that when the programmer should just be able to take the customers request an "make it work"?
      • They fully expect you to know their needs and usually have a very hard time communicating them because a lot of things that make no sense to you are obvious to them because it's their daily bread and butter. And hence these things will be sorely missing in the specs.

        That's why requiring a big upfront whole signed specification is useless. Users may not know what they want exactly, but they're very good at knowing it when they see it; they know exactly what problem they want to solve.

        Your job is to understan

  • Writing a piece on how programming sucks, in a typeface that hurts my eyes to read.

  • by Begemot ( 38841 ) on Wednesday April 30, 2014 @03:20AM (#46876047)

    Portable toilet cleaner
    Sewers cleaner
    Animal masturbator
    Janitor at a porno theater ...

    Programming is bonanza

    • by hawkinspeter ( 831501 ) on Wednesday April 30, 2014 @03:49AM (#46876139)

      Animal masturbator

      What? I can get paid to do that?

      • by SeaFox ( 739806 )

        Animal masturbator

        What? I can get paid to do that?

        At the zoo. Rare species that are almost gone from the wild but exist in captivity and they are trying to build up the population of.

      • I think it might be done sometimes in animal husbandry.

        I caught part of a documentary one time that was talking about needing to manually give female pigs an orgasm, but they didn't point that out to the workers doing that because it would be too horrifying. I suspect it was after the sows were injected with semen, to facilitate its passage to the right place.


    • They're not really difficult. They're just really unattractive (well, to the average person, I'm pretty sure there are people who enjoy wanking bulls).

      • They're not really difficult. They're just really unattractive

        In some sense, these two can be the same thing. For example, I find working as a teacher more difficult than any of the science/programming I've ever done, even though the individual technical challenges may seem much easier. Dealing with troubled kids from day to day can make your life feel difficult in a grander scale.

  • When people work in a group as a team this inevitably happens and that's all right. Building a perfect software that satisfies everyone is a hard NP problem. What's the point of being perfectionist if that 10% you wish to polish it going to consume 90% of your time and money.
  • by bmimatt ( 1021295 ) on Wednesday April 30, 2014 @04:10AM (#46876195)

    The comparison that has been coming to my head, regardless of whether I was self- or otherwise- employed is: coders are the plumbers of the Internet age. Furthermore, we are the electricians, the elevator drivers, the janitors, the security guards, the dealers, the cops, the architects. All generalized comparisons apply, because the Net is a representation of the world. Slightly skewed, a representation nonetheless.
    I am proud of the being an Internet plumber and cheers to others who spend their days trying make it work smoothly.

  • From what I've heard, actual construction engineering is typically not that far removed from the description in the article.

    Sure, the designs in construction engineering are way better proven and tested than the designs in software engineering, but the building process is in many ways still a trial and error affair where things can and usually will go wrong. Then the post mortems sometimes come with literal post mortems attached to them. How well do you think those engineers sleep at night?

    One nice thing ab

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      As someone who had a part-time construction job in college: It's amazing how many people doing that actual building on construction projects who fuck shit up and then hide it long enough that by the time it's discovered the designers have to tweak their near-perfect designs to incorporate workarounds.

      Thankfully you don't get that in software development, it'd be like a world in which developers wrote near-flawless code but your average compiler/interpreter played it fast and loose and did shit like randomly

  • by petrus4 ( 213815 ) on Wednesday April 30, 2014 @04:21AM (#46876217) Homepage Journal

    a} Clueless psychopathic suits in management, who make impossible schedule demands, and have no programming background themselves.

    b} The use of popular, but garbage programming languages. C++, PHP and Perl are probably the main three culprits here. Dishonourable mention also goes to XML, JavaScript, and the XHTML Document Object Model. I have never encountered a "Web application," yet, which wasn't a disorganised, bloated, CPU hogging abomination.

    For the last two months I've been economically forced to use a dual core 1.5 ghz laptop with 2 gb of RAM, and it can only barely keep up with the inefficient, JavaScript-infested obscenity that the Web has become. Virtually none of said JavaScript ever provides truly valuable functionality, either; most of it is just trackers of various kinds.

    It's also purely due to Capitalism; all of it. Why have Red Hat had Lennart try and force systemd, GNOME, and the rest of their corporate crapware on Linux users? Their desire for a corporate monopoly, that's why.

    What caused the UNIX wars? Corporations wanting to add their own non-standard extensions, to ensure their coveted Unique Selling Positions.

    We must get rid of the suits.

    • by Begemot ( 38841 )

      Following your post, if by any chance you haven't seen the Expert video [] yet, it's a must :)

    • by jandersen ( 462034 ) on Wednesday April 30, 2014 @06:24AM (#46876659)

      Clueless psychopathic suits in management, who make impossible schedule demands, and have no programming background themselves.

      Yeah, I can feel like that too, sometimes. However, I don't agree with the picture you paint - it isn't the case that all management is always useless and harmful and all engineers are always competent and beneficial, but so completely restricted in their options that they can't write good code. Most managers in most IT companies are in fact willing to listen to sensible advice and make concessions that make life easier for their staff; after all, a manager's success is measured by how well his team as a whole does, so a successful manager is likely to be one who is able and willing to communicate with his employees. But it only works if the employees are able and willing to communicate facts to the manager in a language he can understand and use to make sensible decision with; and engineers are notoriously bad at doing that.

      The use of popular, but garbage programming languages. C++, PHP and Perl are probably the main three culprits here. ...

      There is an old saying that goes something like: Don't blame the tool for bad craftsmanship. If you are a good programmer, then you can write good code in any language that you know - COBOL, FORTRAN, ... Haskell, C, C++, ... - even Intercal. The problem with some languages is that they demand much more of the developer - using C++ well requires a much higher level of theoretical understanding of good design than using a simple language like C, so it is much easier to loose your way in obscure and misunderstood constructs in C++.

  • by purnima ( 243606 ) on Wednesday April 30, 2014 @05:24AM (#46876439)

    Thinking is hard, but there is a kind of thinking that is harder.
    Rough order of thing (easiest to hardest).

    1) lounging around doing nothing (easiest)
    2) doing what you are told to do without physical exertion (menial white-collar work)
    3) doing what you are told to do with physical exertion (menial blue-collar work)
    4) independent thinking about things not involving organising other humans (programming, painting, composing music, solving systems of equations)
    5) independent thinking about things involving organising other humans (managing programers)
    6) independent thinking about things involving organising other humans who are in turn doing independent thinking involving organising other humans (hardest)

  • by sjames ( 1099 )

    I'm glad he's not bitter about that shit!

  • by Jeremi ( 14640 ) on Wednesday April 30, 2014 @10:04AM (#46878235) Homepage

    That was a pretty good rant, but if you want a true description of the mind-melting Lovecraftian horror that is programming (from a Microsoft distributed systems engineer, no less), there is no better read than this article [].

  • by maz2331 ( 1104901 ) on Wednesday April 30, 2014 @12:11PM (#46880169)

    Actually, it is more like solving a huge jigsaw puzzle, but without an actual picture of how it is supposed to look when it is completed, and with a picture that changes while trying to put it together.

Never worry about theory as long as the machinery does what it's supposed to do. -- R. A. Heinlein