Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming

The Ways Programming Is Hard 278

Posted by Soulskill
from the or-annoying-or-frustrating-or-etc dept.
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:
  • by FireballX301 (766274) on Wednesday April 30, 2014 @01: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.
  • by clickclickdrone (964164) on Wednesday April 30, 2014 @01: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 TheLink (130905) on Wednesday April 30, 2014 @02: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 Begemot (38841) on Wednesday April 30, 2014 @02:20AM (#46876047)

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

    Programming is bonanza

  • Re:Perfect example (Score:5, Insightful)

    by antifoidulus (807088) on Wednesday April 30, 2014 @02:21AM (#46876049) Homepage Journal
    It is....sometimes. The biggest problem with Open Source QA is also one that affects a lot of research, everyone wants to code, nobody wants to be a reviewer/bug fixer.

    Look at the HeartBleed bug, there was only one source review before release. There could have been more, but open source suffers from the peer-review paradox: the people with the ability and resources to do thorough reviews are the ones least likely to want to do reviews. Quite simply, there isn't any "glory" in it, and it isn't nearly as much fun as creating new code yourself. Now in big commercial operations, especially web sites, there are large QA departments where everyone has a financial motivation to scrutinize code and find weak spots. Really if companies like Google et. al want to help open source, they shouldn't just contribute code, they should donate their QA team's time and talents to doing really thorough reviews on critical open-source code before it's merged into the main branch.
  • by ubersoldat2k7 (1557119) on Wednesday April 30, 2014 @02: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.

  • by MadKeithV (102058) on Wednesday April 30, 2014 @02:32AM (#46876077)

    (Wait, did I just hear you denying that the general) 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.

    Bonus points for realizing that your own code from three months ago is also "other peoples' code".

  • by ATMAvatar (648864) on Wednesday April 30, 2014 @02:34AM (#46876095) Journal

    The best part is when you find out that the "other guy" who put in the stupid code is you from months or years ago. You start to get incensed and rant about what idiot would write such awful code, check the commit logs, then facepalm as you realize it was you.

    I occasionally wonder if that kind of thing would happen less frequently if our profession wasn't so quick to fire the guys whose gems turned black.

  • Re:wimp (Score:5, Insightful)

    by Cenan (1892902) on Wednesday April 30, 2014 @02: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:Perfect example (Score:3, Insightful)

    by MadKeithV (102058) on Wednesday April 30, 2014 @02:39AM (#46876113)

    This is a real problem. Open source projects have a very varying degree of Quality Assurance.

    Look at the name - Quality Assurance. QA can only tell you it's bad, it doesn't make anything better. And what they can look at is usually only the external, visible part, which may seem to be working nicely but built from spit and wire on the inside, ready to fall apart at the next version update of the printer driver. That doesn't mean QA is useless, it's just a final double-check to see that you've built the right thing.
    No, writing good quality software is a team effort of everyone involved. As a developer in the middle, you should be able to smile at the great design documents given to you by the system analysts, telling you what's needed and how, while having enough freedom to do it in the best way given the tools and frameworks you work with. And you should be able to high-five the QA people when they fail to find anything wrong when you deliver it, because you know that if they give their OK you can sleep on both ears and the users will be able to do what they need to do. And that's a good month's work if you managed to get there on the third try :P.

  • Re:wimp (Score:2, Insightful)

    by KingOfBLASH (620432) on Wednesday April 30, 2014 @02:46AM (#46876131) Journal

    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 Opportunist (166417) on Wednesday April 30, 2014 @02: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.

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

    That joke actually stems from Soviet times and was making fun of perceived and reported field yield vs. real, but it works just as well for management and projects.

    A programmer has to estimate how long he'd take to get something done. He ponders, calculates and finally decides: 3 months.
    His supervisor isn't happy with this, 3 months, that's probably too long. He notices the programmer has a vacation planned and there are a few holidays that he could work overtime in, he cuts those and corrects the estimate to 2.5 months.
    The group's superior isn't happy with that. The quarter report is due in about 2 months. But if they think they can do it in 2.5 months, they sure can do it in a week or two less by cutting time somewhere or working overtime, so he puts down 2 months.
    The department head doesn't like what he hears. The general meeting of the shareholders is in 6 weeks and he sure wants that prestigious project to be mentioned in there. But maybe somehow we can cut 2 weeks somewhere, probably we'll hire a temp or some other way that doesn't cost ... anyway, they can do it in 6 weeks, too, I'm confident!
    The project lead finally gets the estimate and is very happy. 6 weeks! We have almost 3 months time left! Time to push for those features I wanted, they said they'd tack 2 months onto the project, but somewhere they can surely shave off 2 weeks of those and we'll be done in time!

  • by Opportunist (166417) on Wednesday April 30, 2014 @03: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...

  • by Anonymous Coward on Wednesday April 30, 2014 @03:35AM (#46876279)

    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 round numbers up and down. Random rounding was actually pretty common when I did construction, the design clearly states that each section between two windows needs to be 1.9 meters, there are 12 windows on that side of the building and the sections come prefabbed in 2 meter segments that you're supposed to cut 10 cm from to get 1.9 meter segments? Yeah, Bob the 47-year-old foreman will shoot down any attempts to "waste time" by cutting the segments and suddenly you have to settle for just 11 windows because the total length of the wall is 1.1 meters too long. Because Bob thinks engineers are a bunch of pedantic wusses. Sort of like if your compiler were to try "optimizing" your floats and doubles to ints

  • by Anonymous Coward on Wednesday April 30, 2014 @04:32AM (#46876479)

    >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 doing, they say that they only have experience with hammers. So, you grab a bolt, put it in your hand and proceed to show them how to tighten a bolt and check with a torque wrench. You go back to the large section of the bridge roadwork you were assigned, but now horribly overdue for the CEO to drive his car around on. Days later, your boss checks on how the other workers are doing. Since they haven't accomplished much, they claim that your example was bad and they had to research on the internet how to tighten bolts. They proceed to pick up a bolt and tighten it with their hand, following your example _exactly_. "See? The bolts are not getting into the bridge! Only my hand!" Your boss looks at you accusingly and says "you should have tightened the bolts for them on the actual bridge!".

    This is the point where you proceed to jump off said bridge.

  • by jandersen (462034) on Wednesday April 30, 2014 @05: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 smallfries (601545) on Wednesday April 30, 2014 @06:04AM (#46876837) Homepage

    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.

  • by BVis (267028) on Wednesday April 30, 2014 @07:53AM (#46877503)

    Contrary to common perception, you need a design not only for waterfall, but for agile development too.

    And the problem is that the design for Agile is usually something like "This is what we're doing today, do what we say and shut up. Tomorrow we'll do something completely different, do what we say and shut up. No, we're not going to pay for changes, we like Agile because we don't have to do anything, just shut up and code." In my experience, this is the only half of Agile that actually gets implemented; the part where the business has to pay for changes, thus giving them incentive to think things through ahead of time and give adequate specs, is unpopular with the MBAs (as it requires them to do actual work and not drink lattes and play golf all day), so the coders get all of the drawbacks of Agile with none of the benefits.

    The API and specs should be done before a single line of code is written, and compared to other APIs and specs to ensure its compatibility. So you should have lots of small designs instead of one big book.

    And if you can document ONE case of that actually happening in the real world, go collect your Nobel.

    Because there never was a design, and the coder isn't interested in discovering logical faults, just in getting an "approved" and move on.

    The programmer frequently has no incentive to discover logical faults. They get punished for "not being a team player" and "asking too many obvious questions." They have incentive to make it someone else's problem through the approval process; however, even then it's the coder's fault even when it isn't the coder's fault.

I've never been canoeing before, but I imagine there must be just a few simple heuristics you have to remember... Yes, don't fall out, and don't hit rocks.

Working...