What Makes Software Development So Hard? 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."
good question (Score:2, Insightful)
Why is conducting an orchestra so hard?
It's complicated (Score:2, Insightful)
It's design not development (Score:5, Insightful)
One word: Skill, Talent and Knowledge (Score:5, Insightful)
Computer software is no different.
Don't treat it like a science. (Score:1, Insightful)
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.
People expect too much too soon. (Score:5, Insightful)
Two things make software "hard" (Score:5, Insightful)
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.
mandelbr0t
Re:good question (Score:5, Insightful)
Theory is great (Score:5, Insightful)
PHB? (Score:2, Insightful)
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.
Hard is better than impossible (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Re:It's not hard (Score:5, Insightful)
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 design not development (Score:5, Insightful)
The problem is:
If it was easy (Score:2, Insightful)
It's simple (Score:5, Insightful)
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.
Mod parent up! (Score:5, Insightful)
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.
Where software developers sell themselves short (Score:5, Insightful)
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.
It's not that complicated... (Score:4, Insightful)
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! (Score:2, Insightful)
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.
Re:It's design not development (Score:5, Insightful)
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
An old-timey programmer looks at this... (Score:3, Insightful)
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.
Because software design isn't construction (Score:5, Insightful)
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.
Why it's so difficult (Score:2, Insightful)
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
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)
Re:It's not hard (Score:5, Insightful)
Re:It's design not development (Score:3, Insightful)
Excuses like; and; 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 (Score:5, Insightful)
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.
Software has HYSTERICAL complexity. (Score:5, Insightful)
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:It's design not development (Score:5, Insightful)
Re:It's design not development (Score:4, Insightful)
Close, but not quite. software engineering is "I want it to do blassie. Make it do blassie by yesterday." Where 'blassie' is a loose concept and the developer has to determine and define the underlying logic.
-Rick
Re:good question (Score:3, Insightful)
On smaller projects my experience is that there are projects that I can count on going well, because I assign certain people to them. Other projects with double staffing does not do to job nearly as well, even when the task is half the size. This does not change (significantly) over time and is not related to education.
To answer the original question why software projects are so hard is that similarly to orchestra one bad player can ruin the show. Either that being the boss who has team meeting every hour, designer that doesn't know what is needed, customer that cannot give direction or software engineer that hides bugs in the code and causes several weeks of debugging for the team. Once the orchestra is filled with professionals I believe there is nothing inherently difficult with software engineering. Those projects happen, but it's rare.
Re:good question (Score:5, Insightful)
Conducting, however, is a lot harder than it looks, especially during rehearsal. It requires the simultaneous processing of the score (possibly twenty plus lines going on simultaneously), time (not so easy once you get into funky metric changes), expression (precisely what the conductor is all about) while keeping track of mistakes that happened during the piece even though not stopping immediately. It's extremely easy to see when a conductor is inexperienced, boring, or hasn't looked over their music properly.
For conductors of student groups, they also have to keep the members of the ensemble engaged through tasteful storytelling while not completely going off tangent, they must be extremely creative in figuring out how to get their point across, they must be careful not to over-rehearse a section, etc etc etc.
Ask any marching band student turned drum major. Being a good musician does not mean you'll be a good conductor, and a more generalized notion is the core meaning of most of the other analogies offered by Slashdotters around here.
Re:It's not hard (Score:5, Insightful)
In that case, you have essentially proven that you have no experience with large software projects. Even if everybody is qualified for the job they are hired to do, and are enthusiastic about the project, and doing the things they are supposed to do, things just don't work out right at first try. Or second try. Or third try. Or... you get the picture. And then, when that problem's finally done with, you have 7 new ones, where at least 3 of them are total show stoppers.
It's of course easy to start pointing fingers at people. That guy is an idiot. The management has no idea what we are doing. Writing documentation is killing my productivity. I had to rewrite this assholes code since he didn't follow my favourite bracing style. And so on... The point is, the guy you call an idiot probably knows three hundred times more than you about fluid dynamics, which is what all the project is about. Management isn't supposed to know what you are doing, they are supposed to handle budgets, equipment, hiring, firing, etc. And the last two are kind of obvious...
Software development is hard, because it's not a solved problem. You don't build software the same way you build buildings. There are no rigid rules to follow, no best practices that can be universally agreed upon. The purpose of each new software project is to solve (a) problem(s) that has never been solved before. And because of that, there are great uncertainties involved. You can guesstimate a lot of parameters, but eventually, some of the unknowns are going to bite you in the ass. (As Rumsfeld said: There are known knowns...)
Not exactly an easy person to work with, are you?
Development fails because developers are ignored (Score:5, Insightful)
But while stereotypes persist that programmers have no people skills, you forget that many business people don't either.
Just ask yourself: how many effective, people-oriented bosses have I ever had? If your answer is "not many", you're not alone.
I've been software engineering for over a decade. These are a few observations I'd like to share with managers:
Re:It's design not development (Score:4, Insightful)
There are lies, damned lies, and software specs.
Today's applications are like 1850s houses. (Score:3, Insightful)
I think this might be taking the art side a little far.
With a painting, the surface appearance is the end product. If it looks good, it is good.
This is distinctly not the case with software. Not only does the application (or whatever) have to look good on casual inspection, but have to be built to work well, including under conditions that might not have been thought of in the beginning.
I think architecture as a metaphor for software development is actually pretty good; architects have to combine artistic judgment and technical skill in order to produce a building that's both aesthetically appealing -- true works of art, in some cases -- but also structurally sound, designed according to accepted standards and principles. It's not enough, in most cases, to just have either one. Nobody wants an ugly building (well, most people don't), and nobody wants a building that's just a facade without substance.
Software "architecture" is where house-building was a few hundred years ago. When you wanted a house built, you just went and got a few people that you thought would be good at building houses, or had good reputations for building them, and told them what you wanted. They might or might not have any formal training, and the only 'standards' were what they knew from past experience would probably work.
I suspect that in a century or two, software will be not unlike house-building is today. While every house today is different, depending on the owner's requirements, there are a set of well-understood and basically accepted standards for putting them together. That doesn't mean that some builders aren't better than others, or that some don't cut corners, or that there's not room for artistry and physical beauty in the final product, but just that in theory, they all meet minimum standards for structural integrity and other key factors. In time, I think software design will probably follow. Every piece of custom software will be different, because they each solve different problems, but getting to that solution will involve a combination of creativity and the application of existing standards, built up from the accepted body of knowledge of what works and what doesn't.
Re:Mod parent up! (Score:5, Insightful)
Whereupon it turns out that they have exactly the wrong skill set to be managers and things get even worse.
I once saw a deep-thinking and productive coder promoted to management. The result was a catastrophe of Biblical proportions. In terms of morale alone, when employees got together to compare notes they found that they'd independently been thinking of where to take cover if the guy went postal.
Re:Lesson: (Score:2, Insightful)
You are wrong. ls does _one_ thing very well: it lists files; and it does a very good job at that IMO. The switches are not to increase the information stream, but are meant to decrease it (your milage may vary). The formatting is an important part (for compatibility) but the function is still to list files.
Although the options act visually as formatting, they are, in fact, filters. They filter the information in a very well defined way (well, most do
Looks like he doesn't know Knuth (Score:3, Insightful)
The idea is that if we're going to turn the creation of software into a true science, we need to first have principles. We need to know the fundamentals and formulas by which software behaves. What are the laws and principles we can count on in creating it?
I think Knuth has been working on that.
But in general, the reason software is hard is that the problem domain is hard. You can't solve anything without understanding the problem. This is why hiring code monkeys causes so many problems. THey may make nice GUIs and know how to build a web based wizard 'out of the box', but end up knowing nothing about the problem at hand.
Other observations:
1) He gets it write when he talks about things always changing. Part of the reason projects like Vista get delayed is that they take so long is that the requirements change. If you can't do it in 6-9 months, don't do it.
2) Nice to see him reference Brooks.
3) Another nice qoute:
The only real reason that a team gets together and writes a new piece of software is that they want to do something new, something another product doesn't do, whether it's to add a feature, or to be compatible in a different way with another system.
For years now I have said: "Software development is R&D". If the software has been built then use it. If you must do scratch development, then understand that it will be open ended; and all attempts to schedule, budget and predict will fail. It is *not* an industrial process, though we tend to treat it as such.
4) My observation is that much of 'Software Development' is actually social. You are working with users, managers, investors and programmers and trying to get everyone to agree on something. It gets political *fast*. So a good SD team must not only bee good at learning new problems domains and coding up solutions, but also must be good at human relationsships. And the closer the development team is to the end user, the easier this is.
The real point is... (Score:5, Insightful)
A good orchestra conductor who is in front of a bunch of rank beginner inexperienced musicians will not be able to make very good sounding music. You get what you pay for.
Re:Mod parent up! (Score:3, Insightful)
Or promote the concept of the title "Software Engineer" requiring a professional certification, the way real engineering does. Any slob off the street can't suddenly proclaim himself a "Professional Civil Engineer" and start building skyscrapers; why should he be allowed to proclaim himself a "Professional Software Engineer" and start coding medical databases?
Re:It's design not development (Score:4, Insightful)
The execution isn't simple, but the problem is pretty well defined. You don't generally get people asking for exit and entry lanes in the middle of a bridge, or asking it to accomodate aeroplanes, or asking you to build them out of styrofoam just because some magazine said styrofoam was the hottest new material. Or deciding that each piece of the bridge should have a special connector that requires new tools, or finding that your welders suddenly don't work when you choose a different brand of paint.
Software engineering generally sucks because it's surrounded by suckage all around. Programmers are trained and treated as wiz-kid hackers who can do everything ad hoc, projects and tools are designed that way, and it's no surprise that the products come out that way too.
When it's all said and done, it's probably harder to build a good large bridge than a good payroll program. The thing is, most bridges are eventually finished someday.
Re:good question (Score:5, Insightful)
Re:good question (Score:4, Insightful)
Simultaneous management of multiple requirements (possibly 5,000 competing business requirements competing simultaneously); time (not so easy when the scope of the project is creaping, but the deadline isn't, or the estimating process was off, or the requirements have changed.....) while keeping track of 1,000 action items, issues, defects and delivery dates at the same time. It's extremely easy to see when a Project Manager is inexperienced, or undertrained, or bored, or being overworked into an early grave!
For project Managers there is the ongoing need to maintain team cohesion, and team spirit, and still get the code out the door - tested and working perfectly, on time and under budget.
Like musicians, being a good programmer doesn't mean that you'll make a good Project Manager. Some of the best programmers out there would be dead in the water if put in charge of a real project, for no fault of their own, other than being totally unequipped to run a project.
As for delivering on time and on budget, it is a well known truism that the first 90% of the job takes 90% of the budget, and unless you are REALLY lucky, it's likely that the other 10% of the job will also take 90% of the budget....but I digress.
Captain obvious (Score:5, Insightful)
Re:Today's applications are like 1850s houses. (Score:3, Insightful)
Re:Mod parent up! (Score:2, Insightful)
This is one reason software development is hard. Most of us can figure out what a "balcksmish" is, but the compiler can't figure out that
if (x = 0)
Should be
if (x == 0)
Coding is inherently error prone. Even the very best programmers make stupid mistakes.Re:It's design not development (Score:2, Insightful)
I think you've mistaken "overdesigned software" for "engineered software". In my experience engineered software is cheaper than the usual mess, because there are fewer bugs and they are found earlier in the development process. Modularity is strictly enforced so the scope of bugs is smaller and unit testing is easier.
It is certainly possible to expend huge amounts on designing a thing to death, but given the howling screw-ups that NASA has produced over the years (was that metric or Imperial?) I wouldn't hold them up as anything like an exemplar of good software engineering practice.
Remember, engineering of all kinds is a matter of finding adequate approximations and compromises to meet specified performance criteria. It is not and never has been about making everything "perfect" by some impossible standard. Perfectionism is expensive. Engineering is cheap.
The real problem with software engineering is that the vast majority of people writing software today simply do not have the intellectual discipline to undertake it.
Re:good question (Score:3, Insightful)
This is why you should do the hard parts first.
Re:The real point is... (Score:5, Insightful)
The week before a concert is absolutely brutal, especially if you're rehearsing with a band/orchestra (but even if you're playing solo piano and rehearsing on your own). You're treated fairly well at other times (most importantly, after the performance), but you can sure feel like dirt during all of the rehearsals.
I guess it's like being treated with respect as a programmer, except that you still have deathmarches.
Your analogy is good, though - hire amateur musicians, and you're not going to get a good outcome. If the conductor knows next to nothing about music, you're not going to get a good outcome. If the instruments the orchestra is using are not tuned well, you're not going to get a good outcome. If you rehearse a piano part for weeks and the conductor suddenly asks you to play the oboe instead five minutes before the concert, you're not going to get a good outcome...
Re:good question (Score:2, Insightful)
"Who'd have thought that little bitty piece there would have caused so much trouble?"
Or, as a cartoon I have on the wall of my cubicle says: "We decided to save the total screw up part for the end".
I also once had an entirely approrpiate wall mounted cartoon that showed a really complex diagram of how the application was to work, with a gap in the middle, and the PM explaining the gap as
"Here, we're expecting a great leap of faith to fill in the missing detail."
It never does, of course.
Has anyone here not read Yourdan's "Death March"? If you have any interests in projects and why they fail, then get hold of this book for a good read.
Re:Mod parent up! (Score:5, Insightful)
Actually, this has been attempted repeatedly in the software business. It has always failed, for pretty much the same two reasons.
First, the only thing that the organizers (invariably software managers) can agree on is testing for knowledge of the mundane introductory-level details of IBM/Microsoft software. This means that in the more technical areas, where other (higher-quality) systems are used, there is no certification.
Second, even if the customer wants software that runs on IBM/Microsoft systems, they quickly realize that that "mundane introductory-level details" part can be rephrased as "It's a totally Mickey-Mouse certification", and the people who get certified tend to be the novices who think that a certification will get them the big bucks that their knowledge doesn't qualify them for.
So in software, "professional certification" always turns out to be a big joke. Everyone knows this, but pretends that a good certification program would help.
And no, I don't know how to make a non-joke certification program, either, despite several decades of building software. If I did, I certainly wouldn't be hired to take part in the committee that manages the certification program. (But I'm disqualified anyway, because I've worked too much on non-IBM, non-Microsoft systems to be considered for a position in a certification committee.
Re:good question (Score:3, Insightful)
True, but a better analogy in this situation is the customers of the orchestra -- ie, the listeners. This might be a concert hall, or the person who commissioned the piece to be played (perhaps more often in older history).
The conductor is still accountable if the piece doesn't sound like what the customer (audience) expects.