The Ways Programming Is Hard

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

Comments

i've worked on that bridge

[maliqua]

he's right it does suck

Re:i've worked on that bridge

[TheLink]

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.

Re:i've worked on that bridge

[Anonymous Coward]

No, both bridge building and bridge designing are like programming and program designing. That's how i feel. You not only need to do the actual coding, but you need to design the software too and how users are going to use it. Atleast that's how i've had to all my projects. Well alright, i actually work with hardware too, but i don't get a say in the hardware part. I'm just given some hardware and told "it's supposed to do everything and do it right" and then i need to make a program for it and maybe the UI also. And when things don't work out in the physical world, i need to fix it in software.

Software engineering build phase is not the "make all"-part. It's the part where you type the code. "Make all" is just the part where you clean up after building.

Re:i've worked on that bridge

[gl4ss]

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:i've worked on that bridge

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

Re:i've worked on that bridge

[JaredOfEuropa]

Good point about the hardware: it's not just about the design and building, but also about the materials you get to work with, and the environment. Bridge builders use structural steel elements, bolts, cables, and need to account for environmental factors like the ground they're building on; software designers rely on computer hardware, the OS, the network, and they will also use APIs and libraries to build the software.

The problem with software components is that they are difficult to test completely compared to physical elements (it can be done but it's often cost prohibitive, and even then it is all too easy to make a mistake). Also, software doesn't fail gracefully but chaotically: small errors can have large consequence, and even a bug in an unimportant feature of the software can bring the whole thing down. In terms of our bridge: mount the railing next to the walkway incorrectly, and the bridge comes crashing down. Use Traffic Signs v3.0 together with Overhead Girders v5.41, and things come down; not just the traffic signs or the girders, but the whole bridge, and somehow the town downstream gets flooded, too. And god forbid you forgot to account for the brand and colour of the cars that will pass over your bridge; because the red ones will behave differently, and cause troubles. That's how software fails.

Re:i've worked on that bridge

[Beck_Neard]

Code always fails in exciting and new ways that no one can think of before the fact.

Re:i've worked on that bridge

[smallfries]

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.

Re:i've worked on that bridge

[Qbertino]

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.

Re:i've worked on that bridge

[Drethon]

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

Re:i've worked on that bridge

[gbjbaanb]

But when you want coding to be implementation similar to construction, you have to understand that the design phase would suddenly become much more like the old Waterfall methods - where the entire system was designed, locked down, fully thought out and specified to the last detail.

That approach works for bridges because an architect will basically take an existing design and will tweak it for the specific customer requirements . Software isn't so mature it has such existing systems to work with (though I 'd say it could be by now, there is far too much reinvention or tools, languages and frameworks to allow this to happen in reality).

So today, coding is still part of the design phase. Hopefully once the system is designed, the concept of deployment to production is more analogous to construction (think pre-fab structures being craned into place), but I feel deployment in the software industry is still part of the design phase too.

Re:i've worked on that bridge

[gbjbaanb]

So the trick is to create the components so they do work in a totally isolated manner. If traffic lights v3 had a very specific specification then we could reuse them.

We do this at the moment with some libraries - openssl was used across the world because it was a drop-in library that did what it said it would do. (ok, it had a flaw, but bugs don't really count in this discussion of design). similarly webkit is used for web rendering and it works well, because it does what it says it will and is pretty much a closed box. Http protocol works because its specified - much like the way roads are (set minimum width, camber etc) so to use it, you just have to designed your component to fit inside those parameters.

That's what we need to encourage - not the idea of frameworks where you are bent to the framework design, but in pluggable libraries that are designed independently of whatever system you are going to use them in.

But people don't do this - a library will be designed to do what they need at the time and then gets modified to suit the next project and so on. No standards are published and so other systems that use it become intertwined with special cases.

Re:i've worked on that bridge

[dbIII]

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 are next to each other and not eight metres apart is also part of engineering.

Re:i've worked on that bridge

[arth1]

But when you want coding to be implementation similar to construction, you have to understand that the design phase would suddenly become much more like the old Waterfall methods - where the entire system was designed, locked down, fully thought out and specified to the last detail.

Contrary to common perception, you need a design not only for waterfall, but for agile development too. 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.
The problem is that developers and managers don't want to spend that time up front, and think they can get something for nothing. And then it doesn't matter how good a programmer you are - you're coding by the seat of your pants, and things will break.
Making the problem worse are the coders who write unit tests after the fact to rubberstamp their implementation as "good", instead of exercising the robustness of the code against the design. Because there never was a design, and the coder isn't interested in discovering logical faults, just in getting an "approved" and move on.

Re:i've worked on that bridge

[BVis]

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.

Re:i've worked on that bridge

[alex67500]

Someone's been spending too much time on xkcd :-)

Re:i've worked on that bridge

[ultranova]

Getting that last pour done at 2am as the two halves of the bridge expand and contract enough that they are next to each other and not eight metres apart is also part of engineering.

How about knowing that concrete has very little tensile strength so it can't keep them from moving apart again? But maybe magic instantly-setting concrete is different.

Re:i've worked on that bridge

[BronsCon]

The bridge construction workers follow a plan that has already been decided, they don't get to change the design and decide whether to add another beam or not. So they are not coders - they are compilers", like software compilers they can make some "optimizations" but they are not supposed to deviate significantly from the design.

The bridge construction workers can stop construction if they see a problem (like a compiler) and point out where the problem is (like a compiler), but they can also point out a solution (much unlike a compiler) and they often don't have to restart the build from scratch after encountering an error, which a compiler most certainly would. A human developer, on the other hand, can point out solutions, and likely won't have to scrap all of his work of a problem is found in the design; and, much like the construction workers, the issue should be brought to the attention of the engineers who botched the design, and fixed by those engineers, before the developer continues his work.

If the specification for the program (the design phase) leaves enough wiggle room that the developer is making those decisions, then the design phase has failed. I think that's the whole point of this article.

Re:i've worked on that bridge

[BronsCon]

The problem with Waterfall is that, often, the people implementing it are not qualified to do so. In all honesty, there is no reason the engineer(s) designing it and the engineer(s) implementing it can't be one in the same; the important part is that the design is completed, by a qualified team or individual, before the build begins.

Re:i've worked on that bridge

[BronsCon]

This is precisely what the article is getting at. Compare the design phase you just described to the design phase from the summary; now, look at a real bridge construction design phase and compare that to the ideal software design phase. See it now?

Re:i've worked on that bridge

[brausch]

8 m of thermal expansion/contraction would make that the biggest bridge in the universe!

Re:i've worked on that bridge

[Bengie]

I may be missing some steps, but programming goes a bit like this.

Analysis -> Design -> Architect -> Implement

Analysis is the gathering of information in order to identify and solve the problem.
Design is kind of the flow of how the program will work. What very generalized "parts" are needed. Kind of like a story board is for a movie.
Architecting is about designing a structure that will allow the flow to work and the parts to work together. At this point, most of your interfaces should be completed and mostly static
Implementation is backing those interfaces with real code.

Re:i've worked on that bridge

[keytoe]

Most software requests seem to be more like "I want to drive across the Aleutian islands, make it happen".

Shortly followed by "We now need to support walking as well, but they need to get there as quickly as the people who drive. This should still fit in the 'get to Russia' spec, so we won't be adjusting your budget."

Re:i've worked on that bridge

[Phrogman]

You missed the stages where the customer changes their mind (and thus the requirements) half way through the project because "they read an article" - but has no idea what the consequences would be, or the stage where the lead developer decides he *hates* one environment and decides the whole project has to be reimplemented in a different environment (with no cogent reasons to support it), or the testing phase for the program is abandoned because there isn't time. Been there with all 3 of these.

Re:i've worked on that bridge

[Grishnakh]

I'm no civil engineer, but I imagine they use concrete-reinforced steel, not just plain concrete, to build bridges. Maybe "that last pour" also involves installing a bunch of steel beams, which are then encased in concrete.

Re:i've worked on that bridge

[BronsCon]

A big part of it is the "nobody is going to die if this isn't just right" mentality (except when they do) most developers take on. Even if the planning phase is done correctly, your average developer will take lightly any changes they feel need to be made to the design; when the whole thing comes crashing down, it's not like peoples' lives will be affected in any way. Right?

Re:i've worked on that bridge

[dbIII]

But maybe magic instantly-setting concrete is different.

You can simulate magical instantly-setting concrete over time by using a lot of wood and enormous steel cables to hold everything together while it sets. That is also engineering.

Re:i've worked on that bridge

[dbIII]

That situation was twist on segments of a huge box girder bridge which amplifies the expansion and contraction. Imagine a T shape twisting as forces are applied. Now imagine two of them.

Re:i've worked on that bridge

[Bengie]

That's why you have the customer sign off on the analysis stage, making the customer responsible for any delays if requirements are changed. This also requires that you actually do a good job with the analysis of the needs for the customer. They must be warned from the very beginning that requirement changes after each stage will cause greater and greater delays and costs and the customer is entirely responsible if they change their mind on key points.

Sounds like a good time to replace your lead developer. Proper development only works if you don't have a bunch of unruly kids doing the work.

Re:i've worked on that bridge

[NulDevice]

> That's why you have the customer sign off on the analysis stage, making the customer responsible for any delays if
> requirements are changed.

AHAHA HAHAHA HAHAHAHAH AHAHA HAHA HAHAHAHA HAHAHA HAH AHAHA HAHA HA HA HA

AHAHAHA HAHA HAHA HAHAHA HAHAHA

HAHAHA HAHAHA AHAHA HAHAHA HAHAHAHAHA

[wheeze]

HAHA HAHAHAHA HAHAHA HAH AHAHA HAHA

[cough]

Ahem.

Okay, sure.

Yeah, you can warn them from the very beginning. You can say "hey, don't ask for changes, because it will change the timeline." Then what they do is go over your head to some manager's manager's manager or the CEO who says "I don't care, we need this now and so-and-so says it's an easy change (and I don't know why you estimated 160 hours of dev time for this) so make it work. If you need extra time we'll just cut it off of the testing phase."

No dev plan is immune to office politics.

Besides, even if the customer is *aware* they're responsible for the delays and they assume said responsibility, *they're* not the ones coming in on weekends to write code to hit a deadline or scrambling to integrate the new change into a nice clean architecture plan. And upper management rarely yells at (or fires) the customers when stuff goes overbudget or over time.

Re:i've worked on that bridge

[Gripp]

Management often doesn't mind spending a bit extra to get the design better, because the budget only allows for one big Build.

As a structural engineer turned programmer: HA.

Re:i've worked on that bridge

[umghhh]

I see your point but what I see as bridge analogy actually more like a singled out one particular building type. You have many buildings where prefabricated parts are just put together and where say electrician or plumber just comes and make their job without much hassle and (hopefully) according to standard regulations. Then you have buildings like bridge where an architect must be there and where different parts of testing need to be done and where packaging and maintenance play a role. All this requires significant amount of project management and coordination effort whereas actual 'brick laying' activity is important but relatively small part of the activity.

Not even regulations and actual enforcement of standards, certification of the crew and quality oversight by external sources (which in some places are legal obligation) differ that much from SW projects - there are some where that is enforced by ordering entity.

SW crashes and may be useless upon delivery (I just took part in such a project). Bridges fail too so that is not a difference. The difference as in Tuo River bridge catastrophy lies elsewhere. According to wikipedia reasons for failure of this bridge are "Currently under investigation, believed to be linked to the fact that local contractors often opt for shoddy materials to cut costs and use migrant laborers with little or no safety training" - does that ring a bell? I am sure it does. You know what is the difference? I am also sure you see it or? That is the 'investigation' part - I vaguely recall distant past when I worked for a telecom infrastructure project where I was invited to a meeting of a crash commission. Needless to say such meetings are not held anywhere anymore. Why should they. There is namely another difference between 'brick laying' trades and SW: in SW there are gurus that tell management about their sure ways of fixing it all and produce faultless software at almost no cost. If you ask them you may even believe, until that is, you ask about failure cases of their system to which they have no examples i.e. no looking back at ruins is done in SW but wait we had that already or? Seems like we fell in a loop which is another SW characteristic that we do hardly have in building of real stuff...

"there's not much to indicate difficulty"

[FireballX301]

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:"there's not much to indicate difficulty"

[KingOfBLASH]

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 build something, and a form of entertainment (and pride) to be able to put something together. How many people can you say that about programming?

Re:"there's not much to indicate difficulty"

[x0ra]

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.

Re:"there's not much to indicate difficulty"

[MadKeithV]

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 long, but I still see quite a few newbie questions around Stackoverflow, Gamedev.net, people reading about the Raspberry Pi on the train, etc. etc. I think it's still going on.

Maybe I'm biased, because I've done some pretty crazy remodeling on a house, but building software is a LOT like building houses, lots of people just have really strange misconceptions about how well houses are(n't) built. Those same people are often in management, have to get an expensive second contractor in after the first one totally cocked up the extension to their 5-bedroom house because the I-beams he brought were a couple of inches shorter than spec but oh well, there is NO WAY that correlates to writing software (even though that's supposed to be their management expertise).

Programmers aren't special little snowflakes. People generally just do stupid things.

Re:"there's not much to indicate difficulty"

[wonkey_monkey]

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.

Re:"there's not much to indicate difficulty"

[ubersoldat2k7]

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.

Re:"there's not much to indicate difficulty"

[KingOfBLASH]

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 makes per hour, you may see things differently. But that does not mean that most of the people who go to home depot to fix things themselves are not there for entertainment. If you don't believe me just look at how many riding mowers and tractors the Home Depot sells. There is no need for a person with a normal yard to buy one of those things, if it was really about saving a buck they'd go with the cheaper walking mowers.

Re:"there's not much to indicate difficulty"

[khchung]

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

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

Re:"there's not much to indicate difficulty"

[Opportunist]

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.

Re:"there's not much to indicate difficulty"

[TapeCutter]

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 on a fishing boat in the notorious "Bass Straight" although the sawmill comes a close second the boat involved working 36hrs straight (30 min break every 5hrs), plus 30hrs travel time where you were either on 2hr watch in the wheelhouse, or hanging on to your bunk for dear life. The visual and auditory hallucinations from lack of sleep on the boat were a bit concerting at first but mine were the comedic variety, about 1 in 4 new deck hands have the horrific variety and quit after the first voyage. Oddly I look back at both of these with fond memories, possibly because it's when I was at peak fitness and surrounded by wilderness and good mates. There was "something good" about those jobs that you just don't get in an office building, I have never been to war but I imagine the comradely found in a foxhole is a more extreme example of what I'm talking about.
- The most stressful and mentally draining job was 12hrs behind the wheel of a city taxi.
- The most unhealthy and socially isolating job was 5yrs rotating shift work in a nylon factory
- The most ridiculous, sweeping a 5 acre concrete slab with a yard broom. (2 days, if you're wondering).
- The most uncomfortable - empting one ton bags of lime into a hopper, under a bare tin roof, on a 45degC day.

Software development - "find a job you love and you'll never have to work again".

Re:"there's not much to indicate difficulty"

[Anonymous Coward]

I think the point he was trying to make is that it's easier for anyone to see a bridge and get some idea of the difficulty of building it. Of course, the larger bridges give a bigger sense of awe than the smaller ones, or even the older ones where you say "wow, people really did this way back when!". It has to do with the tangible, physical, visually evident thing that's before them.

A bit of text on a screen that begins to flash red in ever-increasing frequency to alert of a "major" event looming in the near future. Not so impressive... because the difficulty of getting from zero to there is not evident to the average person. And you might say that there's a monitoring station in the antarctic that connects a system of buoys in the ocean with all kinds of sensors for tides, currents, temperature, salinity, pH levels and whatnot that sends the data over a satellite network (because Line-of-sight) and then to land-based station that shoots it over the internet to a big cluster of computers that make all sorts of complex predictions based on that new data and all the data that came before it (even the stuff from the 1930's we had digitized), and then sends and priority 1 message with an alert that in X hours some farm animals might experience dew... but, fuck, all they see is a little bit of text that's flashing red. Whatever lies behind what the person sees is not evident, tangible or even physical, so without the explanation you can't really make much of it. It's just not fucking there, like the bridge.

So now imagine you see the bridge and they tell you all the bullshit that went into building it... then you might say "wow, it's a wonder that thing is even standing"... and that is when you make the connection to the programming part.

Call it software engineering, software design, coding, programming, development or whatever else you might choose. If it's done "professionally" in a work environment where there are budgets, and customers, and deadlines, and teams of developers, and marketing, and non-techie bosses and all kinds of things; you're going to run into that bullshit.

And, in conclusion: http://www.youtube.com/watch?v=BKorP55Aqvg

Re:"there's not much to indicate difficulty"

[KingOfBLASH]

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)

Re:"there's not much to indicate difficulty"

[cowwoc2001]

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 depends on 100s of transitive dependencies. No one in their right mind includes transitive code in their security audits, unless you're the military and have that kind of money.

I'm not saying that building a house is any easier. I'd simply point out that we evaluate houses and bridges after a 30-year track record. If bad things happen, people get sued and there is some form of liability.

How many people behind software development (from the programmers up to the project managers) are liable for their work 30 years later?

Until we become liable for our work there will be no incentive to measure and improve some of these metrics. Just my 2 cents.

Re:"there's not much to indicate difficulty"

[Anonymous Coward]

" I'm quite sure an intelligent person could learn how to be a bricklayer if they really wanted to."
And that's the reason why the "armchair generals" are convinced they're always right.

Re:"there's not much to indicate difficulty"

[Opportunist]

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

Re: "there's not much to indicate difficulty"

[cbart387]

That assumes that working more hours translates to more money. Our bonus "takes into account" overtime, but it is not directly for every xxx hours we get xxx more. So I may make more a t my profession, but that does not mean that monetary it will save me money if I hire someone else to do work around the house.

Now, there is probably some type of heuristic I could use to determine at what point it is not worth my time, since some jobs would take me to long or I do not have the skill, but my point is that is little more complicated than just looking at pay.

Re: "there's not much to indicate difficulty"

[KingOfBLASH]

Many jobs do allow you to forego working for extra vacation days, at a pre-specified rate. So you DO have a specific "value" to your free time, as set by your employer. Even if you may have trouble redeeming it at that rate by someone who is not your employer.

You do however have the opportunity to pick up some consulting jobs, to do side jobs, or perhaps pick up some side projects. But, depending on what you do, YMMV. A lawyer, web designer, or other profession may have no problems picking up a few extra hours on the side, while you may not find this to be possible

Re:"there's not much to indicate difficulty"

[goarilla]

Yes and the tech industry would become a niche again. Computers are wonderful, someday we (the world) might even have 5.

Re:"there's not much to indicate difficulty"

[Mirar]

Yet people do it all the time, specifically about creative jobs: Video editing, logo/layout design, software design, architecture, music.
"All you did was to draw some lines and add some letters."

R&D usually ends up being "that thing that just cost money", because of idiots/tools that thinks like that. Companies close it down, and get surprised when customers stops buying the same crappy non-developed products that they want to keep selling for 20 years.

Re:"there's not much to indicate difficulty"

[TuringTest]

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.

Re:"there's not much to indicate difficulty"

[TuringTest]

s/wall/bridge/

Re:"there's not much to indicate difficulty"

[shadowrat]

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.

well, i'm paid on salary, so the amount i make per hour goes down the more i work. If i tell the boss i have to cut out early because i have these big home improvement projects i just have to get done, i actually start to make more per hour!

Re:"there's not much to indicate difficulty"

[sycodon]

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.

Re:"there's not much to indicate difficulty"

[ultranova]

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.

Your logic omits the "boss factor": it's more stressful to work for money, because then you're beholden to someone else, than for yourself. In fact "free time" usually means working, even if only by producing these comments, rather than just laying in your bed; it's free because you're not obligated to do anything, not because you aren't doing anything.

Re:"there's not much to indicate difficulty"

[canadiannomad]

s/wall/bridge/

I thought you were being serious the first time!.... I've seen too many cases of "Do this." And only finding out later that was meant as an easier first step to something completely different and actually unrelated in any way.

Re:"there's not much to indicate difficulty"

[GlobalEcho]

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.

Re:"there's not much to indicate difficulty"

[Jmc23]

You're a little too full of yourself and your profession and very ignorant of others.

If most programmers were intelligent, java wouldn't have been invented. All professions have idiots, geniuses, and clueless cheerleaders.

Re:"there's not much to indicate difficulty"

[egarland]

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

It definitely looks like something any idiot can do, but I fail every time.

Re:"there's not much to indicate difficulty"

[tlhIngan]

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)

There are multiple levels of skill required. At the very most basic level, programming is just a trade, like a bricklayer. You tell the bricklayer to build a wall of bricks here to there and all that, and they execute it. Just like you can tell a programmer you need a function to do X and Y and go do it. (You may even specify that since there's a gap in the ground, what the bricklayer should do, just like you tell the programmer to use quicksort to arrange the array). You might refer to these sort of programmers as "codemonkeys" because they went to a "learn to program in java" type course.

Then there's skilled trades and professions above it. After all, one may need to choose the kind of brick to use, the arrangement, design, mortar, etc to meet requirements of the wall. Just like a software engineer might go and look at the problem and break it down - figuring out what algorithms, architectures and other stuff to use and directing the programmers below them to actually do it.

Then there's the scientists - computer scientists, material scientists, etc., who go and figure out how to make better bricks, etc.

Re:"there's not much to indicate difficulty"

[Quirkz]

How many people can you say that about programming?

I'm more likely to do exploratory programming than exploratory building, though I've done both. I think on the whole you're right that more people dabble with the physical than with programming, but I think that's mostly because computing is still new enough that a lot of people don't realize they have access. Give it a generation or two and they'll probably be on par. Heck, most programming is free and can be done without leaving the house, which makes it more cost-effective and convenient than most builder projects.

This is also why all of my freelance business pursuits have been digital. Almost no startup costs, no equipment costs (I already had the computer, software is minimal), nothing to store, no mess, etc. Over time I think it's inevitable more people will catch on to the idea there's nearly unlimited potential for messing around at basically no cost.

Re:"there's not much to indicate difficulty"

[operagost]

That kind of depends on your definition of "normal yard", right? I have a total of 0.8 acres of land. Probably .4-.5 of it is covered by my house, a shed, a stream, driveway, and woods, so I only need to mow about a half acre. That used to take me three hours with a 21" walk-behind. I bought a used lawn tractor and it now takes me half the time. It would probably take me even less time if I didn't have so many trees, the shed, various parts of my overly complicated septic system, etc. in my way.

Not everyone has a tiny little yard, and not everyone buys a lawn tractor. Home Depot has many because not everyone has the same amount of money to spend or the same needs. Do you go to Best Buy and complain that not everyone needs one of those 50" TVs?

Re:"there's not much to indicate difficulty"

[operagost]

Lay down enough to make sure you don't miss a spot, then wet your finger and run it along the bead.

You now look like an expert.

Re:"there's not much to indicate difficulty"

[Herder Of Code]

Most software engineers I know have a fixed salary with no over time pay. There's no possibility of working overtime to make up for the price a plumber would cost me to change a faucet. I can either take the financial loss or do it myself to save money.

Re:"there's not much to indicate difficulty"

[Herder Of Code]

That's crazy talk, if you do that you won't be able to charge your clients enormous change fees when they realize they didn't really want a wall, they wanted a 5 bedroom house.

Re:"there's not much to indicate difficulty"

[Altus]

That assumes that you get paid for your overtime.

Re:"there's not much to indicate difficulty"

[Altus]

you do have a point though software is generally significantly more complex than your home actually is but there are several similarities. Having redone several bathrooms and kitchens myself I think I can confidently say that if you don't plan ahead all the way down to the final finish pieces when you have your studs exposed then chances are you are going to end up screwing yourself somewhere... probably in several places actually... ending up with a bit of super complicated molding or finish work or with two finishes that don't line up just right and require more work to smooth over. In a lot of ways software is exactly like that.

But don't be deceived, the level of complexity in a piece of software is insane and the amount of things that you have to think about is huge. On the plus side, in the software world that spackle code you use to fill the cracks is not as visible to the end user (directly at least) as it can be in your home.

Re:"there's not much to indicate difficulty"

[Bob the Super Hamste]

Nice to know I am not the only person who can't do this.

Re:"there's not much to indicate difficulty"

[Pentium100]

Not all jobs are like that. For example, I work as a sysadmin and sometimes I do get to work overtime if something important fails or if what I have to do cannot be done during normal work hours (because it will disrupt the service). However, I cannot choose to work overtime because I need the money, the clients would not like that (as they would be charged more).

So, I repair my electronic devices or my car, unless I do not know how to solve that particular problem or do not have the skills/tools necessary to do it (for example, I do not know how to weld, so I cannot patch a rusted hole in my car).

Re:"there's not much to indicate difficulty"

[Opportunist]

So an expert is someone covered in caulking material? Sorry, I thought that's the idiots wasting 10 times more than they actually use, seems I wronged them.

Re:"there's not much to indicate difficulty"

[Opportunist]

Another nemesis of mine. Or cooking an egg so that the yolk is still waxen while the white is hard (either it's hard through and through or the white runs away the moment I crack it open). Well, cooking is in general one of those fields that look oh so simple yet ... well, to put it simple and to quote a friend of mine (who is an accomplished cook) "Dude, get out of the kitchen, you're the only person I know who could literally scorch water."

wimp

[zephvark]

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.

Re:wimp

[KingOfBLASH]

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 generally doesn't want to pay for properly engineered solutions. But it is indeed a problem.

Re:wimp

[Cenan]

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:wimp

[KingOfBLASH]

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.

Re:wimp

[KingOfBLASH]

Bollocks. Aerospace engineering doesn't have thousands of years of history to fall back on yet we can still build planes that don't blue screen of death out of the sky.

The difference is that, when lives are at stake, people make damned sure things are reliable.

Another example would be engineering of chips. When's the last time you heard of a bug in your CPU creating issues? IIRC the last one was the infamous pentium bug from the 90s.

Transistors on a chip cpu engineering has been around for less time than software, yet they get it right...

Re:wimp

[Cenan]

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 planes. There are very, very few amateur plane builders selling their rickety winged contraptions (at least not ones made for passenger flights).

Re:wimp

[Anonymous Coward]

I've seen bugs in chips all the time. Most of the time people have to write bad software to account for the bugs in the chips. You aren't seeing most of the CPU bugs because OS programmers are seeing them and fixing them in drivers which you never touch. Take a look at errata: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-family-spec-update.pdf

Re:wimp

[Mr. Droopy Drawers]

it's a good example. That's not the last I heard. I'm under NDA. But, I can enumerate the multiple bugs we've seen with chips. Your point is valid. It's more about the human/dollar cost of the bugs. As fab costs have fallen and the more use of FPGAs, the cost of mistakes are lower and, therefore, more bugs have crept in.

Make the bug expensive and more discipline will be given to the problem.

Re:wimp

[KingOfBLASH]

Mod parent up.

That's incredibly informative! Thank you AC. For 99 goatse posts you always make one or two gems...

Re:wimp

[Altus]

he gets more into the issues of code later... the amount of domain knowledge necessary to do anything, the immense mental stresses of trying to hold all the necessary information about a complex system in your head all at once. The difficulty of thinking in long strings of complex logic.

But yeah, you are right, a lot of this is about how projects are run.

Wait, did I just hear you denying that the general

[aussersterne]

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.

Good article

[msobkow]

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.

Re:Good article

[Opportunist]

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.

Programming is "hard" ...

[Ihlosi]

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

Re:Programming is "hard" ...

[MadKeithV]

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

No, but what happens is that the architect comes along and tells you that the foreman picked the wrong side of the plot markers when telling you where to dig the ditch, so it's exactly a ditch-breadth off from where it should be. Please fill it up again and dig a new one to the side before the concrete for the foundation is poured, and by the way, the cement truck is arriving in 30 minutes.

Re:Programming is "hard" ...

[Opportunist]

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.

Re:Programming is "hard" ...

[Drethon]

And people are busy pouring more water on that puddle with an occasional bucket of mud added.

Re:Programming is "hard" ...

[Ihlosi]

No, but what happens is that the architect comes along and tells you that the foreman picked the wrong side of the plot markers when telling you where to dig the ditch, so it's exactly a ditch-breadth off from where it should be.

Yeah. Or a case of the dreaded undocumented ninja-spec that pops out of nowhere two weeks before the release.

Re:Programming is "hard" ...

[Ihlosi]

And people are busy pouring more water on that puddle with an occasional bucket of mud added.

They only add buckets of _mud_ where you work? Do they have any open positions?

Re:Programming is "hard" ...

[Drethon]

Recently they added a position for "Organic fertilizer shoveler" that I'm not sure about...

Here's his problem

[phantomfive]

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.

Re:Here's his problem

[phantomfive]

Then there's the plan change week three

Changes in plan are part of the reality of programming. Include them in your estimate. Write flexible code, that is part of YAGNI

If you have confidence in your estimates, don't let your manager push you around. Stand by it. Be kind, and tell him you will estimate anything he wants, but it will still not get done any shorter than your original estimate.

And make sure you hit your estimates. Programmers who have trouble with their bosses changing their estimates are usually the types of people who don't hit their estimates.

Re:Here's his problem

[dcollins]

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

Re:Here's his problem

[Opportunist]

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!

Re:Here's his problem

[SalafranceUnderhill]

Expect the unexpected!

Hmm...

Re:Here's his problem

[clickclickdrone]

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 because it was rushed because you wouldn't accept reality or lacked the balls to tell your boss that reality was different to what they wanted it to be.

Re:Here's his problem

[mrt_2394871]

a century ago, the same sorts of complaints were being made:
see The Ragged Trousered Philanthropists by Robert Tressell.

Re:Here's his problem

[Jmc23]

So what you're saying is it kept happening over and over again because you lacked the balls to tell your boss that reality was different to what they wanted it to be?

Re:Here's his problem

[phantomfive]

They went white in the face but told me that myself and 1 other person had to get it done in the remaining 2.5 months left because the ship date was a hard deadline and there were no other free resources........ These were very good managers

Clearly you have no clue what you're talking about

Re:Here's his problem

[phantomfive]

Design changes midway through are more expected than unexpected. Keep your code flexible.

Re:Here's his problem

[phantomfive]

You should feel no obligation to meet someone else's estimates. Work hard during your eight hours, but then go home. If you don't finish it, it's their problem for not making a reasonable estimate.

They might be upset, but just stare at them like they are an idiot. Don't dignify that kind of ranting with a response.

Re:Here's his problem

[phantomfive]

Exactly.

Re:Here's his problem

[dcollins]

Well, basically agreed, but: Someone with authority ranting at me like that for insane reasons upset me so much that I was constantly distracted and started having health problems. So I can't even dignify that kind of ranting with my presence. I got out of the industry after that, halved my salary and regained my health, but I assume those practices continue. The people who remained and were rewarded the most at that company wrote very bad code indeed (re: grandparent's directive).

Re:Here's his problem

[simonreid]

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 take all my developers estimates and arbitrarily double them,. In my experience even experienced developers will hit something they didn't forsee, or have requirements changes forced on them.

Re:Here's his problem

[keytoe]

I've experienced this first hand. I gave my estimate for a new feature. Over the course of the remaining meeting, I literally watched my estimate get cut in half by the client and management as they shuffled dates around.

I then chimed back in with my original estimate of how long it would actually take in the real world, and somehow everyone was upset that I had moved the deadline. Unreal.

Re:Here's his problem

[clickclickdrone]

Oh I tell them, they just say "That's not my reality". Twats.

Comedy != Informative Editorialism

[originofstorms]

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 OTHER HUMANS. If in doubt, please re-read the article with that in mind, and I think you'll find all the admittedly hilarious conceptions boil down to that issue, and that issue is pervasive in nearly any job you could name. Programming is an oasis from insanity, not ground zero.

Programming is the easy part

[clickclickdrone]

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.

Re:Programming is the easy part

[Opportunist]

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

Re:Programming is the easy part

[clickclickdrone]

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. Then designers work out the finer detail (often referring back to the business guys) and pass that on to devs.

Re:Programming is the easy part

[Drethon]

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

Re:Programming is the easy part

[TuringTest]

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 understand the problem well enough to build a solution; and showing the working result to the user is the only way to know if you understood the problem, and if the solution is good enough. That's why iterative design works, and waterfall doesn't.

Re:Programming is the easy part

[Kjella]

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 understand the problem well enough to build a solution;

No, they're very good at knowing that this is not the solution. What most people want is a computer that's practically mind-reading like on Star Trek, always understanding every nuance of an instruction and providing you with relevant information and solutions no matter how vague and ambigious the request. They may have a capacity planning problem, but you're not going to solve their problem. Maybe their real problem is that they're understaffed. Maybe their real problem is that their supply, demand and availability data is crap. Maybe their problem is executives rushing certain orders turning everything else into havoc. Maybe if you get coal as input your system can squeeze, shape and polish it into a diamond but if you get shit in, you'll have shit out no matter how much you spray it with perfume.

My impression is that if you've gotten to the point where you throw up "solution" after "solution" and they keep shooting them down you're on a death march project, people can stay unsatisified forever or at least until the money runs out and the project is cancelled as a gigantic failure. I agree that trying to figuring everything up front before coding behing is rather futile, but even in iterative design specs should precede code. If you haven't got good user stories, mock-ups, process flows descriptions and some real commitment and buy-in that this will solve the problem then there's really no chance that you'll be able to code an acceptable solution. You still have to drag it out of them, just in smaller pieces.

Re:Programming is the easy part

[clickclickdrone]

But, but... what colour should it be?

Re:Programming is the easy part

[Yunzil]

You got a post-it? I've been programming professionally for 17 years now and I have never been given a spec sheet. Ever.

Re:Programming is the easy part

[ObsessiveMathsFreak]

Back when I was still programming, i once got a spec sheet written on a post-it.

The programmers task is to create the concrete system which the executives are only daydreaming about. When executives give you such a document, they are giving you the freedom you to design, code, and implement the thing. Once you have created it, Code is Law, and the program gains its own authority.

Re:Programming is the easy part

[Rinikusu]

My dad was a machinist. Occasionally, he had bosses that were more interested in being bosses than actually listening and managing projects (hence the "You'll do this because I tell you to do this and you will like it" types). For these guys, he made a special point to always do *exactly* what they asked, without question, because hey "you're the fuckin' boss." So when his manager would occasionally bring him a napkin with a part drawn on it it, he'd quietly make a copy of that napkin, and get to work. So, when that boss would transpose his numbers.. say the inner diameter was greater than the outer diameter of the part in question, well, you can imagine. The boss would come back later and say "How's that part coming along?" "I dunno, boss, I'm just so confused. I keep trying to make it to the dimensions you requested, but it keeps disappearing" and he'd point to a pile of shavings/waste on the floor and shrug. If the boss tried to reprimand him, he'd have that napkin (and a copy) to produce and say "Well, you tell me what the problem is, hoss." Fortunately, those types of bosses didn't last very long (indeed.. they were usually promoted and transferred) and most of his bosses were reasonable and were open to discussion.

Re:Programming is the easy part

[Rich0]

Yup. This is most of my job, and I think I do a pretty good job at it, but it is a constant battle to get the time allocated to the project to do this job right.

Everybody just wants to get something done. The problem is that with this attitude the main thing the project accomplishes is spending the right amount of money on time, which is usually the metric that is easiest to measure. Then nobody can understand why nobody wants to use the system.

Getting the specs right is 80% of the battle. Good developers are also important as I've seen too many that will pull a "well, there wasn't a specific performance requirement that the time to tab from one field to the next be less than 30 seconds." Ditto for UI design - good requirements are useless if the coders just slap together something completely unintuitive, unless you want the UI to be dictated in the specs (which is usually a mistake unless done as a separate step from actually figuring out what the system needs to do). Still, those systems where the only solution is to toss and do-over are almost always the result of faulty requirements.

Re:Programming is the easy part

[Kevin Stevens]

This reminds me of when I was building a new stock trading system from scratch. We wanted to provide a web interface so you could enter orders, view your trades, etc. This wasn't considered a core thing, so it was outsourced to some guys in Brazil. These guys were smart, but knew nothing about our industry and clearly hadn't ever traded a stock. We gave them some mockups and specs, and what they gave us back looked just like what we asked for, but it was a usability nightmare.

The order and execution screens were in a random order, and there was no way to sort the records. Basic validations were not done- entering a negative number of shares or price was not caught for example. Summaries of numbers of shares, value executed, etc, were not there. There were just a bunch of things like this, that made the app a complete disaster to use.

But I realized after talking with these guys, it was entirely our fault. They really had no idea what they were building, how it was used, or who would use it. But they were amazing soldiers, I could have told them to walk in a straight line, and watched those guys just get up and walk, straight into a wall, and continue to do so until I told them to stop. Things like being able to sort the records, were so obvious to us that we didn't even think to put them in the spec.

Re:Programming is the easy part

[Opportunist]

You don't have to deal with C-Level idiots often, do you?

Re:Programming is the easy part

[Opportunist]

Depends, which one would be the cheapest? Maybe you have a sale of a certain color, we'd be very interested in that!

Re:Programming is the easy part

[cavebison]

I soon learned that it is a good idea to write the specs together with them if you want a project to succeed.

I turned into a freelance developer, as I really enjoy this part. Communicating ideas - the exchange between a client's broad scope ideas and my down-on-the-ground detail never fails to: a) enlighten us both about the other's domain of thought, b) give rise to new ideas - things they hadn't considered, and things I hadn't considered.

The I go away and code, but what keeps the satisfaction up on both sides is a constant level of communication. The more you update the client, even if it's little things, the more they appreciate the work you're doing. I feel that something is lost when the client and the developer are two separate silos, neither really understanding the other. In my experience, the client always gets something out of my technical approach, as I do from seeing my stuff help them do what they want to do.

Re:Perfect example

[x0ra]

Because the code I wrote is not what is being executed, and if it was, we would not have the level of performance we have today. Moreover, the level of complexity of today's computer. Moreover, tolerance are such in the physical world that a construction guy can afford to "cut corners", whereas software is a lot less tolerant to a bad input, remember, it's a dumb automaton.

Re:Perfect example

[Anonymous Coward]

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

Re:Perfect example

[x0ra]

Because proprietary software is better ?

This guy really has his nerve

[mbstone]

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

You know what professions are difficult?

[Begemot]

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

Programming is bonanza

Re:You know what professions are difficult?

[hawkinspeter]

Animal masturbator

What? I can get paid to do that?

Re:You know what professions are difficult?

[Opportunist]

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

Re:You know what professions are difficult?

[Anonymous Coward]

Congratulations - you can turn your hobby into a job!

Re:You know what professions are difficult?

[SeaFox]

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.

Re:You know what professions are difficult?

[TeknoHog]

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.

Re:You know what professions are difficult?

[Opportunist]

Dealing with kids is easy. What makes it hard is that the law for some reason prohibits shooting them.

Re:You know what professions are difficult?

[DoofusOfDeath]

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.

Shudder....

Re:You know what professions are difficult?

[hawkinspeter]

From the supermarket?

Re:You know what professions are difficult?

[hawkinspeter]

Oh. So the neighbours' pets aren't an option for that?

Re:You know what professions are difficult?

[leuk_he]

Become a farmer or a vet.

http://www-naweb.iaea.org/nafa...

Don't see the joy in that.

Re:You know what professions are difficult?

[goarilla]

Farms do it as well. It's too risky to let the male pig hump the female pigs.

Re:You know what professions are difficult?

[dargaud]

I caught part of a documentary one time

Yeah, yeah, yeah...

Re:You know what professions are difficult?

[hawkinspeter]

Mmmm! Tangy!

Re:You know what professions are difficult?

[greg1104]

Not difficult? You, sir, have a great deal to learn about animal breeding. I'd suggest Cracked's recent article.

Re:Perfect example

[antifoidulus]

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.

Re:Wait, did I just hear you denying that the gene

[MadKeithV]

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

Re:Wait, did I just hear you denying that the gene

[ATMAvatar]

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.

Overgenralized scenario.

[ajyand]

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.

Re:Overgenralized scenario.

[Chatterton]

And it is that mentality that make working as software engineer such hassle. These 10% are as important than the other 90% event if they take 90% of your time on the whole project. It's like a house. You have done 90% of the work once you have the wall, all the electricity and the plumbing ready. Sorry but these plaster panels and paint job are just for the perfectionists, they are not necessary to live in your house! But you still expect them no? This is exactly the same for software. You expect your software to work for every use-case because to implement that last use-case you need to rewrite or restructure a part of the already existing software. You expect it to work on the million records database and not the meager 20 records used for tests without needing a data center to run your program. I have seen too much of these corner cutting things from manager, saying that I am a perfectionist, who made what should have been a nice project into a living hell.

Re:Perfect example

[Opportunist]

If you're not satisfied with the level of quality in open source software, you're free, actually encouraged, to improve it.

Re:Perfect example

[MadKeithV]

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:Perfect example

[Opportunist]

Where's the paradox, it's the same in science. Everyone wants to make the new discovery, nobody wants to review and verify them.

ER, stat

[Anonymous Coward]

Fred only works with wood?
Perhaps he should consult a physician.

Re:Perfect example

[antifoidulus]

Well, the paradox is that open source and science both depend on peer-reviews, but the only people capable of doing them don't want to do them.

Plumber-architects

[bmimatt]

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.

Re: Plumber-architects

[cyber-vandal]

Until you have to unblock a toilet.

Re:Plumber-architects

[Rob Riggs]

Make sure your permits are in order and you've paid off the inspectors. Oh, wait... I see where the comparison breaks down. No one's palm needs to be greased when the job is done half-assed.

Actual bridge building

[rasmusbr]

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 about computers is that they usually have nowhere near enough mass to crush a person to death.

Re:Actual bridge building

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

True for two main reasons

[petrus4]

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.

Re:True for two main reasons

[Anonymous Coward]

C++, PHP and Perl are Turing complete. You can write beautiful code with them, and awful code. You can also write beautiful code and awful code with darling languages like Python. The real problem is, regardless of programming language, the people who write the code.

Re:True for two main reasons

[Begemot]

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

Re:True for two main reasons

[Anonymous Coward]

Ook and Brainfuck are also Turing complete. Turing completeness is not sufficient to imply that you can write beautiful code in a language.

Re:True for two main reasons

[jandersen]

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

Re:True for two main reasons

[Anonymous Coward]

"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 seen very well organized code in PHP and JS, and therefore the conclusion is that the culprit is not the language but the programmer and maybe improper management expectations.

I honestly cannot imagine that somebody who cannot do proper application architecture design, will be magically able to do so, if he switches to a different languages.

Conversely I do not see a reason, why somebody who can do proper application architecture design, cannot do so in PHP or JS.

Programmers just need to have a look at frameworks like Symphony or AngularJS, and grasp the basic object design patterns. Many programmers are not capable of this and switching language will not save it. They just need somebody to write class and method stubs for them, otherwise they always design garbage.

Re:True for two main reasons

[DoofusOfDeath]

Ook and Brainfuck are also Turing complete. Turing completeness is not sufficient to imply that you can write beautiful code in a language.

I think we should be honest that regardless of Turing completeness or not, different languages are prone to differently prone to horrific code in different circumstances.

Regular expressions, and old-school SQL, are not Turing complete. I've seen them elegantly solve some problems, and be a real mess in some other cases.

Similarly, I've seen Turing-complete (* see comment below) languages like C++, C, FORTRAN, and Python be used in some cases to write very clear code, and in other cases to be incomprehensible. Same goes for Turing-complete functional languages like Haskell and Erlang, although I haven't seen many programs written in them, so I'm less clear on which problems they're well/ill suited for solving clearly.

* Modern computers aren't really Turing machines. They have finite storage, and they have I/O.

Re:True for two main reasons

[twocows]

The problem is that some tools are worse than others. Yes, an artisan craftsman can make a good house with a carp and some thumbtacks, but that doesn't mean those are good tools. C++ is not a good language, nor are any of the languages he mentioned, and they just make things all-around worse for everyone involved.

Re:True for two main reasons

[BadDreamer]

You will not see a carpenter trying to make a beautiful desk using a set of dull dinnerware. The tool is definitely part of the quality of craftsmanship that can be produced.

Sure, a good programmer CAN write good code in any language, but who will pay for all the extra time required to construct the code well when the language is the opposite of helpful?

Not to mention the insane amount of effort required to co-ordinate a whole team working in a garbage language. Even if all members of the team can produce good code in it (provided the time to do that is available) they're highly unlikely to have consistent style between each other.

Re:True for two main reasons

[Rich0]

The use of popular, but garbage programming languages...Dishonourable mention also goes to XML...

Uh, if you're using xml as a programming language, you're doing something wrong. XML is a way to store structured data with fairly extensive support across many applications/languages/etc. The fact that it can be validated independently from any implementation that uses it is a great feature.

Sure, it is rather verbose, but if you're reading it by hand you're probably doing something wrong except in trivial cases.

Re:True for two main reasons

[jandersen]

Well, a good craftsman knows which tools are suitable for the job. And I don't agree with those who insist that some languages are 'bad' - most languages were designed with a specific purpose in mind, so solve that sort of problems well. A good craftsman also knows his own limitations and chooses his tools accordingly - and doesn't usually blame the tools for his limitations either.

What often annoys me is the flak C++ gets simply because people don't know how to use it well. That's a bit like calling Linux crap because it allows you to run 'rm -rf /' as root. Well made C++ code is easy to read and understand, because the important structure on each level is made more visible. Such as operator overloading: if the agreed convention or 'intuition' is that concatenating two strings is similar to 'adding', then it is perfectly reasonable to use the '+' operator for that. The fact that many developers are poor at designing their code is not an argument against overloading; it's an argument for looking before you jump.

Re:True for two main reasons

[BadDreamer]

Actually, Linux (or rather GNU rm) does not allow that. And C++ uses a lousy paradigm. Of course code written with discipline is good. The point is that C++ does not help or enforce that discipline. The fact that many developers are poor at designing their code is an argument for a language which makes it easy to read poorly designed code.

Re:programming is hard

[Opportunist]

Newsflash: We're living in the first world. If you want different problems, you have to move.

Not going to? Gee, wonder why. Could it be that you prefer having first world problems?

Re:Perfect example

[Opportunist]

That's true for both. When was the last time you saw a Nobel Prize winner repeat an experiment from someone else just to prove his colleague?

Re: programming is hard

[cyber-vandal]

I'm glad I'm not the only one who hates that patronising phrase. You're not dying of starvation or disease so you should be happy all the time.

Re:Perfect example

[Anonymous Coward]

If you aren't making a comparison you shouldn't draw a distinction. If closed-source software isn't better then the distinction in source-openness is irrelevant and misleading.

It's hard but not that hard

[purnima]

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)

Re:It's hard but not that hard

[Old Fatty Baldman]

7) independent thinking about things involving organizing other humans who were hired to do independent thinking but actually turn out to be duds who come in at 11:00 and just sit around drinking the free coke for six months then get pissed off when they don't get "genius" on their performance review then they go around trying to start a rebellion and eventually need to get canned and escorted out by security and you inevitably see them come back in three months as a vendor and as sad as that is at least it reminds you you'll never be out of work (even harder than that)

Re:It's hard but not that hard

[Bryan Ischo]

Interesting characterization. From the outside (5) & (6) don't seem that hard to me. Why are they so hard?

I "manage" my 6 and 7 year old kid every day, getting them to do what they need to do, getting them to meet schedules they don't want to meet, and that's got to be at least as hard as (5) & (6). And it's really not that hard at all. Frustrating at times - OK, well, most of the time, really - sure, but hard? No. Not in the way that 4 is hard.

Re:Perfect example

[Anonymous Coward]

The article is very funny, and makes a lot of good points, but it's not really addressing the question. It gives reasons software projects are difficult. Not why programming as such is. The engineering part, if you will.

The reason programming is difficult is because it's discrete. Whereas most (all?) other engineering is continuous.

If you try to bend a steel rod, there's going to be a range of strain for which nothing will happen, another where it will flex and recover, another where it will flex permanently, and finally a point where it will fail. This is all contiguous, and you can reduce it to a few numbers that will accurately predict the behavior of identical rods. Depending on the expected load, and the desired behavior, you can then pick the right rod, that will behave the way you need it to, with a good and predictable safety margin, because you know when what will happen.

Software, on the other hand, is discrete. That linked list can behave correctly as you add elements, then remove them, all good, then fail when you remove the last one and it (should) become empty again. There's no hint of that unless you test the very specific condition. There is no failure progression. There is no concept of safety margin.

That's why software regularly blows up. That's why it's difficult to make it not blow up. It's always on the edge.

Glad

[sjames]

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

Segmentation: core dumped

[jenatremens]

</rant> tag was not correctly open... I got down reading the whole article, but that thing crashed me!

Re:Perfect example

[gnasher719]

Where's the paradox, it's the same in science. Everyone wants to make the new discovery, nobody wants to review and verify them.

Verifying is easy. Checking and finding out that it doesn't work, not because you are too stupid to reproduce the experiment, but because it just doesn't work, that's the hard part. Plus you don't make friends doing that, obviously.

All You Have To Do Is...

[RabidReindeer]

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 Thursday, right?

Because a model bridge is patently not the real thing, but model software is virtually identical to the only parts of the system that most people will ever see.

Re:Perfect example

[Wootery]

Interesting take, I'd not seen it put that way before.

I once heard a horror story of an embedded software project. They were forced to only use debug builds, as the release builds seemed to trigger a race condition in the start-up code. The 'held together with paper-clips' approach to software engineering...

We can at least lessen the fragility by using regular testing and defensive programming.

(I'm almost crazy enough to think we should actually use the tools intended to make software that damn well works, but we all know that's never going to happen.)

Re:Perfect example

[Drethon]

Verifying can be fun, I like breaking other people's stuff. However I find companies rarely want to pay for it to be done properly since that often costs more than the development in the first place.

Of course it can be hard to test properly if the company doesn't want to take the time to say exactly what the program is supposed to do in the first place.

Laugh

[koan]

And can I get the header in cornflower blue?

young eng's heap success; old eng's bleed failure

[epine]

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

Yes, and wherever that experience is lacking because the progress and rate of change are related by a differential equation, what type of engineer manufactures the expanding putty? The Roman engineer or the von Neumann engineer?

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

Young engineers heap success. Old engineers bleed failure.

The Night Watch

[Jeremi]

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.

Car anology please!

[richtopia]

I just don't get this bridge thing... I know cars drive on them but how does that relate to anything!?

Re:Wait, did I just hear you denying that the gene

[thoth]

Or as so nicely put in The Codeless Code:
http://thecodelesscode.com/cas...

Re:Perfect example

[Anonymous Coward]

There are reasons for that:

1.) QA positions get no respect at any company I've ever worked for. Most of the time they are simply reduced to the role of "point and click monkeys", in quotes because I don't like the phrase and I've heard it from software engineers many times.

2.) Because of the lack of respect and complete misunderstanding of what good QA should be doing the pay differential between a QA position and a software engineer is massive and when companies make cuts QA is always seen as more expendable.

The reality is companies need to start treating the role of Quality Assurance Engineer with more respect and paying better money to attract good engineers to take the role. Reading other people's code, understanding what they are attempting to do, seeing the flaws and being able to fix them without creating more issues is a really tough job. In my opinion it is far more difficult than creating new projects and we should all start treating it as such.

Let's stop bitching about our jobs

[mikein08]

Bad code keeps many, many, many people fully employed at good hourly rates. So be thankful for it.

Part of why I got out of programming

[pubwvj]

This is part of why I got out of programming. I saw this coming a long, long time ago. I loved programming all alone. Creating clean, neat, tidy code with excellent, efficient data usage and easy to work with user interfaces that followed good standards and human interface dynamics.

But that has all changed. Coding has become like working with zoning regulators and legislators who know nothing about the rules or environments they deal with.

Now I just code for myself. I still get the enjoyment of it and don't have the hassle or stress.

One happy programmer.

Better Analogy

[maz2331]

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.

Re:Perfect example

[Grishnakh]

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.

It's not that much different for proprietary software. Some companies do take QA very seriously, and thoroughly test stuff before shipping it to customers. Aerospace companies, for instance, test their code extensively, since lives are at stake. Other companies don't.

Even hardware (silicon) isn't always that great. Intel only instituted the extensive verification departments it has now because of the infamous FDIV bug in the Pentium. Lots of CPUs and other ASICs have enormously long errata sheets, requiring software workarounds.

Re:Perfect example

[Grishnakh]

That's what code review is: it gets people to look at the code and do a visual inspection for style (to make sure violating coding conventions isn't going to introduce a serious bug; this is a big factor in embedded programming where, for instance, you can't use C++ exceptions or de-allocate memory), and also for bugs which are obvious upon inspection by others. It's not a substitute for formal verification or black-box testing.

Open-source software mostly works by using the users as bug-testers and encouraging them to file bug reports (or better yet, patches if they can). In effect, the users are the QA department. Since QA costs a lot of money (or at least effort), this is not a bad trade-off; you get the software for free, but there may be bugs. However, with so many users out there, some portion will be interested enough to file bug reports, and over time the bug quality will become very low. It also helps a lot if the software doesn't change frequently or gratuitously. Proprietary software is infamous for continuously adding more questionable features, or "bloat", in an effort to stay relevant and get people to pay money for an "upgrade". Look at Adobe's software for a great example. Their PDF reader is bloated beyond belief, and they keep tacking extra crap onto the standard. You don't see so much of this in open-source software, except maybe for a few particular projects (GNOME, I'm looking at you).

Also, it's not that big a deal if you find an odd bug in some open-source PDF reader or other application. A bug in a safety-critical piece of software is another matter.

Re:Perfect example

[Grishnakh]

QA people don't really need to be able to read code and fix bugs directly. That's not even an efficient use of resources. A proper formal verification team's job is to understand the system they're testing, create a test plan, and develop tools to test that the system works as it should (the more automation, the better, as you can use automation to increase the amount of testing and catch more corner cases). Their only role in understanding the inner workings of the system is to be able to help isolate the root cause of the problem, so that the actual developers/engineers who are responsible for the bug can be alerted to it ASAP instead of involving a bunch of unrelated people and having a lot of finger-pointing.

Source: I used to work in a formal verification department for multicore processors.

Re:Perfect example

[Grishnakh]

There's no shortage of shitty proprietary software filled with bugs, missing features, lacking documentation, containing unoptimized code, and having security vulnerabilities. With OSS, the shortcomings are simply more obvious and apparent to anyone who cares to look for them.

Yes, some proprietary software does real QA. Not all of it does, and a lot of it is half-assed.

Re:Perfect example

[greg1104]

Software that works very differently in debug builds is common. The 1993 edition of Steve McConnell's "Code Complete" was the first thing I remember reading that talked about reducing debug vs. release variance. IIRC, Microsoft was chewing this problem heavily then because the betas of Windows and their development tools going to developers included debug instrumentation, while the released versions did not.

SPARK falls squarely into silver bullet territory. Taking on that idea goes back to at least Fred Brooks's 1986 No Silver Bullet paper.

Re:Perfect example

[greg1104]

You're confused about the real cause and effect here. The biggest problem with open source QA is that no one wants to fund it. It's straightforward (albeit not easy) to solicit sponsors for building new features. The users of the software who financially benefit from it rarely feel like it's their responsibility to pay for QA across the whole project. And that's how QA normally works; ugly, time consuming bugs to chase down often start with a problem you can't even connect to the responsible code at first.

Developers don't just work on features over bug fixes just for status or personal satisfaction. You're projecting a sort of selfishness on them by saying that, which is a pretty silly attitude to have toward the sort of people who work on open source.

Getting paid to develop new features give you a clear finish line to get some money to support yourself at the end of the day. That's why open development ends up organized in that direction so often. The main thing that's different about commercial development priorities is that paying a person to do QA is recognized as necessary. When I raise money for open source development, I constantly struggle over how to put QA into the budget in a form that it's recognized as necessary.

This is absolutely at the core of the Heartbleed story. The OpenSSL Foundation has dumped large amounts of money toward checkblock compliant features like FIPS compliance. The same amount of money would have funded a lot of source code review, but people don't pay for that. If developers want to eat, they have to prioritize chewing on features.

If Google et. all want to help open source, they should provide a lot more funding. We don't need their QA departments, we need the cash they're making off our backs.

Re:Perfect example

[Wootery]

SPARK falls squarely into silver bullet territory.

Well, in terms of correctness, formal methods really are a silver-bullet.... assuming an infinite budget and an unchanging, well-understood spec ;-P

"Software Is Hard" / "Dreaming in Code"

[Paul Fernhout]

http://gamearchitect.net/Artic... By Kyle Wilson
""Software is hard," reads the quote from Donald Knuth that opens Scott Rosenberg's Dreaming in Code. The 400 pages that follow examine why: Why is software in a never-ending state of crisis? Why do most projects end up horribly over-budget or cancelled or both? Why can't we ship code without bugs? Why, everyone asks, can't we build software the same way we build bridges? ... But the nature of software is that the problems are always different. You never have to solve the exact problem that someone's solved before, because if software already existed that solved your need, you wouldn't have to write it. Writing software is expensive. Copying software is cheap. Scott Rosenberg coins this as Rosenberg's Law: Software is easy to make, except when you want it to do something new. The corollary is, The only software that's worth making is software that does something new."

See also the book http://www.dreamingincode.com/ by Scott Rosenberg:
"Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software sets out to understand why, through the story of one software project -- Mitch Kapor's Chandler, an ambitious, open-source effort to rethink the world of e-mail and scheduling. I spent three years following the work of the Chandler developers as they scaled programming peaks and slogged through software swamps. In Dreaming in Code I tell their stories."

I doubt it mentions how I wrote to the Chandler Project early on about using ideas like triples from my Pointrel project but did not get much of a reply... :-) Still my own project has been ongoing for decades. It's surprisingly difficult just to store and synchronize versions of data in useful ways when faced with uncertainties about future needs.

My latest attempt of many, many:
https://github.com/pdfernhout/...
"This stores snippets of HTML entered in a text area in a local IndexedDB database in your browser. These snippets can be displayed in a list below the edit box. TiddlyWiki was a bit of an inspiration for that list display. This is intended to support "bootstrapping" more a more complex system, such as Doug Engelbart worked toward to support a co-evolution of tools, knowledge, community, and processes."

Git is remarkable in that way in fitting into current practices of using hierarchical files changed by desktop tools. Still, it misses a lot as far as references to data items that can be exchanged globally (needing longer hashes), or dealing with large binary files (constantly rechecking stuff, but with workarounds), or dealing with rapid collaboration by several people such as to create shared drawings. But it is still awesome as far as it goes.

"Dat" is another up-and-coming approach I wish well, started by Max Ogden:
http://www.knightfoundation.or...
http://dat-data.com/
"Dat seeks to increase the traction of the open data movement by developing better tools for collaboration."

Citation needed.

[Barryke]

The main story is an interesting opinion piece.
But further down he represents facts that i dont believe. Citation needed.

Tell me more about the "two lines of code that parse two lines of embedded comments in the code to read the Mayan numbers representing the individual ASCII characters that make up the magazine title, rendered in 90-degree rotated ASCII art." program. I cant find it on the internet.

comprehensible opportunities == limit options

[Barryke]

Git is remarkable in that way in fitting into current practices of using hierarchical files changed by desktop tools. Still, it misses a lot as far as references to data items that can be exchanged globally (needing longer hashes), or dealing with large binary files (constantly rechecking stuff, but with workarounds), or dealing with rapid collaboration by several people such as to create shared drawings. But it is still awesome as far as it goes.

To that i say "To facilitate comprehensible opportunities, you have to limit options.".
This goes for game level design, the Apple ecosystem, jigsaw puzzles for toddlers, and the kind of focus that i only see in broke entrepreneurs that reboot their career.

Re: comprehensible opportunities == limit options

[Paul Fernhout]

Thanks for the insightful reply. I'll continue to think on it -- especially you last example. :-)

Remind me to never hire this guy

[laddiebuck]

I was having a conversation earlier today about this with a friend. Clearly this guy finds programming overwhelming, is likely to write hacky code, deals with pressure the wrong way, and concludes that everything is just broken. Maybe he's just too immature and it'll get better later, maybe he would just be happier in another field. A good engineer should not deal with the code quality vs time tradeoff by writing crappy code all the time. If he can't write maintainable code in the given timeframe, then either he is too slow or not standing up for the quality of the codebase. Either way, bad outcome. It seems to me that behind the hyperbole, he really has this view that is more appropriate to hacking away in the college computer lab than to real engineering. I don't particularly want to hire someone who dreams in code or works 80-hour weeks and cuts corners until his code is a mess. I would rather hire someone who gets the big picture of engineering. I think if he worked in a real coding shop (one where there are code reviews, and issues of style differences never even enter into the picture because you follow the group's coding style) he would get a better picture. But I guess when 9 out of 10 startups do embody the culture he describes... Thing is, 9 out of 10 startups also fail. When he described the failed bridge project- that kind of attitude doesn't cut it for long in software engineering either. But since he believes that's inevitable, it makes me think that's how he'd act.