Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What Makes Software Development So Hard?

ScuttleMonkey posted more than 7 years ago | from the release-date-of-the-book-pushed-back-to-2010 dept.

Software 567

lizzyben writes to mention that CIO Insight is running a short piece that takes a look at why the rocky culture of software development continues to exist despite all of the missed deadlines, blown budgets, and broken promises. From the article: "I was not really looking or thinking about big software projects. I was just coming out of my experiences at Salon, where we built a content management system in 2000, which was painful. I was one of the people in charge of it, and when the dust cleared, I thought, I don't really know that much about software development. Other people must have figured it out better than I have; I must go and learn. So I started reading, and talking to people, and realized it's a big subject and an unsolved problem. And the bigger the project, the harder the problem."

cancel ×


Sorry! There are no comments related to the filter you selected.

good question (2, Insightful)

macadamia_harold (947445) | more than 7 years ago | (#17513702)

What Makes Software Development So Hard?

Why is conducting an orchestra so hard?

Re:good question (5, Insightful)

jonnyelectronic (938904) | more than 7 years ago | (#17513874)

It isn't. Haven't you seen them, all they do it wave their hands around and look silly. That's the point. Everyone thinks it's a breeze when it isn't, so everyone underestimates everything.

Re:good question (0)

Ambush Commander (871525) | more than 7 years ago | (#17514432)

Whoever modded this flamebait doesn't have their sarcasm-detector tuned properly today.

Re:good question (0)

Anonymous Coward | more than 7 years ago | (#17514056)

Why is conducting an orchestra so hard?
According to Kurt Masur it's becasue some musicians behave like a spoiled five year old brat. Of course that's only one opinion...

Re:good question (3, Funny)

xs650 (741277) | more than 7 years ago | (#17514130)

Why is herding cats so hard?

Software development is hard because.... (5, Funny)

Anonymous Coward | more than 7 years ago | (#17514268)

... of all the hot babes running around the offices in miniskirts giving massages that make it tricky to type. That, and the martinis that keep spilling in the keyboard. Combine that with the constant parties, sailing trips, ski trips, etc and it's a wonder anything gets done.

What's that you say? It's not the .com bubble anymore? Glad I left software.

Software developers? (0)

Anonymous Coward | more than 7 years ago | (#17513704)

Software developers?

Mod parent up! (4, Insightful)

EmbeddedJanitor (597831) | more than 7 years ago | (#17514054)

While the comment might just sound like a silly grab for a funny, I think this is a very valid point. We really have far too many developers who were not intended by the Intelligent Designer to be so. Software quality and robustness etc (which impacts on delivery schedules etc) are dictated mainly by the lowest performer in the group rather than the highest performer.

There's a whole industry of dev tools out there trying to convince management that SilverBullet will make your software come out on time, or make your crappy programmers more productive. I don't think so.

What we really need is to promote the concept of the CodeSmith like a balcksmish, silversmith or whatever, coding is a skilled artisan occupation. Instead of trying to keep good coders coding, most organisations try promoting them and making them managers. Eventually you're left with just the dregs coding.

Re:Mod parent up! (0)

Anonymous Coward | more than 7 years ago | (#17514322)

What is the hell is a "balcksmish"?

It's not hard (0, Flamebait)

Oz0ne (13272) | more than 7 years ago | (#17513730)

You just have to have a good system and management if it's a large project. That's all.

Re:It's not hard (4, Insightful)

daVinci1980 (73174) | more than 7 years ago | (#17513954)

Spoken like someone who hasn't ever been involved in the development of a large software project.

Large projects bring problems with them that aren't noticeable on small projects. The working set of my project is around 10 gigs, most of which is code and text files. The tree changes quite frequently, and syncing to that tree is painful.

What makes it more painful is when the tree is broken. So we had to develop tools to help ensure that the tree isn't broken, and that we have a way to tell what the last known good submission was.

There's performance issues related to the source repository, because no matter what repository you're using, they all have issues when you have 200 people working in the same place at the same time. (This is true of virtually any database application).

Re:It's not hard (4, Insightful)

CastrTroy (595695) | more than 7 years ago | (#17514318)

Exactly. Anybody who thinks it's easy to complete a large software project without problems has obviously never worked on real software. Secondly, anybody who asks why it's so hard to develop good software has never worked on a large software project. You can say a lot of stuff about following processes, and doing testing, but until you're working on a large project, with lots of different developers, with time and money constraints, you don't know what you're talking about.

Re:It's not hard (1)

Oz0ne (13272) | more than 7 years ago | (#17514396)

I didn't say there wouldn't be problems. I said it wasn't hard.

In my experience the only time it becomes difficult is when people are NOT doing their jobs. That's a people problem which should be addressed outside of the scope of the software project. Yeah, it effects you a great deal, but in any large project you need to know you can count on your team.

The only other problem I've encountered with software development are when people have unrealistic expectations, despite me telling them exactly what to expect and delivering on exactly that.

Re:It's not hard (1)

Oz0ne (13272) | more than 7 years ago | (#17514360)

I stand by my original comment. I've worked with multi gig source trees, perhaps not quite 10 gigs. The largest project I've personally managed was 125 member team. Perhaps your situation is a different scale... I really don't think so.

No you don't, you silly manager troll. (1, Interesting)

Anonymous Coward | more than 7 years ago | (#17514332)

Linux is a large project. It was managed effectively with no source control and no managers for years. If that's what you consider good management and a good system, I might agree with you; but somehow I don't think that's what you were saying.

Too much Management and Systems *ARE* what makes software hard.

It's complicated (3, Insightful)

fittekuk (1033554) | more than 7 years ago | (#17513734)

Software is complicated, and obviously the larger the project, the more peices need to fit together, etc. I think a lot of it though has to do with the team involved - both the developers and management. It seems to me, there are lots of "developers" around who really have no business writing software. And even more self-proclaimed architects who really have no clue.

Re:It's complicated (1)

RingDev (879105) | more than 7 years ago | (#17514450)

And there are yet even more supervisors and managers that have no business being in charge of developers.


Lemme Guess... (0)

Anonymous Coward | more than 7 years ago | (#17513758)

A bad process makes software development hard.

Poor specs, the dreamers from marketing, arrogant programmers, feature creep, unwanted input from people outside the process, lack of caffeine, and the users...oh the god damn users!

Totalitarian dictatorship and "hello world" can be simple if you work hard enough at it.

Re:Lemme Guess... (-1, Flamebait)

HomelessInLaJolla (1026842) | more than 7 years ago | (#17514058)

> arrogant programmers

Take, for example, this one [] who claims to have written huge portions [] of Slashdot [] by averaging a whopping 4 lines of code/hour [] .

Re:Lemme Guess... (1)

necro2607 (771790) | more than 7 years ago | (#17514340)

Ohhh yeah I forgot about that, programmer skill is of course based on number of lines written per hour...

Re:Lemme Guess... (1)

TheWoozle (984500) | more than 7 years ago | (#17514384)

[sarcasm]Because lines of code per hour is such a *great* metric for productivity.[/sarcasm]

Technically, with certain C compilers I can write entire programs on a single "line" of code. Please tell me how productive I am, then?
PHB's who measure productivity by lines of code/hr. get what they deserve. (Clue: it isn't nice).

Here [] . You're welcome.

It's design not development (5, Insightful)

gilesjuk (604902) | more than 7 years ago | (#17513760)

Writing the code from a good design is easy. It is creating a good accurate design, capturing all the requirements accurately and ensuring the end user's expectations are correct.

Re:It's design not development (4, Interesting)

MindStalker (22827) | more than 7 years ago | (#17514002)

Well no one really teaches software design do they.

You can go to school to learn to be a bridge builder and come out of it knowing all the exact specifications to build a bridge and probably design a fairly good bridge, or with a bit of creativity and some extra architectural skills a really cool bridge. Software design isn't really taught in this manor, sure your taught how all the bridge building tools work, and even a lot of the engineering specifications. But I have yet to see the software design school that covered more than a class or two into truly how to design software. Then again, we've been building bridges for thousands of years, and designing software systems for a few decades. It does take time for these things to really get figured out.

Re:It's design not development (1, Interesting)

korbin_dallas (783372) | more than 7 years ago | (#17514154)

That and software is more like art than engineering, but no one wants to admit that.
Of all the Renaissance painters that ever painted, only a few became forever famous.

Same thing with coders.

Re:It's design not development (4, Insightful)

HappySqurriel (1010623) | more than 7 years ago | (#17514336)

That and software is more like art than engineering, but no one wants to admit that.
Of all the Renaissance painters that ever painted, only a few became forever famous.

Same thing with coders.

I personally would use the term "Craft" rather than art because I have always believed that art is about "saying" something through your craft which I don't think is really the goal of software development. The truth is that anyone can be taught to be a reasonably good muscian, artist, or blacksmith and with proper motivation anyone can become great. I would say that there are two problems currently, schools focus on the wrong things (how often did you gather requirements, properly design, implement to given specifications, effectively test, or maintain a program in your school years?) and the industry seems to focus more on technology rather than skillset (does it really make that big of a difference to program in C# as compared to Java?); the result is you have someone who is trained to use a hammer designing your house, and you ask someone if they know how to drive a "Ford" when you are interviewing a truck driver.

Re:It's design not development (5, Insightful)

nuzak (959558) | more than 7 years ago | (#17514198)

We've had a couple of thousand years of practice building bridges, and bridges solve a known problem: connect points A and B when there's a gap or a river inbetween.

Software engineering is "Do X, Y, and Z except when A, B, but not C except when A and B and when user isnt E except when user is E and A and B and X and Y are not Z but Z is B when F is ..."

Re:It's design not development (5, Funny)

MeanMF (631837) | more than 7 years ago | (#17514274)

Software engineering is "Do X, Y, and Z except when A, B, but not C except when A and B and when user isnt E except when user is E and A and B and X and Y are not Z but Z is B when F is ..."

That was yesterday....We'll be sending you the updated specs soon.

Re:It's design not development (1)

scdeimos (632778) | more than 7 years ago | (#17514388)

Mod parent up! Yes!

Re:It's design not development (0)

Anonymous Coward | more than 7 years ago | (#17514422)

Thanks for making me laugh :-)! Wish I had mod-points for you.

Re:It's design not development (5, Insightful)

kevin_conaway (585204) | more than 7 years ago | (#17514014)

Writing the code from a good design is easy. It is creating a good accurate design, capturing all the requirements accurately and ensuring the end user's expectations are correct.

The problem is:

  • There is no such thing as "all the requirements." The only thing you can count on in software development is that the requirements will change
  • The end users have no idea what to expect or what they want. They may think they want X, but they really want Y after seeing what X looks like.

Re:It's design not development (2, Insightful)

xero314 (722674) | more than 7 years ago | (#17514324)

I think you are getting at the point but in a bit of a backward way. The problem is that somewhere along the line the idea of Software Engineering was thrown out the window and replaced with ( or reverted too, depending on how you look at it) software development. If you apply the principles of Engineering to software you end up with far more stable and durable products. If we built buildings like we build software there would be millions of people dying from "unforeseen bugs" or rooms that could not be accessed because the "interface" was not clearly defined (of course you would go back and put the door in by severing an important support beam causing massive loss of structural integrity, but I think you get the point.)

Excuses like;
There is no such thing as "all the requirements." The only thing you can count on in software development is that the requirements will change
The end users have no idea what to expect or what they want. They may think they want X, but they really want Y after seeing what X looks like.
are the exact reason software sucks. Not because these things are true, because they certainly are not, but because we are not applying logical engineering principles to the problem.

Re:It's design not development (4, Informative)

truthsearch (249536) | more than 7 years ago | (#17514118)

The last project I was on which had requirements that didn't change at all during development was 7 years ago. And it was built right on schedule. For me it's been the ever-changing requirements which delay projects the most. The other half of the problem is usually bad estimates, but that's almost irrelevant after the requirements change.

What makes software development so hard...... (3, Funny)

Chineseyes (691744) | more than 7 years ago | (#17513774)

Viagara, Cialis, red bull, two brazilian hookers and a swiss midget.

Re:What makes software development so hard...... (1)

SoulRider (148285) | more than 7 years ago | (#17513936)

Um, thats "What makes software development so hard", not "What makes software developers so hard"!

Re:What makes software development so hard...... (1)

iamdrscience (541136) | more than 7 years ago | (#17514066)

two brazilian hookers and a swiss midget.
Herein lies the problem, how often are you going to find two brazilian hookers and a swiss midget in the same place? I would think there are probably more brazilian hookers in Switzerland than Swiss midgets in Brazil, but it's really unlikely either way. I think the best solution to this would be to fly from Switzerland to Brazil with a Swiss midget as your carry-on, that way you're not leaving anything to chance.

Thank Goodness (1)

pyite (140350) | more than 7 years ago | (#17513778)

That was a close one. If this was another Joel on Software article, I was going to have to promptly defenestrate [] myself.

Re:Thank Goodness (1)

xlordtyrantx (958605) | more than 7 years ago | (#17514380)

Are you trying to educate slashdotters?

One word: Skill, Talent and Knowledge (5, Insightful)

rudy_wayne (414635) | more than 7 years ago | (#17513784)

Anyone can write a book. But, writing a book that's *GOOD* and that people will want to read is an entirely different matter.
Computer software is no different.

Don't treat it like a science. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17513788)

The idea is that if we're going to turn the creation of software into a true science, we need to first have principles.

Treat it like an engineering discipline.

With science, you're observing and making measurements of the natural world and testing hypotheses to develop a theory on the how and why of nature.

Engineering, OTOH, you are applying natural physical laws to create a man made piece of technology or something.

Ok, here comes the Wikipedia cites on science and engineering from folks who are completely missing my point.

Why? (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#17513794)

Because I can't write every line of code myself.

The answer is easy (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#17513802)

The over abundance of stupid programmers or programmers tought in India. I guess those aren't mutually exclusive. Oh yeah and also the fact that smart programmers come out of school thinking that the real world is just like college where everything must be perfect and "elegant".

Re:The answer is easy (0)

Anonymous Coward | more than 7 years ago | (#17514020)

smart programmers come out of school thinking that the real world is just like college where everything must be perfect and "elegant".

It's not just a thought, real world code is so repulsive it's almost unbearable. Software, like art cannot be forced and the world is only interested in paying for cheap prints sold by marketoid parasites. Often the more aesthetically pleasing app is superior in the mind of those holding the purse strings. Microsoft know a thing or 2 about software in the real world, Superficial enhancements for the win.

Re:The answer is easy (1)

DavidR1991 (1047748) | more than 7 years ago | (#17514032)

I would reeeally like to see your code. Seriously. Then we could have a flamebait style code-review just like your post, where we humiliate your coding skills (if existent in any form at all)

Simple, really. Three words (0)

Anonymous Coward | more than 7 years ago | (#17513834)

the goddamn users

Re:Simple, really. Three words (1)

Archangel Michael (180766) | more than 7 years ago | (#17514222)


Except we tend to call them L-Users, or function 1d10t faults. As in "We suffered a fault in function 1d10t and are currently patching the system."

Seriously though, Never underestimate the power of a group of average persons to exceed your expectations and find the one (many?) undiscovered bug. Whatever you can think of, they can exceed in mere minutes.

People expect too much too soon. (5, Insightful)

Dex5791 (973984) | more than 7 years ago | (#17513846)

Good software takes time to develop. There is sometimes a tendancy to set unrealistic goals and when they aren't met the people in charge feel let down.

What large projects DON'T have problems? (4, Interesting)

panaceaa (205396) | more than 7 years ago | (#17513858)

In related news, humans still can't seem to bridges [] with any reliable schedule or budget. Despite the fact that bridges have been built probably since the dawn of man, and we've been building suspension bridges for at least 500 years [] .

Re:What large projects DON'T have problems? (0)

Anonymous Coward | more than 7 years ago | (#17514104)

we've been building suspension bridges for at least 500 years.

That was before the formal invention of capitalism, back when people did it right the first time because that made the rich people that fed and housed them look good.

Now, it's simply a function of how much money can be extracted by doing the least amount of work for the most money possible. Employees do this because they're "lazy good for nothings communists who think they deserve a free ride", corporations that do this are "shining examples of capitalism who deserved every dollar that was coming to them".

Bay Bridge (2, Interesting)

whoever57 (658626) | more than 7 years ago | (#17514374)

The Bay Bridge is an interesing parallel -- the delays have been caused by unclear and shifting requirements (which are focussed on the aesthetics). These changing requirements have led to delays and cost overruns.

Two things make software "hard" (4, Insightful)

mandelbr0t (1015855) | more than 7 years ago | (#17513866)

First, the people who make the technology decisions often don't have the required technical know-how, and have a terrible tendency not to listen to people who do. OTOH, the people who have the technical know-how have absolutely no idea how to write a business case. Thus, there's usually a disconnect between the people who understand the business requirements, and the people who understand the technical requirements. Vendor loyalty has been known to be a sticky issue as a result.

Second, there's always a problem getting a bunch of talented, egotistical (ok, so not all software developers have ego problems...) quirky, eccentric and generally difficult people to work toward a common goal. The common analogy to being a successful director/manager of a software project is to that of "herding cats". My experience has been that business types don't react well to the often-emotional developer types, hearing the emotional outburst, but ignoring the content of it. Developers would do well to learn some more social skills, and director/manager types would do well to listen better.


Re:Two things make software "hard" (0)

Anonymous Coward | more than 7 years ago | (#17514372)

First, the people who make the technology decisions often don't have the required technical know-how, and have a terrible tendency not to listen to people who do. OTOH, the people who have the technical know-how have absolutely no idea how to write a business case.

Actually, they usually do, that's why there are sales departments to prevent them from communicating to the customer the expected budget and time..

... Posting as an AC for obvious reasons

Theory is great (4, Insightful)

hsmith (818216) | more than 7 years ago | (#17513878)

practical application isn't so. Requirements change, clients see something and want something different. You work a month on something and find out it isn't working anywhere close to the way it should. Tasks are more complex then people thought at first, the list goes on. It is a complex thing with infinite ways to do things. It isn't any easy process.

Technology Review tackles the same subject... (1)

mcho (878145) | more than 7 years ago | (#17513888)

...but, instead, they profile Charles Simonyi and his quest to "re-program software".

He's developed an approach he calls intentional programming (or, more recently, intentional software), which he hopes will overturn programming. If Simonyi has his way, programmers will stop trying to manage their clients' needs. Instead, for every problem they're asked to tackle--whether inventory tracking or missile guidance--they will create generic tools that the computer users themselves can modify to guide the software's future evolution.

Read the article at Technology Review. []

Slashdot. (0)

Anonymous Coward | more than 7 years ago | (#17513898)

Slashdot makes it hard.

PHB? (3, Insightful)

Jumper99 (51637) | more than 7 years ago | (#17513904)

I find most of the issues that arise on projects are not so much that the developers are incompetent, but that no one sets realistic, or are not allowed to set realistic expectations. How many times does the business change the specs? How many times are the developers given more time to allow for the changes?

The last project I worked on had a hard deadline. We were in the UAT phase when the business decided it wanted a change. A big one. Despite the fact that we were mere days from production, we were expected to make the changes, test them, and still meet the schedule. IT managements take was as usual. The business pays the bills so the business gets what it wants.

Until IT management can stand up to the business side, software development will always suffer.

Where software developers sell themselves short (5, Insightful)

Digital_Quartz (75366) | more than 7 years ago | (#17514070)

When you've contracted an engineer to design a bridge, and you want to make several large-scale changes to that bridge, the engineer will come back and say "If you want these changes done, this is how long it will take. If I don't have that much time, I can't make the changes".

In fact, I'd go a step further; software developers tend to say "This is how long it will take to make the change, and this is how long it will take for me to hack something together." Bridge engineers don't say things like that. They don't put that "hack something unsafe together" option out there on the table, and neither should we.

I think one of the biggest problems in our industry is accountability. The engineer would never put the unsafe option on the table, because the engineer knows he'll loose his license and go to prison if the bridge collapses. With software, on the other hand, we just expect our customers to deal with the fact that it fails, and we behave accordingly - and unprofessionally.

Re:Where software developers sell themselves short (1)

Cro Magnon (467622) | more than 7 years ago | (#17514266)

I think one of the biggest problems in our industry is accountability. The engineer would never put the unsafe option on the table, because the engineer knows he'll loose his license and go to prison if the bridge collapses. With software, on the other hand, we just expect our customers to deal with the fact that it fails, and we behave accordingly - and unprofessionally.

It's not just that we put "unsafe" software out there. It's that our bosses expect us to put unsafe software out there. I try to test everything, but when the requirements are changing long after we SHOULD be in beta, and the boss wants it out by such-and-such a date, something has to give, and often that something is proper testing.

Hard is better than impossible (5, Insightful)

composer777 (175489) | more than 7 years ago | (#17513916)

The reason it's hard is because we are doing the impossible, at least if you had asked someone 50, 20, or in some cases even 10 years ago. Solving previously impossible problems requires quite a bit of innovation and novel thinking. But, it's better than it was decades ago, even if it is difficult. What we need to remind people is that even with fast computers, the problems are still difficult to solve.

Also, automating tasks that we used to perform ourselves is also difficult. It's one thing to walk and chew gum, but another thing entirely to precisely describe the mechanics of doing so. (One is very easy, the other requires creating precise models of how things work, a very hard problem).

Ideas come faster than code (5, Insightful)

nharmon (97591) | more than 7 years ago | (#17513932)

What Makes Software Development So Hard?

Simple. The current state of technology in regards to human imagination makes it many times easier to think up of good ideas or improvements for computer software than it takes to create or implement them. Thus the requirements for developers are often made by the ones with the ideas with no idea of the costs (in terms of time or money) involved in making those ideas a reality.

Joe Sacks says "Gee, it would be a great idea of our flight tracking program also tracked fuel usage and recommended fuel loads to minimize weight on subsequent flights". See? It only took Joe all of about three minutes to think that up. He figures that a reasonable amount of time to implement this idea is one or two days. After all, those "computer guys" are pretty smart and can "do anything".

Two days later Joe receives a report that the "project" is over budget (needed to check with the FAA on this one, that cost money) and overdue.

Sure, you could just say that these problems need good project management. But seriously the problem is that these "problems" are not considered worthy of project management. It only took Joe three minutes to think the idea up...why should he hire a project manager for *THAT*. It's not like he's building a new hangar.

One wag of my finger, one tip of my hat (4, Interesting)

iPaul (559200) | more than 7 years ago | (#17513934)

First the wag: The idea that the interveiwee states early on, that software development is not introspective, is horse-hockey. We think about it all the time. We invent new, clever ways to diagram software, capture requirements, interview users, validate functionality and come with all sorts of certifications. More than, say accounting, we are process focused people. Maybe our processes suck, but we spend a lot of time, energy, certification exams, etc, on those processes.

Tip of my hat: He does mention starting small and iterating. I think that's the best way to build software.

the devil is in the details (1)

prgrmr (568806) | more than 7 years ago | (#17513946)

Rarely can a single person manage all of the details. Coupled with the generally poor estimating skills I've observed at all levels of staff and management, technical and otherwise, significant portions of projects tend to be guesses. Granted, usually educated guesses based on a certain amount of information, but ultimately still guesses. Getting management and users to want to have the patience to quantify everything is all but impossible.

For Me (5, Informative)

KermodeBear (738243) | more than 7 years ago | (#17513972)

What makes software development so difficult for me in my particular case:

1. Requirements are not clearly defined
2. Requirements that are defined change constantly
3. No existing documentation on the system I work with
4. Outdated technology (Not a big issue, but many things are just easier to do with newer software)
5. The sales department sells features that do not exist, promise a date, and do not consult IT at all about the feasibility or time estimates

4 out of the 5 things I have listed above have to do with bad information / lack of communication.

Re:For Me (1)

cryfreedomlove (929828) | more than 7 years ago | (#17514234)

> 5. The sales department sells features that do not exist, promise a date, and do not consult IT at all about the feasibility or time estimates

My advice to you, for this item, is to begin looking for a new job right now. If your sales force can't make enough money selling the product you already have then you don't have a great product. Then, couple that with the fact that your sales force seems to have free reign to put the company into lose-lose deals that will end with bitterness for the customer.

Be candid with management. If that does not work then run away. There are alternatives at the same or greater income level. That's been my direct experience.

Re:For Me (1)

KermodeBear (738243) | more than 7 years ago | (#17514348)

Working on it right now. (o: However, my last job had the exact same problem, and I fear that I'm falling prey to "The Grass Is Greener..." mentality. I'm also not quite how nice it is to ask in an interview, "So, does your sales staff sell things you don't actually have?" I suppose I'll find out soon enough.

the five p's (0)

Anonymous Coward | more than 7 years ago | (#17513992)

Pre-planning Prevents Piss Poor Performance

Why is it so hard? (1)

CasperIV (1013029) | more than 7 years ago | (#17514008)

It's hard because of stupid people. I swear, users get increasingly more challenged as time goes on. An incompetent user would rather push the wrong button and see what happens then read anything. My new system is fool proof; each button will be a color coded geometric shape....

Oddly... (-1, Troll)

Otter (3800) | more than 7 years ago | (#17514018)

What I find astonishing is how the dopes who can't reliably build something as familiar and unambitious as an internal "content management system" can insist that if cancer hasn't been cured, it must be because of a conspiracy.

Re:Oddly... (1)

HomelessInLaJolla (1026842) | more than 7 years ago | (#17514138)

As a medicinal chemist I second this.

Complexity & Culture (4, Interesting)

denoir (960304) | more than 7 years ago | (#17514022)

There are two major reasons why software engineering is today not comparable to more traditional types of engineering.

The first reason is the complexity of the systems. There are essentially extremely many interacting parts that cause all sorts of emergent phenomena. This is a field that we don't really know how to handle very well - good quantitative models of complex systems simply don't exist. We need more study of systems theory and chaos theory to build some form of predictive models on which in turn can base planning.

The second problem is a sort of 'freedom of thought' culture that sees coding as the vaguely mathematical expression of ideas. As there are a huge number of degrees of freedom most attempts to regulate it in practice have been abandoned. So instead of just the problem of describing a mathematical problem, you throw individual human preferences, thinking and biases into the equation.

Of course it can't continue that way forever and we need to move to a meta level of coding. We do have well-constructed systems, such as the software on-board an airplane - but they are laughably primitive (because you have to account for all possible states the software can get in to). And we have advanced software, but it is laughably unreliable.

Still, there is reason to be hopeful. We're not inventing the wheel every time any more (just the horse carriage and so on). Modern programming systems have extensive class libraries that are on average a more stable foundation than making a custom implementation from scratch every time.

Ultimately however we need to know how to handle complex systems and how to enforce convergence/stability to systems where the huge number of possible combination of states can be analyzed. And sad as it is, if we want it to be reliable, the liberal individual approach to coding has to be abandoned in favour of a much more strict industrial way of thinking. Right now we have handcraft and we need industrial precision, standardization and quality.

If it was easy (2, Insightful)

dantal (151318) | more than 7 years ago | (#17514024)

I would be out of a job ;)

Engineering and Education (1)

TrappedByMyself (861094) | more than 7 years ago | (#17514044)

What is the pedigree required to build a large bridge, a skyscraper, a rocket, or to perform brain surgery?
Right now software engineering is such a young field. Success isn't dependent so much on process and education as it is on the skill and intuition of individual developers. And there are a heck of alot of software developers out there with neither education nor skill
Software engineering is still becoming it's own thing. I mean, we still keep trying to compare building software to building buildings. We're still pounding things with rocks, but the difference between software and things in the past is that it's so easy to get something up quickly that is moderately useful.

We'll get there.

Part of the problem (1)

grasshoppa (657393) | more than 7 years ago | (#17514046)

Part of the problem is this; When asked if we ( software developers ) can do something, the answer is typically yes; Of course we can do something. Given enough time and money, we can write software to accomplish just about anything. The problem lies in that we may not have experience in that field, or we do but this request is different in a way to make it difficult.

Software development is a lot like engineering, only without the hundreds of years of experience to pull from. And it's a lot like janitorial work, only without the experience to draw from there as well. Managers, marketting ( and schools really ) like to see it like a burger to be flipped.

It's simple (4, Insightful)

ozzee (612196) | more than 7 years ago | (#17514050)

When you ask a carpenter "are you done ?", almost anyone can verify the answer just by looking at it.

When you ask a programmer "are you done ?", it is difficult to verify the answer.

There are so many ways to accomplish a goal in software that you need a number of very expensive controls in place to validate the result. Very few managers know how to do it and very few C*O's are willing to spend the money to put in place even the minimal control measures even though I can say in every case where ther were good controls put in place the benefits far outweighed the costs.

This leads to a plethora of problems that I won't repeat here but I know too well.

Eventually everything breaks down when the C*O's start making technical decisions that they are not qualified to make and it's all downhill from there.

Re:It's simple (1)

Tankko (911999) | more than 7 years ago | (#17514420)

>>When you ask a carpenter "are you done ?", almost anyone can verify the answer just by looking at it.

You've never had a house built, have you. :-)

Women make me hard. (1)

agent (7471) | more than 7 years ago | (#17514094)

This is off toppic. -1

Mommy, rocket science is too hard. (0)

Anonymous Coward | more than 7 years ago | (#17514120)

Complex subjects are... ummm... complex.

Every day there is more software created that makes creating new software easier. We're still in the toddler phases of computing. It will get better as computers get faster and have more storage. Even if you combined all the computing power in the world it's still pitifully slow in the grand scheme of things. Compare biological functions for example and the amount of computing power it takes to model even a single atom (and that's without even modeling the quantum state... and whatever is smaller than the quantum level...etc).

It's not that complicated... (3, Insightful)

Gunark (227527) | more than 7 years ago | (#17514180)

The answer to this question isn't complicated. Software development is hard because it requires that the developers impose an artificial abstraction on the real world -- a real world that could be conceptualized in an infinite number of ways.

Once you decide on some particular conceptualization, you make certain assumptions about what is and isn't possible. This is the root cause of most if not all of developers' headaches. Despite our best intentions, we find that our carefully engineered abstraction does not capture everything about the real world relevant to the given task (either because we got it wrong the first time, or because the task itself has changed).

This, in fact, is a deep problem in computation in general -- a huge obstacle in artificial intelligence, for example. We need an algorithm that can pick out the salient aspects of a problem and ignore the irrelevant ones. Until the day that we have this (and that day may never come) the hard part of software development will remain an art form based on intuition and creativity.

...because planning isn't doing and we want to do! (2, Insightful)

jofny (540291) | more than 7 years ago | (#17514188)

I see more projects go bad because of poor communication and lack of architectural efforts than anything else.
A sufficiently detailed question needs no answer. Likewise, with software development (and really most computer systems development), everyone wants to rush out and start coding as fast as possible...but if they'd made sure there were no assumptions, defined their problem specifically, and spent way more time than they wanted to developing an architecture, the coding afterwards would just be data entry for the most part.
But...people tend to be averse to taking the up-front costs of not only gathering their requirements, but also -understanding them- and making them -fit together-. Frameworks and Architectures tend to be poorly developed and understood ahead of time. Features are developed in isolation from each other. Test cases need to be developed at every step to keep people in agreement and to make find issues early. If your project isn't working in a manner where every new addition to it can't be tested as it's written, you're doing something wrong.
Requirements need to be reviewed and revised and reviewed and revised constantly with all staekholders against those test cases.
But...maybe I'm off base.

Who says it's hard? (1)

Animats (122034) | more than 7 years ago | (#17514194)

Software development isn't really very hard today. At least not at the level at which 90% of programmers work. The tools mostly work, many of the languages are quite forgiving, there are plenty of books, you can get help from Google, and much code can be downloaded. Yes, there are people doing hard stuff - real time control, database internals, game physics, stuff like that. But ordinary web programming is almost a no-brainer today. Look at the people doing it.

And if you need to do something hard, it's amazing how much one person can get done today. It's a great time to be a serious programmer.

There are design problems, yes. Microsoft's world is overly complex because they need it to be complex; if it were straightforward, nobody would need Microsoft. The Linux/Unix world is overly complicated because it has too much legacy dating back to the 1970s. The CSS world is overly complicated because the approach to page layout was botched. (Layout is a constraint problem, but isn't being approached as one.)

What we do have is too much tolerance for the mess at the bottom. What we need is, say, a "Just Say No to Bad Software" from Fortune 1000 CIOs. As in "We're not buying Vista until this list of problems is dealt with".

A few reasons (1)

scdeimos (632778) | more than 7 years ago | (#17514204)

Three reasons I see regularly that cause development not to be delivered "on time" and "on budget":

  • Specification - specifications given to developers are always incomplete. Something always gets left out, from subtle behaviours to business logic for whole subsystems.
  • Scheduling - although we're working on changing this, other people who have no hands-on development experience set the schedules. They either use some metric about lines-of-code-per-person-per-day that has no relevance in the real world, use a dart board, or just pull the figures out of their proverbial. (I'm thinking the last.)
  • Integration - Green Fields development is always easier. Extending old systems is always a pain in the proverbial due to the lack of accurate documentation. Even the perfect documentation becomes imperfect if it isn't kept up to date (or nobody knows where it is).
There's heaps more, but this is my top three.

No such process (1)

camperdave (969942) | more than 7 years ago | (#17514214)

I think that a big part of the reason that software development is difficult, is that people don't have, or don't follow a program development process. At what stage is the data definition and data flow analysis done? Before coding starts? After? Are there milestones in place, specific points at which progress is measured and design changes made? Are these planned for and documented? How is this program related to others? Is there code from other projects that can be re-used? What parts of this project can be re-used?

An old-timey programmer looks at this... (3, Insightful)

troll (4326) | more than 7 years ago | (#17514220)

We promise according to our hopes; we perform according to our fears.

Managers -- down to mid-level -- need to have dates, so the programmer gives the earliest possible date. The software goes out buggy, untested. More pressure on the programmer and management doesn't trust programmer estimates anymore.

Solution? None, with the current business model.

Short Answer (4, Interesting)

955301 (209856) | more than 7 years ago | (#17514228)

Software is still a Science and not an Engineering practice.

As long as the design can also be the implementor and estimates based on actual analysis are optional, Software will NEVER be an engineering study.

These aren't changing quickly for what I believe are a few reasons:

IEEE has not created a Professional Engineer - Software and noone really wants them to.
Companies don't like to be told they have to hire something that sounds expensive to build something they cannot see.
Companies will NEVER open their software to outside inspection the way construction companies must open their buildings because of the concept (flawed, I think) of Intellectual Property.

If a company had to have their software inspected by a Software P.E. before using it in production or selling it to end users - If Software P.E.'s had to adhere to standards which included concrete estimates and testing - If companies were not allowed to use anyone they could find that has seen a computer to write their software... commercial software development would be much further ahead.

Do I believe any of this should happen? No. Why? Because I want it to continue to fail. I do not believe software development should be put on a pedestal or only performed by "experts". I believe shoot from the hip software projects allow open source software projects to exist and to succeed in the market.

Open source works without accurate estimates because the contributors can flock to good projects and don't have to adhere to a labour budget. Company employees can't get wind of the cool software project and leave the crappy one's - corporate structure and budget's won't let them.

I don't believe companies with more than 120-150 people are stable - once they breach this range empire building occurs and massive uncontrollable monsters result. If a company truly needs more than 150 people it should split into two and partner on the project at hand. I believe this is a human condition - humans work best in tribes where they can personally know all of the members.

All of this might be completely and utterly wrong. But it's my hypothesis.

No one knows ahead of time what to write (1)

scottsk (781208) | more than 7 years ago | (#17514230)

What I've always seen in college classes and books on methodology is that there is some mythical "requirements" known in advance but in the real world I've never, ever seen any project which actually has known requirements and sticks to them over the project. I guess software development would be easy if that were the case. What usually happens is as the software is developed, requirements emerge and diverge and go amok during the time it takes to develop the software. Not true in other fields: When you've got a die or something you pour stuff into, you aren't going to change it after you make a few widgets. You're not going to port your die to Oracle after casting it for DB2. You're pretty much stuck, and if people don't like tail fins that year, you've got to start over from scratch. Software isn't like that, and any known methodology from engineering and science breaks down. The closest thing I've seen that works is some of the agile methods that say deliver as little as possible as soon as possible. But even that doesn't tell how to do it. What I have discovered is that the best way to meet changing requirements is to build applications with an object model that does the base functionality and a scripting language like Python to drive it. Then, as new requirements emerge, you can mold and shape the object model into new "applications" using the rapid-development scripting language. If the user wanted a desktop GUI and suddenly wants a web interface - if the user wanted a GUI but now wants it to run in batch - if the user wants something new no one thought of six months ago - whatever, the scripting language makes major changes much easier as long as they're not asking for big changes to the basic object model that does what the application does. (Or, you can add new stuff to the object model without breaking the working scripts.) Push the changeable stuff off into a scripting language that makes it really easy to change stuff, and write the guts of the app in your core language like Java or C++. I don't have a catch name for this approach, but it's worked remarkably well in practice.

The Truth (1)

carrier lost (222597) | more than 7 years ago | (#17514232)

What Makes Software Development So Hard?

It's all that goddamned thinking you have to do.


Because software design isn't construction (4, Insightful)

Todd Knarr (15451) | more than 7 years ago | (#17514246)

Software design and development is more akin to an architect designing a building rather than the more common analogy of building the building once it's designed. Except that software developers are often burdened with requirements that any architect who valued his license would reject. For example, management often dictates which parts are to be used (ie. "We're going to use MS SQL Server as the database engine."). What architect would design a skyscraper after having been ordered by the client to use pine 2x4s instead of steel beams, or design a 1-story residential house under the requirement that he use titanium box beams instead of 2x4s? And then there's what the article notes at the top of page 3: software requirements change right up to the day of release. When an architect goes to design a building, the requirements are fixed before he starts. Square footage, height, number of floors, number of people each floor has to accomodate, number of elevators, number of toilets needed on each floor, how high the ceiling of the lobby floor will be, all that's fixed in stone before any design work begins. Sometimes that requires back-and-forth between the client and the architect to get everything clear, but it all happens before major design work begins. No architect's going to design the foundations of a building until he knows exactly (or at least very very closely) how much mass is going to have to sit on those foundations and how much horizontal shear they're going to have to handle. If the client can't decide what he wants, the architect just goes "Fine, call me when you decide what you want.". And even when this kind of analysis is done, software requirements change constantly after design's started. See above, no architect's going to accept the client changing the number of floors or the square footage of floors without also agreeing to a complete redesign to accomodate the changes with all the delays and additional costs that requires. If the client didn't like it, the architect would just hand the client the work to date and tell him to have a nice day. And no there wouldn't be any refund of money, the architect's held up his part of the deal as best the client will let him.

And then there's another parallel: architecture is only half engineering, the other half is art. Every building is different, and it's accepted that the architect's going to have to have time to come up with the parts that aren't off-the-shelf standard. There isn't a single standard floor-plan for a single-family 3-bedroom house, there aren't any rules that can be mechanically applied to create a floor-plan, and it's accepted that the process of creating a floor-plan is more creative than anything else and people without the knack for it just aren't going to be very good at it. And that on the next single-family 3-bedroom house much of that work's going to have to be done over again because the new client doesn't want the same thing the previous client wanted.

changing requirements (1)

mrcubehead (693754) | more than 7 years ago | (#17514262)

Writing good software is hard because while the result is just a tool for a job, identifying the job can be very, very difficult. Sometimes it's like planning to create a square peg for a hole that may or may not be circular, and whose circumference might no longer be known in six to twelve months.

Evaluate at every stage (1)

digerati00 (847542) | more than 7 years ago | (#17514264)

Management should re-evaluate the project at every stage and choose 2 out of following 3 to make sure it gets done .... Quality , Time or Money.

For good Quality product to be delivered on Time - you need to make sure the Price is right!
For a good Quality product which Costs less - you need to make sure you have enough Time to develop it
For a Cheap and Quick product - you will have to compromise on Quality

Gap between computer science and person problems (3, Interesting)

lawpoop (604919) | more than 7 years ago | (#17514282)

I believe that these days there is a gap between the kinds of concepts that you learn in computer science, which are mathematical things, and the everyday social problems that people are trying to solve with computers. It was summed up nicely a few years ago in a criticism of open-source software someone on the internet -- someone was complaining that the developers of GNUcash were dealing with memory leaks. I think they were using c or c++, and the complainer was saying they should migrate to java or python or something. If you're trying to make a computer program to solve problems, it's a waste of time to be solving computer problems. You should be solving the pre-existing human problem.

Every tool has its own problems. One problem is accounting, or keeping track of money. With pen and paper, you can run out of ink or paper. Humans aren't good at adding numbers in their heads. With computers, you can completely erase all of your work with a few clicks of the mouse or keyboard. So there are ways that problems inherent in the tool can emerge, which take energy and attention away from solving the pre-existing problem.

Currently with computers we are trying to abstract problems such as banking and business into simple logic puzzles. I think that's too much of a simplification. I think we need to create a virtual world full of basic human-percieved concepts, such as time, weather, humans, animals, etc. and create programs by manipulating those basic ideas and objects.

An example is an ontological system like OpenCyc. An ontological system holds hundreds of thousands of logical assertions like "Animals eat Food" and "Paris is the Capital of France". Basically, an ontology system has some basic common sense. From all of these assertions, it can make logical conclusions. So, if well tell Cyc that Duke is a Dog, it can conclude that Duke has a tail and eats food. If we tell it that Duke lives in Paris, it knows that Duke lives in France.

Now imagine, instead of dealing with animals and where they live, it has a bunch of assertions about generally accepting accounting principles. One day, you might be able to just sit down and talk with an ontological system via email or IM, and say, "We got a check from client A for $575, another check for $440." and then the computer balances the books with all the other accounting principles it 'knows'.

Current programs seems to be exclusively a digital re-creation of paper-based forms and filing cabinets. It's a sheet of paper with a bunch of field:value pairs, and reports are the resulting logical operations you can do with all of that data. This is *basically* the relational database. I think we are hitting the limit of the field:value model of reality. I think there are other models, such as virtual realities like online worlds, knowledge systems like opencyc, etc.

Programmers are working exclusively at too low of a level. Yes, of course, we will always need to teach and understand basic boolean logic and computer science terms, but we need to start working at higher-level, human friendly concepts.

Why it's so difficult (2, Insightful)

BluedemonX (198949) | more than 7 years ago | (#17514290)

BLOAT - Look at J2EE and COM.

EGO - Noone will admit they don't know what they want, noone will admit that what they wrote thet were learning while they were coding it, etc.

GENERAL CLUELESSNESS: Figure out what you want and build it. In that order. "If I don't write down clear specifications I can't be held accountable if they're wrong" is the manager's mantra.

MAGIC BULLET THEORY: Technology X will solve all our problems! And our neighbour's problems (see first point)

HR ISSUES: Must have 10 years experience in .NET (posted a year after .NET was released), Must have experience in Java, J2EE, J2ME, J2SE, JAX, JNI, JWD, JQV, WWJD, SOA, SOL, SQL, SPL, APL, OBE, CBE, ... (see point one) and AN EXPERT IN ALL THE ABOVE.

Corollary to the above: don't hire someone with a clue who architects well and can translate the design into whatever language you want (or tell you why "object oriented" and "EJB" don't co-exist) find someone who either guesses the exact answer to your clever pointer question you thought was a cool hack, or find someone with tons of certifications and ultrageekery in the language du jour (the GOLDEN HAMMER antipattern)

My brain doesn't work that way. (0)

Anonymous Coward | more than 7 years ago | (#17514302)

I'm a sysadmin and not a coder. Scripts make sense. Do this, then this.

3D Matrix? Pointers? Sorry but those things confused the living hell out of me.

I took C++ in college. It was nice and fine. I understood it but after getting stuck on syntax, lost commas, single quotes and pathetic "Hello, world";. scripts it just lost ALL the magic.

My cousin does some high end 3D world modeling (and math) and he got turned onto it. That's why it is hard: our brains are wired differently.

Lack of a specification language! (3, Interesting)

vinn01 (178295) | more than 7 years ago | (#17514312)

Home builders have architectural plans. Machinist have blueprints. Electronic equipment builders have schematics.

Software engineers are stuck trying to figure out the incoherent ramblings of marketing/sales/business analysts/corporate executives/users and a host of others who have no means to specify what they are asking for.

Software specifications are uniformly deplorable.

You wanna know (1)

MrCopilot (871878) | more than 7 years ago | (#17514356)

What Makes Software Development So Hard?

two words: The DarkRoom

My Guess (0)

Anonymous Coward | more than 7 years ago | (#17514364)

  • Marketing
  • Software "engineers", the most difficult group of people to get to work as a unified team known to man.
  • Clueless managers
  • Software patents
  • Lawyers
  • Users never know what they want
  • lack of communication

Software has HYSTERICAL complexity. (4, Insightful)

Ungrounded Lightning (62228) | more than 7 years ago | (#17514366)

What makes software so hard? The enormous complexity of the software constructions.

Why is it so complex? Because it's so EASY to build it.

Example: Pre-computers, the moment-to-moment computations necessary to run an automobile engine were performed by mechanical devices, mainly the distributor and carburator. Every term in every computation was manufactured as a number of physical components, several of which are moving parts.

For instance: The RPM input to the spark advance was computed by two weights on pivots, with springs and stops, rotating a sleeve on a shaft. The shaft was driven by the camshft through a gear and the sleeve carried the cam driving the contact points or (in an electronic ignition) the starwheel that passed the sensor coil. Adding this computation (compared to no RMP spark advance) added five moving and four stationary parts, to be assembeled, and a test stand the volume of an office cube to test the result, and allow a worker to adjust the constants by bending the spring supports with a screwdiver.

In software this computation can be done by PART of ONE line of code. (In real engine controls it's actually done by more - mainly so the computation can be more complex and thus better approximate ideal running conditions.)

Software changed the game completely: When adding a piece of a compuation requires a moment of thought, a minute with a text editor, and issuing a compile command (plus whatever testing is necessary to convince yourself you got it right), rather than months of an engineer's and draftsman's time, manufacuture of dies, lab work to check the result, repeat through three layers of departments (to prove it can be done, to prove it can be done reliably, and to prove it can be manufactured affordablly), the amount of work and time to implement one bit of complexity reduced drastically.

The result was that the amount of complexity that can be afforded rose in proportion. Given that the proportion was hysterically large, the amount of complexity handled by each person became enormous.

Unfortunately, programming is NOT formulaic. Portions are - and as they are identified they are rendered into algorithms and software is written to perform them. The result is that the part people work on is ALWAYS the part that is "fuzzy" and difficult to formalize.

Programming consists of rendering a set of requirements into a correct specification for meeting the requirements. (The reset is automated.) This is not an easy task - and it gets more difficult with increasing complexity of function. Unfortunately, methodologies for performing it have remained in a catch-up game: The better the tools, the more complexity a worker can handle. The more he can handle, the more he is assigned.

To quote McClary's Third Law of Computer Technology: Software complexity expands to exceed the capability of any software development methodology.

Re:Software has HYSTERICAL complexity. (1)

Ungrounded Lightning (62228) | more than 7 years ago | (#17514444)

By the way: Though the example was process automation, the same applies to all fields of software application. The drastically lowered cost of creating a complex computation was enabling - allowing things to be done that were too complex, and thus too costly, to do by non-software-driven methods.

When the blueprint IS the product it's possible to do far more than when it's a first step in an expensive process.

A manager was asked how many programmers s/he had: (1)

troll (4326) | more than 7 years ago | (#17514382)

Oh, about 1/3 to 1/2.

Some people can, some people can't. Unfortunately they're all in the IT industry.

The automated development platforms that apparently make someone off the street into a programmer are at the base of a lot of bad code.

To turn it around.... (1)

GeorgeMcBay (106610) | more than 7 years ago | (#17514386)

What makes software development so hard?... What makes anyone think software development should be easy? It is simply an inherently difficult job that very few people are truly talented at, just as with any other inherently difficult job. All of these people who think software would be easy if people just followed process X,Y and Z would cause Fred Brooks to spin in his grave... if he were dead.

Fucking C (0, Flamebait)

SensitiveMale (155605) | more than 7 years ago | (#17514394)

IMO, Delphi is still the best and fastest option available.

First and formost : Management (1)

Shivetya (243324) | more than 7 years ago | (#17514446)

Management who is more concerned with the process than the product

Management who never met a feature they didn't have to have added

Management who sets rules for design lockdown but permits themselves exceptions

Management who never seems to discipline those who don't work but loads obligation upon obligation on those who do work

Management who is more concerned with initials on parking spaces, titles, and new furniture.

Explains our 3 year project currently in its 6th year with 3 more years scoped out !!!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>