95% of IT Projects Not Delivered On Time 654
An anonymous reader wrote " The Globe and Mail reports that 'A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.' The article goes on to discuss the reasons for this pervasive (perceived?) problem. The article mentions Info-Tech's reasons: unrealistic time frames, staff shortages, and poorly defined project scope. However, the article's author lays the blame with vendors."
Nah (Score:5, Insightful)
Actually, it really depends on who they would ask in a company. Whether it be
the business executive (probably a higher estimate)
the IT middle manager (lower estimate)
the IT worker (who would think that they are on time)
or the customer (who sometimes have unrealistic expectations)
Understanding your art (Score:5, Insightful)
Could it be that marketing is always overselling the product? Seriously. I cannot count how many times I have heard (in the past now I am in science), "oh, yeah....well, you need to include feature X because we told customer Y we already had that feature". This is often followed up by the engineer muttering under his/her breath "Dumb jock.
So, this is another example of why pre-announcing products is a baaaaad idea. Treat your customers with honesty and announce the product when it is ready and not before. Again, this is why vaporware only serves to irritate your customers and build expectation of a product that is not always delivered.
I also believe the fundamental problem is that managers these days (in many cases) no longer come from the ranks and are not engineers. So, they do not always understand what is involved in 1) building the codebase 2) testing code base 3) proper interface design 4) end user testing 5) documentation 6) making sure it does not suck.
The last point is where most executives seem to get hung up. More often than not in most companies, executives really have no idea of what makes good code and all too often, what makes a good product. Come on now, a good portion of executives can barely use their personal computers to answer email or browse the Internet. When you have companies run by executives and managers that have come up through the ranks, you are much more likely to get quality which often is much more important than meeting an arbitrary deadline.
This just in. (Score:5, Insightful)
Merge it. (Score:5, Insightful)
The answer to this problem is change, and isn't change always the answer?
Consider if you will for a brief moment the vast difference between the average executive and the average programmer. Programmers are generally broad-picture thinkers who solve largely complicated problems that regular folks can't possibly wrap their heads around. The executive runs on a schedule and uses reports and correspondance to understand what is going on, because business folks have to judge their employees and projects.
These two groups are forced to work together, and we expect good results? We need someone to interpret between these two groups! The HR department can't regularly serve in the interpretive capacity, but perhaps they should.
Managers generally don't want to give the programmers the whole picture, because management often believes that they are superior in rank to programmers, placing the programmers on a need-to-know-basis, only. Huge mistake.
What programmers and managers need to do is realisticly approach their solutions together. They need to be honest with each other. They need to share each other's thoughts and feelings about the subject matter. It's not happening today.
The programmers need to come to the table and care about their customers a little more. The managers need to come to the table and care about their programmers a little more. The customers need to be more specific and realistic about how far their dollar can go. Then deadlines will be met and promises kept and successful solutions provided to customers.
I encourage a no-holds-barred approach to project management. The superior product is developed using the Agile [agilemanifesto.org] method.
In other news (Score:5, Insightful)
Title is misleading... (Score:3, Insightful)
Re:Nah (Score:5, Insightful)
Managers just seem to cut it out of plans because clients don't like paying for it.
How does this compare to say... (Score:1, Insightful)
This is why (Score:5, Insightful)
Us: We can do that for $x in 12 months.
Customer: But Joe Bloggs says his company can do it for $x/2 in 3 weeks!
Us: That's simply not possible.
Customer: Well, for that sort of savings we're going to give them a try.
11 months later and $x^2 later they're still waiting for Bloggs to finish but by then we're on the dole and Bloggs is laughing all the way to the bank.
TWW
If an IT department never, ever is late... (Score:5, Insightful)
Adding requirements (Score:5, Insightful)
Sometimes some of the new requirements or wants involve going back and rewriting a good chunk of code, or changing the DB design, etc, no matter how carefully you wrote your code and flexible the code may be.
Methodologies and the lack of it (Score:5, Insightful)
Second of all, rather than delving in to the varied array of processes and methodologies prevalent in the software development arena and reviewing advantages and disadvantages of each, the report goes in lenght talking about Vendor issues. I dont have a clue why.
Right from the Waterfall approach, or having no approach as well, we have RUP, XP and a mix of each playing itself out for the last few years. In my past projects, I have implemented each or a customized version of each and has varying levels of success. The biggest issue that I have so far seen is the lack of adequate knowledge in each methodology that someone who starts implementing any approach, either loses interest and resorts to a quick fix at which point the process starts to wither and die. More over, to some of the developers I have worked with, its not process, its documentation. CRC Cards is not a design tool, its documentation, its impediment to writing code. Much of it has to do with no academic background in best design or coding practices. They have heard of design patterns, and probably has used MVC to death, but when it comes to designing a system, its back to "lets start writing code rightaway and maybe the design will flesh out over time". The system gets built, but it suffers from Simplicity, it has very low quality.
I have seen a lot of firms talk about having a process, they love throwing RUP in the air, but nary a project which has successfully or much less adequately implemented any sort of process. They talk about Use Cases/ User Stories, but when the project gets kickstarted, they resort to SRS documents or less. And then they forget to adequately keep them up to date. Many even have Requirements management tools like Requisite Pro which hasnt seen daylight yet. Fuck the tools, atleast have a damn process. Many dont even define success at the outset of a project, no acceptance criteria either. They end up in a deathly downward spiral towards absolute failure dragging their clients with it.
I love XP, I love it for several reasons. Having a Client involved during all phases of the project, much less have a day to day interaction with the team is a phenomenal idea. I have had great success with this, but it becomes a bit of a problem, when the project is outsourced. No amount of communication (documents/mail/phone) can stand up to having a person next to you to tell you whats important and whats not. I love pair programming even though I could never fully implement it, when the client doesnt believe in it. I have tried pair design and have had great success. I have a few developers reviewing Test First Design and this has limited success as well. Limited, since the developers rebel, having low discipline and patience to write tests as they code. They are tutored and trained in the ways of "lets code first, maybe manually test it later and let the QA worry about it".
I would like to hear about other's experiences as well.
or (Score:5, Insightful)
Re:I remember on my first web dev (Score:5, Insightful)
In a nutshell, the instructor said that the requirements, then the specs, then design,
The guy next to me who was a PM just shook his head and said, "No, the end date comes first and then we figure out how to get it done." I have had the same experience in my decade+ of experience.
The instructor said that's why most projects fail.
Re:Nah (Score:4, Insightful)
Re:Merge it. (Score:5, Insightful)
Please...
I know it's Slashdot I'm reading, but I didn't know readers had that high thoughts about themselves.
Re:This just in. Project Bloat (Score:3, Insightful)
I suppose this was modded Funny because it is true. I have not seen a project yet that hasn't resulted from project bloat. As the project progresses new deliverables are tacked onto the end. One can try and have the project plan set in stone at the beginning, but it never works because all the new stuff is "critical to the business".
So how can any project meet it's deadline under these circumstances? (that was rhetorical. no need to actually answer)
"SOME number" -- Useless statistic (Score:3, Insightful)
"95% are not delivering some number of projects on time or to the full satisfaction of the business executive."
This could means that 99% of the projects attempted were delivered on time by all IT groups which is a more, or it could mean 99% of the projects were delivered late. By using the phrase "some number" this statistic is utterly general, and wholely useless.
Oddly enough, later in the same report they state "the majority of IT projects are in fact delivered on time" which really what counts.
The fact that IT groups do not deliver on time 100% of the time should be no surprise. The fact is that there simply aren't any professions which bat 100.
Botton line, stat is completely pointless.
Rich...
Re:Understanding your art (Score:3, Insightful)
There is always a market for well engineered products that are designed and built with passion. These companies may not necessarily be McDonalds, but they can certainly be companies like Apple Computer, Porsche, Canon, Oakley, etc...etc...etc....
Not surprising. (Score:2, Insightful)
Manager: When can you have X finished.
Programmer: I need two weeks to do what the client asked.
Manager: I told them you were almost finished can you have it by Monday?
Programmer: I didn't start until yesterday I need two weeks.
Manager: Ok the client is expecting it to be ready Monday you'll have to work the weekend.
Programmer: I was planning to work over the weekends to get it finished it two weeks.
Manager: (Clearly Frustrated) I need it Monday. The client will have to punchlist what does not work.
The above exchange is very close to what was actually said. If this was the first company where I had heard that conversation I'd be bolting. Unfortunately no matter where I would run there would be a manger and programmer having the same conversation.
The Three Failures of Engineering (Score:5, Insightful)
- Failure to Understand Business Need
- Trying to Solve Training/Documentation Issues via Engineering
- Scope/Requirements Creep
Join me next week as I discuss the problem with dumbing down your architecture so that you can hire morons for less money to maintain it when all your best talent gets fed up with their 2% raises and quits.Its a management problem... (Score:2, Insightful)
Sorry if I sound cruel or mean to managers, but I've seen it over and over and over again. Managers are far too often people who:
a. Have never written software
b. Were bad software engineers, so they got promoted to management.
Re:Understanding your art (Score:5, Insightful)
- you hit the nail right on the head!
I'm working on a project right now (software is installing as I type this) where I'm supposed to migrate an existing web server to a new datacenter accross the country.
The PM's take on the whole thing was "All you have to do is:"
- Load the software on the new server.
- transfer the data
- ship the server to the new location
- have the server racked and powered up
I could tell he though I was just being difficult when I told him:
- While we're at it we should upgrade the app that's running on it since it's no longer supported.
- If we upgrade the server will be running a different web server and therefore will need a new ssl cert.
- Get the network guys engaged so they can punch what ever holes are needed in the firewall.
- We'll need to do some level of testing.
- Notify the end users that the look-n-feel will change/new applets will be downloaded, etc.
And now, as far as upper management is concerned, I'm the one that is behind schedule...
www.dilbert.com (Score:3, Insightful)
But what about non-IT projects? (Score:5, Insightful)
Let's see... Boston's Big Dig. Nope. Designing a new aircraft carrier... nope. Red Sox winning the World Series... badly delayed
I wonder if in general it's creative projects or maybe highly complex projects that suffer lousy under-estimates for completion dates. Many software projects (i.e., MS Longhorn) are both.
On an unrelated note: I wonder how project planning estimate accuracy correlates with the experience level of the person making the estimate. Because if the IT industry tends to burn out the young people os that there are't many older IT people, that could contribute as well.
Re:Nah (Score:5, Insightful)
Re:Nah (Score:4, Insightful)
Re:Understanding your art (Score:5, Insightful)
The utility program mentioned supported one of our products and was for inhouse use only. It had been whipped up quickly in the devs spare time, had no documentation, no time spent on QA, was not an official product of the company, and had a completely unfriendly UI because the dev had developed it piecemeal for his own use. Needless to say once it had been *sold* to a customer as a feature that attracted their interest enough to purchase our product, it became an official product and was quickly rewritten to be more presentable, but that developer told me he would *never* mention anything to a sales guy again because they couldn't be trusted.
I have seen sales people sell a product based on a feature that they assured the customer the product offered, then once the phone call was done and the sale completed, checked with Tech Support to see if it actually did offer the feature they sold it based on.
Re:or (Score:3, Insightful)
Re:Understanding your art (Score:3, Insightful)
Don't get me wrong: I'm a developer, not an MBA-type. But I've run across primadonna coders that get so hung up on thinking of their coding as a form of aestheticly-oriented art, that left unchecked they'd bankrupt the company or totally miss the market window for the requested feature.
I also see this in computer science research, which is truly the land of cheap hacking. In truth, a huge fraction of code produced for research is genuinely throw-away. Overly purist coders can cause c.s. research to get done at 1/10 the rate it could otherwise be completed at.
Immature Industry (Score:3, Insightful)
Outsiders (the clients upper management) will apply time measurements to IT projects as if they are building bridges or building cars. These are unrealistic because both those industries have been around for 50+ years. The IT industry is immature and still growing. Just think how many languages you have to know just to do your job? Or how many versions of compilers, or how many changes in OS, dll, registry, configs,
Come on, until there is standadization in tasks (what the client wants to do), interfaces (how the client wants to do it) and tools (how we make it so), all IT projects will be optimistically scheduled and all projects will be under time pressure from the beginning.
I won't even start on budgeting of projects...
Ok, I'm down off the soap box.
Er, uh, impertinent question (Score:1, Insightful)
And this is a problem because...?
As a developer, most of the time I couldn't give two craps in a tin can about what Darth Veep thinks. He is, after all, a rep from the Dark Side.
On the other hand, meeting the design goals, generating maintainable code, facilitating the QA process--those are important.
Writing software on a delivery schedule promulgated on the premise that "we need this revenue in Q2!" is short-sighted bordering on the moronic, and a great way to guarantee failure across the board.
Re:Correction: 95% of Schedules are Wrong (Score:3, Insightful)
I spent most of last year on a project like this. I personally spent almost 3200 hours on the project, and I know the rest of the staff was working 50-60 hour weeks the entire time. We managed to bring the project to a successful completion on time, but our Manager and his Director were both gone (to the same other part of the company) before the project was due to be delivered. The result of this was that we spent as much money as planning a much more reasonable schedule, but were specifically directed to take short cuts to create a barely workable solution that would create more work in the future.
In the end, a lot of projects either fail or are minimally usable as a result of poor management decisions. The irony is that the decisions are made in the name of saving money, yet the projects cost as much or more than if a more reasonable approach were taken.
Re:Nah (Score:3, Insightful)
But Jobs would've scrapped the whole project if capacity was projected at 18. He'd have demanded more.
How many times have you seen a realistic bid lose out to a lower budget, quicker timeline bid that ends up late and over budget, often worse than the bid you had to pass on (but that was realistic from the get-go. In a bid situation, you're often times rewarded for your empty promises with an accepted bid.
Doesn't make it right. It just explains it.
Re:Correction: 95% of Schedules are Wrong (Score:3, Insightful)
There have been many attempts to improve estimates by profiling code... a current one in vogue is called TSP - Team Software Process. These methodologies tend to be very top-heavy with record keeping, and assume that people work in ways that they really don't. For example, you don't think about only the UI for 11 minutes and then only the middle tier for the next 13 minutes. But that's the way you have to log your time. So your history data tends to be very approximate. On top of that you always have to factor in what fraction of time a developer is actually going to be doing productive work, which can be anything. Where I work we use 50%. So in the end after doing all that bookkeeping, you end up with a schedule based on making your best estimate and doubling it, which is how a lot of people who have no methodology do it anyway.
Re:Understanding your art (Score:3, Insightful)
Ok, so that said, here is why it happens: IT departments in most large companies are operating in a grey area between development and infrastructure administration. When you ask someone to make sure the bathroom works tomorrow, they usually make the deadline because there is a known path between where you are (broken bathroom) and where you want to be (working bathroom). When you ask someone to build you a new building with a fancy new biohazard containment system that the CDC just approved, you are assured that many issues that arrise will not have been encountered before by the people involved, and therefore will not be part of your timeline.
It's all about the number of unknown variables involved in the plan, and gets really sticky when the number of unknowns is, itself, unknown.
Even being conservative in the face of such developments, you may, more often than not, discover that you were wrong or that you're not satisfied with the result. Welcome to being a developer. We live with this our entire career, and it pisses US off too.
Re:Understanding your art (Score:1, Insightful)
This is a free-market capitalist society: customers tend to have what they are wanting to pay for, the way they are wanting to pay for.
I am *tired* of observing the following scenario:
Client A wants "solution a" to be developed.
* Vendor X offers obviously overoptimistic price and timeframe
* Vendor Y offers realistic price and timeframe (higher price tag and longer time-to-ship).
Client A contracts with Vendor X.
"Solution a" finally costs even more than offered by Vendor Y, ships later than offered by Vendor Y and it is clearly subfunctional.
Now Client A wants to develop "solution b" (or even resolve the shortcuts of "solution a").
Again Vendor X offers overoptimistic time and price and Vendor Y offers realistic time and price.
Client A contracts with Vendor X AGAIN!!!
What do you really expect Vendor Y to do?
Obviously this happens with boxed software too: eyecandy functionally bloated software sells better than serious to-the-task software, so what do you think vendors should do?
"I also believe the fundamental problem is that managers these days (in many cases) no longer come from the ranks and are not engineers."
Right to the bull-eye. Much to Microsoft credit, vendors discovered that you would be more succesful if you try to sell to the one who is going to sign the bills instead of trying to sell to the one which is to use the software on one hand, and to avoid going to the ones that really can separate good products from eyecandy rubish so they can peruse marketing more productively on the other.
Once PHBs "discovered" they could avoid depending on those nasty guys that always have the right answer and made them look as the assholes they are (technically speaking) by going with those vendors that speak their language, they went more and more with it. There's a Spanish say: "ojos que no ven, corazón que no siente" (more or less, "if you are blind, you don't miss what you don't see") so there's kind of a feedback: since PHBs are not technically inclined they don't know the assholes they are making themselves by taking over themselves the technical decitions and, at the same time, it seems to themselves they are in control (and "control" is a drug for PHB-like characters) and they can always blame "the lower ranks" when shit reaches the fan (since that pretty brochure says "its doable", it's not my fault this project has become shit, its our technicians' incompetence. And since technicians are so incompetent next project we'll hire even cheaper technicians -pretty brochure from Vendor A says their software is so complete and easy even monkeys can use it, so it must be true, so our excel spreadsheets show how good a manager I am cutting costs... as a side effect part of these savings will revert to my salary, so important *I* am to the company and so disposable are our monkey-technicians).
I seem to remember an article by Philip Greenspoon about how PHBs didn't like (probably in some subconscient level) those breed of technicians that did the big systems of the 70's; projects resolved by short groups of people with wages sometimes even bigger than those of their bosses (I'm talking about big-iron banking solutions, air-traffic control systems, etc.). By the next generation, PHBs managed to change the trend: instead of a group of, say, ten talented ingeneers, I will lead the project with my MBA, and I will hire 100 monkeys at almost minimal wages. The project as a whole maybe may id plain bullshit, buggy, overpriced and never to be delivered, but *I* will show them who is really in control (that's all about being a Boss TM).
7) (Score:3, Insightful)
7) enter the market too late.
I have never worked in a company (only academic... sweet...), but can imagine 7) is why 1) to 6) are neglected.
Re:But what about non-IT projects? (Score:2, Insightful)
Here's why:
Imagine doing a civil engineering project where advances in material science are accelerated 1000x faster than they are today; where geological changes to the landscape are accelerated to 10 million times faster than they are today. It becomes a lot harder to build that bridge when the landscape you're building on and the materials you're building with are constantly changing.
That's what it's like with any large-scale IT project - the business needs and the tools you're building with are constantly changing.
Re:Nah (Score:5, Insightful)
Non IT people just don't understand why code isn't written correctly the first time.
Re:misleading headline (Score:5, Insightful)
Re:Methodologies and the lack of it (Score:3, Insightful)
The first methodology that should be looked at is the scope of work. If you're building a house and the customer wants a change from the original plan, then the customer is responsible for any additional costs and delays. (But at least there IS a plan!) Too often, in my experience (and I will have been a programmer for 40 years in July), people don't take the time to actually build a plan for the project. My best argument for UML is the possible careful analysis UP FRONT, especially Use Case documents. Use case analysis solidifies the customer's expectations. And the salesman should NEVER decide the scope of work or the time involved.
Salesman (goes up to IT Manager): "Hey, Bob, if we were to take on a project for receiving inventory using RFID tags how long do you think it would take?"
IT Manager (offhand while concentrating on latest emergency): Oh, I don't know. It depends on a lot of variables. Sounds like a 3- to 6-month project to me. Get me some details".
Salesman (to customer): "Our IT Manager says we can probably do it in 3 months, 6 months, tops."
The other thing I'm moving toward is "Critical Chain" vs "Critical Path" project management. How many times is a programmer diverted from a project to work on a more urgent task since his current project "isn't due for some time, yet"? Wasting the slack time in a project is more inimical to the project than using the slack, because once time is gone, it's gone. Programming projects tend to waste the time saved when a milestone is reached early.
Lastly, the headline is misleading: "95% of projects deliverd late" is semantically different from, "95% of IT companies deliver some projects late."
Re:Understanding your art (Score:2, Insightful)
- From a marketing viewpoint:
There's a simple solution to all this - find the 5% that are delivering on time and SHOOT THEM. This results in uniform expectations all around
- From a coder's viewpoint: There's a simple solution to all this - find the MARKETERS and SHOOT THEM.
- From tech supports' viewpoint:
There's a simple solution to all this - find the IDIOTS^WCUSTOMERS and SHOOT THEM. This results in less feature bloat and overselling
From the customer's viewpoint: ... "Hello, 911 - I've just shot and killed a computer vendor ... oh, I'm eligible for an anti-terrorist award now? How nice. Thank you."
Reboot!
Reboot!F$cking computer!
Reboot!F$cking software vendors
Reboot!F$cking suppliers
Reboot!@%$@$ piece of shit
Reboot!I_NEED_A_NEW_COMPUTER
Sales rep: I'll take your order
Customer: BLAM! BLAM!
Re:Nah (Score:2, Insightful)
In actuality, the article quotes differently: " Info-Tech Research Group says 95 per cent of information technology _groups_ are not delivering _some_number_ of projects on time".
This "some number" could easily be disproportionate to the number of projects that are available, according to Info-Tech's original wording.
The facts, according to Info-Tech's study as quoted in the article, nearly every IT group, sooner or later, has difficulty releasing a project. Whether or not the problem is "95% of all projects" is not discussed by Info-Tech, as quoted.
This is hardly unsurprising, and barely qualifies as news since such difficulties are inevitable for any company.
Kris Kerwin
kkerwin@insi__REMOVE_ME__ghtbb.com
Re:Understanding your art (Score:4, Insightful)
Usually, it's because the board of directors has written a clause into a CEO contract that says that if he hits certain numbers, then it triggers a stock grant or a bonus. So of course, he's pushing for it. The board has the shareholders wanting big returns so they are pushing too - the board members have a financial stake in the company too of course. And then you have the analysts who give everyone in charge an incentive to say that growth is going to be high so that they can offer a "buy" rating. But none of these people actually have to do any of the sales calls. Nor do they have to build the product.
So from the developers point of view, it's the salesperson being a pain in the ass. But I think the problem is really that people in charge have the wrong incentives and don't have the balls to say "hey, those numbers are unrealistic."
Unrealistic management pressure (Score:3, Insightful)
- I scope a project
- I pitch it to mngmt
- Their response -always- is "be quicker"
- My response is, quicker means either: less qualiity, or more money, ypou pick.
- They say, you get neither.
- Ill say, sigh, Ill -try-
- It gets delivered on my original timescale
- They fuss about the project being "too late"
Do what -smart- project managers do: overestimate everything.
Re:Adding requirements (Score:3, Insightful)
"Customers don't know what they want to begin with. So just build something, and they'll tell you how to fix it."
This works very well here, especially since we're not afraid to tell them that each fix costs $$$
Re:In my experience (Score:4, Insightful)
1: Budgetary Quote.
2: Requirement Gathering (We assist)
3: Outline Specification (Huge number of meetings prior to this point).
4: 50% Non-refundable deposit.
5: Detailed system bible.
6: Changes to system bible (Chargeable).
7: Develop / Change / Rinse Repeat.
8: Finish Project (Final 50%)
9: Support
We have agreed to refund one deposit in the last two years (We screwed up their requirement gathering). We have had two clients pull out and lose their deposits. Everyone else has been happy, and through good communication hasn't had a problem when we have charged them for modifications to the system bible half way through the project.
Of course, the worst part of doing it this way is when some ass wastes weeks of your time and walks away with your outline spec (No doubt to give it to Joe Bloggs or use it in-house) having paid you nothing. It's probably worth noting that we don't always do the full specs if we don't trust the customer.
Oh, and one final bit of advice - GET TO THE TOP PERSON IN THE CHAIN! If someone is likely to override the decisions of the person you deal with in the company, start involving them. Even if it's just an email or a meeting to make sure they are happy with how things are going. Avoids some serious grief at the end of the project when you find you completely missed out on the features that the purse holder wanted!
The article says that 51%+ ARE on time (approx). (Score:4, Insightful)
So, 51% or more of the projects are delivered on time and on spec.
BUT if you've EVER missed a deadline or been off-spec, then you get counted as bad.
If you deliver 99 projects on time and on spec, but fail on 1 project, you're counted the same as if you failed on 100 projects.Right.... that tells me that the "answer" to this "problem" isn't technology. The "answer" is to have the IT managers take a few marketing classes and spread the bullshit to the "business executives".Again, all it takes is 1 failure to be lumped in that group. No matter how many successes you've had.
"So, you've solved world hunger, the arms race, poverty, racism, nationalism and have single handedly established a viable human colony on Mars. But we're really concerned about that jay-walking ticket from last year. Let's focus on what you can do to prevent such a failure in the future, okay?"
Re:Nah (Score:4, Insightful)
I think that's exactly the problem with software expectations. They always assume that building software is like building a house, or a bridge, or a toaster. In other words, they always assume that building software is done by experienced people who've built nearly identical software systems before. And, no matter how many times we stress and repeat this, we can't get it through their thick skulls - if it's been implemented in software even one time in the past, it doesn't need to be implemented again. By definition, every single software project ever undertaken is a brand new set of problems to figure out. The more experienced we are, the better we know what to avoid, in general, but if there are no unknown problems, the program doesn't need to be written. This is true by definition. Designing and implementing software is more like proving/solving a mathematical theorem than it is like building a house - I doubt mathemeticians often get paid to figure out how to prove the pythagorean theorem.
Re:Merge it. (Score:5, Insightful)
I call this the myth (or culture) of managerial superiority. It tends to go "I'm your boss, therefore I must be smarter than you are." It's one of the reasons that some managers come to resent technical people, whose jobs require that they be smart, and who are not usually reluctant to show those smarts. Maintaining a culture of managerial superiority is difficult when your subordinates often demonstrate that they know more than you do. Too often, the result is either denigration of the subordinates knowledge (You were hired for your expertise in X, but your manager keeps on overriding you on matters relating to X, leading you to wonder "Why did they hire me if they won't pay attention to the knowledge I was hired for?"), or denigration of the importance of subordinates knowledge.
The fact is, management requires a different set of abilities, not necessarily a superior set of abilities. Acknowledge that, and you've at least opened the door for each side to recognize the others talents and use them together.
Re:NO, it is the programmers. (Score:2, Insightful)
If by 'final ... time frame', you mean the actual delivery date, rather than the promised delivery date, then you are correct. But this is not just a software issue. Who decides what time your garbage gets picked-up? The garbage men. Who decides what time your pizza arrives? The Deliverator. Management is free to: 1) fire people who keep blowing management deadlines, 2) add resources or 3) do the work themselves to take up the slack. When it comes to programming, most management deadlines cannot be met by anybody, adding resources usually slows-down a project, and management couldn't code "Hello World" to save their lives.
As a result, they have absolutely zero recourse to the fact that software development takes time. They can start creating 'better' deadlines, or they can stick to the status quo and expect to blow their 'bad' deadlines.
Re:Unrealistic management pressure (Score:3, Insightful)
Re:Nah (Score:2, Insightful)
"How hard would it be to make this small change"
Re:The Three Failures of Engineering (Score:2, Insightful)
You may not realize it, but you've hit the nail on the head here. The biggest problem with SW Development is that too often the engineers do not understand the user perspective. It really doesn't matter what development methodology you use, if you use Use Cases or Agile Programming or whatnot - if the people writing the software don't understand their users' perspectives then all of the problems people've been mentioning will come up.
What is the biggest reason for "feature creep"/changing requirements?? Because the engineers built what they wanted, NOT what the customer wanted. Instead of trying to shoehorn a customer's usage of a tool into your idea as to how a tool should be implemented - and this is what pretty much all software is, a TOOL meant to help people perform some task easier, NOT an end in and of itself - understand what the customer wants to do with the tool, understand the customer's viewpoint (including such things as average level of technical expertise, currently-existing methodologies, etc.), understand the desired end result. And while Unit Testing is great from an Engineering perspective, USABILITY TESTING is at least as important to your end-user/customer. USE your tool the same way a customer would. If you were doing the customer's job, what sorts of things would you want to do? What would be the easiest way to do them?
Nearly every time I've seen a "bad" piece of software developed, it's been because the developers refuse to (or are incapable of) place themselves in the shoes of their customer. (And even for internal projects, you should think of your end-users as your customers, dammit.) And then when discussing things with their customers (or Management, who believe it or not oftentimes DOES understand your customers viewpoint, especially those creepy Marketing Droids), the Engineers responsible hold fast to their way of thinking and place the viewpoint of the SOFTWARE above the viewpoint of the CUSTOMER. Bad engineers, BAD!!
As a SW Engineer myself, I realize it's difficult to raise your head up out of the code you're working on, take a step back, and evaluate your tool from the perspective of a non-engineer. It is well worth the effort, however. Your customers will thank you for it, your management chain will reward you for it, and those peers whose opinion matters will respect you for it.
(And for the more obtuse among the Slashdot readership, yes, Feature Creep / Changing Requirements IS the primary reason most adequately-run projects are late. Nearly everything else is just fluff which can be scheduled around. Designing software which does not meet the ends of the end-users, however, should be considered a Mortal Sin.)
Re:misleading headline (Score:3, Insightful)
Why not have a headline "95% of IT employees will lose their jobs this year," based on an article showing that 95% of IT firms will terminate at least one employee this year.
While highly plausible, this 95% statistic is worthless, and the headline is not at all supported by the article. Actually knowing what percent of IT projects are late might be interesting.
Re:Understanding your art (Score:2, Insightful)
There is No Solution: Godel Incompleteness (Score:3, Insightful)
Programming is math. And math is hard. For starters, 99.9999% of all math is random and impossible to understand in the technical, math sense (proove) (extrapolation from Godel and Turing and Chaitin and Cantor...and yes, it really is 99.999....%).
When you sit out and design something to match a real-world process, you do fine. Then, you change something, you'll never know the impact of that change. You can't design for it in advance. A change of 1 character in the design could litterly require the entire code to be rewritten. You cannot prove how big your impact will be. Ever. That is why programmers get frustrated when customers change their mind "o but I just want it in this differnt order," "godamnit now i have rewrite half the loop..."
That is because good programming isn't just about being "smart", or about "planning"... most of the times, you are running against the fundamentals of understanding the algorithms in question, even with something as simple as lists or hashs or whatever.
The fact of the matter is is that programs are late because of bugs, and there are bugs because of the fundamentals limitations of math/the universe. You can't just smart them away cause you're some genius coder. All the genius coders write in their own designed language that best matches their thought processes and is easy to rewrite (i.e. they just gave up and went with LISP) with the assumption that they are going to rewrite most of the damn thing anyway at all stages of the game and the quicker they can rewrite it the better.
And that is why all these languages are getting closer and closer to LISP was 40 years ago...python, java, smalltalk, etc etc etc....automatic memory management and fast re-write cycle is the best way to write code for 100% of all projects (sans anything with 100,000+ intensive simultaneous users or an airplane code or something when you are bearing up against the engineering portion of things).
That's just my opinion. But I think it's fairly accurate. I've been programming from birth it feels like and I studied the math and I now I write for a large corporation where every schedule slips all the time and I have to deal interpreting customers and figuring out what they want and all I have say is:
There is no magic bullet and there NEVER WILL BE. Read Godel, Turing, Chaitin, etc. You'll be better for it. You're not going to fix your problems by using OSX instead of Windows or Oracle triggers instead of MySQL+PHP or Object Oriented instead of functional or procedural or XML web services instead of TCP/IP and binary. None of those things fucking matter, ok, fanbois? They're corporate games, that's it.
The best you're going to get is to find a language that fits how your brain thinks and that you can rewrite things in QUICKLY (i.e., don't even bother with the write-compile-link cycle... write it in LISP then have something covert the LISP to compiled code at some later day after you've profiled it)...
o, and a good text editor
and if management gives you shit, tell em to jump off a cliff. it's their only job to schedule, and if they aren't smart enough to schedule things with the understanding that schedules change for things that have nothing to do with how smart or good someone is as a programmer, they're worse than worthless anyway and you'd best find a new boss quick.
Re:Nah (Score:4, Insightful)
The wisdom of Scottie (Score:3, Insightful)
If there is a budget, if it will realistically cost 10 grand, say 15 and go "Look we have an extra 5k for you!"
Unfortunately in the business world, when you succeed in this fashion they expect you to work miracles next time under truly unrealistic conditions. Sucks.
Re:Nah (Score:2, Insightful)
... that don't work ...
Re:This is why (back when I was a contractor) (Score:1, Insightful)
Bridge not comparable to most business software (Score:5, Insightful)
Consider the construction of a house, or an addition to an existing domicile. Price is a significant factor, and the customer has many arbitrary constraints (call them "aesthetics"). In many cases the customer isn't sure what they want until they see what they don't want, which requires rework. There is no official certification process for most construction trades - only specialties like electrical wiring. So it is difficult to know how good a crew is until you work with them. Many (if not most) construction projects like this run over budget or over schedule.
I think writing business software is more like building a house. The constraints are unique and vague. The workers vary in their abilities. And the customers are cheap bastards. Projects in this environment have very little chance of coming in under budget and on time.