Is Your Development Project a Sinking Ship? 494
gManZboy writes "Everyone knows that some software development projects succeed and other fail -- the question has always been 'why'? I'm sure we all have our favorite (likely anecdotal) explanations. Well, these guys decided to actually go out there and do a formal survey, and they've got some real data on why projects actually fail (as reported by development project managers -- care to guess where 'changing requirements' ranks?). They've developed a diagnostic formula people can use to gauge the likeliness that the project they're working on right now is (or isn't) going to fail."
Change Transparency a.k.a. Big Visible Charts (Score:4, Informative)
Change is not bad. Adapting to environmental changes (competition, customer education by early prototypes, vendor roadmaps) can make the difference between a one-shot failed project and a multi-generation successful product.
Big Visible Charts [xprogramming.com] is a time-tested technique for non-political status reporting that helps everyone (from senior management to QA) take responsibility for the global impact of local changes. Grab a few unused monitors and create a wall-mounted status display with 1-minute project status updates, you'll be amazed at the results.
Over design (Score:3, Informative)
The resulting source is then needlessly complicated, and often when it comes to extending it, the original design gets in the way because it didn't pander to the particular change being made.
I'll RTFA in my next comment but first... (Score:4, Informative)
Re:I blame the If statements (Score:2, Informative)
The thinking (or so I was told) was that in the early days of this app, it was written to be temporary, so just hack something together and make it fast. Unfortunately - and this seemed to be the rule with this company, and I hear still is - the temporary system stuck around because it worked today, and a new system would wait until tomorrow. Or next week. Or whenever.
So every new conditional was another hacked modification, another IF or CASE.
My task was to rewrite this monster and figure out a way to get it away from IF/CASE nesting, but keep every ounce of "flexibility" and functionality. Just a temporary system, they said; we'll replace it with a fully designed system after another year or two of consultation sessions.
After pulling my hair out for several days on that one, I thought about an article I once read on how the Infocom guys did their games. Rather than trying to code for every possible situation, they coded for a single *default* situation - "when in doubt, do this", etc. Then everything else was an exception rather than a rule, and could be easily abstracted. I did something similar with this system and sliced the code base down to about a third of the previous system, without losing any functionality. It actually gained some, since now new functions could be thrown into a database rather than needing to be hardcoded into nested branches.
It took a little longer to develop than what they anticipated. Not much longer, a few weeks, but a little longer. And my supervisor kept complaining that the design was too "involved" for a system that was only temporary.
That was 1997. The thing's still running today.
Moral of the story: In any given situation, the odds of replacement (whether code, or a job, or even a spouse) is essentially a path-of-least-resistance formula. If it's easier to maintain the status quo than it is to upset it, the status quo will almost always be maintained. The more management tells you that the code is temporary, the more you should assume it'll end up permanent.
Also, it never hurts to learn how other developers solved similar problems.
Re:Please check my math (Score:2, Informative)
The $1 trillion is over many years.
Re:"Software Engineering" is not yet "Engineering" (Score:3, Informative)
Software Project Survival Guide (Score:3, Informative)
It's written by Steve C McConnell (who also wrote Rapid Development [amazon.com] and Writing Solid Code [amazon.com]) and well worth it for anybody doing project management.
keep a strong launch focus (Score:2, Informative)
Focus on launch from the start. Launch all the time, incrementally. Here's a few other nice pieces of advice [extremeprogramming.org]. Read it, and then, well forgetaboutit... just do it.
Re:So... (Score:3, Informative)
Re:Change Transparency a.k.a. Big Visible Charts (Score:3, Informative)
A SIMPLE status portal page in which you can see REALTIME successful and failed code builds, status of regression systems, resources and 1-click (tm) away usefull info towards the RELATED log files, code changes, problem reports, documentation,...;
While we have a huge corporate network with lots of fancy stuff, this project page came within a week the homepage of most people working on the project.
Why ? Managers, coders and testers get and realtime (max 3 min. delay) current progress, status and available resource info. NON-POLITICAL is important for motivation. Compare status reporting (GREEN lights: everyone should feel good, things are going smooth, RED lights: there's a problem, we need help) with pageranking ( following people are responsible for x-number of bugs, bugreports
If it's the fastest way to get the latest info both as a global overview as links to realtime logfiles of what went ok or wrong, that's what people will use.
How? No graphics, just keywords and a few colors show global status info with ALL details 1 click away. Don't post 3 line sentences to say something went wrong or ok. The key is simple, dynamic, and realtime usefull info. The content should be 99.999% automaticaly generated and updated. If most content has to rely on a webmaster it's mostly useless. Webmasters tend to take holidays or get too often other things to do with equal or higher priorities . In that case the page looses most of its interest since the 'realtime' factor disappears.