Most software projects fail. But that doesn't mean yours has to. The first question you should ask is a deceptively simple one: how big is it? Steve McConnell explains in Software Estimation: Demystifying the Black Art:
I think the real problem lies in trying to convince people that the project already has failed. That it’s hard to maintain, doesn’t meet the functional requirements, and doesn’t make the end users life any easier.
But are those the only signs that a software project has failed? Is shipping something, ANYTHING ,the only real criteria that means anything?
I agree with the big three for sure, but I do think that an IDE (or lack thereof) can make a considerable impact on the day-to-day development. Consider writing C# code in Notepad versus Visual Studio. Yes, that might be an extreme example, but I’ve worked in environments where crappy editors become bumps in the road that slow down the daily work and increase the number of “stupid” error that are otherwise caught by the smart IDE editor. Color syntax highlighting, auto-formatting, things like refactoring method names, etc. Those things might be blips on the radar to some but having good tools makes the real “work” more efficient and less error-prone. I used vi, vim, gvim, nedit and SlickEdit when I did development for Unix and hands down SlickEdit won simply because I was able to let the smart editor clue me in on the stupid typos and such that I made. With Visual Studio, I save TONS of time being able to find references quickly, do some refactoring with a couple of clicks, build and see build errors within the editor, etc. Certainly having a great IDE isn’t going to save a project that lacks one or more of the other items mentioned, but having one certainly can save a company money, particularly if the programmers are making use of the features it offers.
Seems like keeping the customer (assuming a product is being built for a particular customer) in the loop during the development cycle would help to keep things on track better (provides an accountability ‘partner’ for the developers) and manages the customer’s expectations. Far better in my estimation that the customer understands the problems early and what is being done to address them. Otherwise, if they aren’t in the loop and I ship a buggy mess to them so that I can say I shipped it on time, they’re definitely going to be upset that I was dishonest with them by letting them believe that everything was good.omer wanted to here - that everything was good.
Scott, I think there’s a definite difference between shipping something and shipping something of quality…
Jeff,
One of the reasons I like Scrum and XP and other agile methods is that they turn a large project into many small ones (one month or less) and that allows stakeholders and team members to have a good chance of doing the important stuff successfully early on. That said, I also strongly agree that a good set of tools is critical. I’ve worked on projects where the tools got in the way (e.g. VSS, WebLogic) and on projects where the tools really helped (subversion, cruisecontrol). The difference even just in morale can be substantial! No wonder tools make such a big difference!
These three pillars play a large part in why i am curently leaving a company. With all the time I have spent making and updating spreadsheets on my progress… i coulda writen a stupid web UI with a sql express database that MADE spreadsheets for my boss. /rant
I sometimes think that because failed projects are the norm people say, ‘Why bother?’. I don’t want to make crappy software that people hate to use and say ‘Thank god we don’t use THAT anymore.’ after they throw it in the trashcan.
Thanks for your blog yo.
I think that today’s software tools and IDE environments are at least part of the problem. There are a myriad of ways to do something wrong, too many new features in reasonable amount of time. I mean, just look at the tutorials that exist for simple CRUD apps in .NET.
Too many other things must occupy the mind of a developer and crowd out the necessity for solid algorithms.
Another huge factor is that most companies do not have managers that manage the right things.
Jeff, great suggestions for building a foundation for success.
An important next step toward success is risk management. Identify and face the toughest technical challenges first. Progress will feel slower because most of the easy tasks won’t show progress, but completing the rough components is a better reality check for your anticipated schedule.
It’s important to remember that sometimes we can do everything right and still fail (to produce the deliverable on time). In those cases, the best we can do is quickly identify the we won’t be able to deliver in time. Manage expectations as soon as possible rather than dropping a bomb on the project sponsor in the 11th hour. Give the customer time to plan ahead and you might get the extra time you need to make the project a success.
Great post.
I think what this industry sorely needs is a return to the fundamentals, both at the coding level and the project management level. It’s as if the pressure a customer puts on a project manager makes them forget all about the simple things that lead to success. Little things, you know, like making trade-offs between time, features, resources and quality, instead of promising all the above in a highly compressed schedule.
Deadline Driven Development (DDD) seems to be in fashion these days. Work-life balance is the first casualty. Project quality goes, too. Then, perhaps your best people after that.
Estimates and plans go out the window. Overtime is required and don’t even think about not working on the weekends. lol.
There is hope. Folks like McConnell, who keep beating the drum over and over about how critical the fundamentals are, may have a ripple effect over a long period of time. It would also help if our high schools and colleges improved their courses in programming, comp sci and software engineering.
To answer the question posed - in all probability, yes your project will fail. People want everything, they want it cheap, they want it with high quality, and they want it all yesterday.
"So if the three most important factors determining the outcome of a software project are…
I disagree with 2 out of 3 of your items. Here’s my top 3:
Your resources - people, time, and money. If you have enough resources, you’ll succeed. If you don’t, you won’t.
Determining ahead of time if you have enough resources is hard though.
The three pillars is a great set of tools to promote. I think it is the kind of thing a lot of us know, but which hasn’t been formalized enough, yet, as something that makes the difference between good software and bad or non-existent software. It is nice to see the good parts of reality validated through a good article.
“Kind of software being developed” and “Personnel factors” are often out of the control of the developers and you have to work with what you have leaving only “Project size”.
The three pillars you have mentioned are tools. Sort of like carpenters arguing which hammer is the best, there may be slight differences between them but there are larger gains to be found elsewhere.
I can’t think of any instance of a past project that I have been involded in failing because we didn’t use one of the tools mentioned.
What has worked for us:
Client Buy-in:
Have the Use Cases been developed with the client?
Are actual end users of the software working with the Devs and not some management type?
Has the client prioritized them?
Has the client walked through them?
Has the client signed them off?
Has the client worked with Demos/Prototypes?
Is the client using vague/abstract terms or defining the project more in terms of what they don’t want instead of what they want?
Programming Development Standards
Have you created a glossary of terms? Does the word “Customer” mean the same thing to everyone on the team for example?
Is there a common naming strategy/convention used for the whole team?
Are there templates illustrating common operations such as function definitions/database access/error handling
Do the devs have access to common source code and utility functions used by each of the devs? Are they stored in a common area so your devs aren’t re-inventing the wheel (repeatedly)?
Do you have a standardized testing standard/strategy?
Iterative Development
Are you delivering iterations of the software regularly?
Walking through them with the client?
Here is where you manage the project size by developing the parts of the application needed the most first, and add functionality with each iteration.
If the client isn’t properly involved, the project is dead. If the customer isn’t reviewing the use cases and baselines the project is dead.
If the team isn’t speaking a common vocabulary the project is going to have a hard time integrating its work and probably end up dead. If there are no templates/standards developers can’t be easily moved in and out and the project will have a hard hard time being completed.
Test cases allow you to test the interfaces of the designed classes before actually coding them. If you can’t write a test case it’s a pretty good sign it’s a bad object. The ability to unit test all of the classes makes the software more resilient and easier to make large changes to the code base (I don’t consider unit testing a tool here, you can test in many ways, just having a tester follow numbered steps on paper for example)
Monolithic development allows the team to spend years not delivering anything and the project will end up dieing. Iterations force the developers to deliver regularly and allow you to gauge forward progress.
Over reliance on tools would be part of the recipe for failure from my past experience. They can help to create a Single Point Of Failure in the system and things can grind to a halt if something goes wrong. They may be overly complex and result in the devs working around them or just ignoring them.
Sorry for being so long …
“I suspect designing for the Web instead of around it is at least as important as language choice.”
I think both are important. The best framework would be the one that made both things well supported, by allowing for direct Web programming and indirect Web programming while sharing libraries/tools/practices at the same time. Unobtrusive JavaScript and obtrusive JavaScript are two sides of the same coin, but where’s such coin?
To answer the question posed by the title: Yes.
Hang on – I see four pillars in that picture…
unless it’s one of those three-D pictures where you cross your eyes… and then there’s only three of them… and they appear to be floating in space and suddenly… WOW! A Sailboat!
Thanks Jeff!
lb
p.s. Also, I can’t really reconcile “build system” as being up there in importance with the other items… maybe on some projects…
LB - I can reconcile it. Especially on projects with more than one developer. Consider the fact that with every developer you add to the team, you effectively add one new “build environment”. The “It Works on my machine” effect starts to take hold. The build environment handles that.
I’ve written about this before: http://haacked.com/archive/2004/08/26/creating-a-sane-build-process.aspx
I’m currently in the situation where the build and dev environment is a pain to use. I can’t get the unit tests to work on my machine because of the huge # of dependencies on things that only work on someone else’s machine. This has put a hamper on my productivity as I’m still learning a new and very large codebase and would like the confidence that the unit tests would provide me that I’m not breaking anything obvious.
When you have a smooth working build system, it really does speed up development.
Isn’t it better if the sales department tried to convince the costumer that doing a quick feasibility study before the real project starts?
That way, you and the costumer, can actually see if the project is possible too carry out before too much money and time is spent?
Recommended book for managers is: Peopleware by Tom DeMarco and Timothy Lister.
If you read that book, I believe that you have much better chances to succeed with your software projects.
I will say that build engineering is probably the most challenging
part of that trifecta
Not all projects require a sophisticated solution, but on those that do, I agree that it is definitely another programming task.
I’m not sure I agree with Bill de h’Ora’s 3 pillar theory though. There are more than 3 pillars, and in different projects different ones become more important. I’m sure many of us have seen insane methodologies bring down projects, for example, regardless of what tools were used.