Successful Software Projects 301
Fixed Time and Budget
Building software is basically a prototyping effort. An application is always a prototype until a customer is willing to use it. In this weaker of budgets presented so far, affixing the time and budget means I will pay you x-dollars and allow x-months or years for you to get as far as you can with everything. At the end, we'd like to have something usable.
This sounds risky for the customer and it is, except the customer knows the amount of time and money when they are all in. If the caveat is that you will build as many of these high risk, high value features in this particular order first, the customer will get something useful when the time and money expire.
Doomed: Fixed Time, Money, and Features
Wealth, like happiness, is never attained when sought after directly. It comes as a by-product of providing a useful service.
Once you fix all three software variables, you are doomed to fail. It is absolutely impossible, even on trivial projects, to know for certain how long it takes to invent something new. It is impossible. Can't be done given today's technology. It is arrogance to say that it can be done. Software is so complex and there are so many variables that uncertainty is the only certainty.
I was at an MVP Summit and made my case against a fixed bid—money, time and, features—project that someone said I was a fatalist (or defeatist). That's incorrect. I am a realist. I have been in the trenches for 20 years all over the world, and our business is too new, too complex, and there is too much invention to know all the variables upfront with any degree of certainty.
I will grant you that there probably are some boutique shops that are routinely successful. There probably are some projects that have exceeded customer expectations, and we are getting better as an industry. But if we are honest, if we are honest... we will work within the constraints as they exist, make the best choices possible while improving deficiencies, and as a result improve as a community.
|If everyone is optimistic but the project isn't done to everyone's satisfaction, seek out the realists. The real status is probably closer to the expressed status of the minority than the overly optimistic view of the majority. Ignore a realist if the openly discussed facts can be disproven; adopt a blind posture of optimism at your peril.|
|My opinions are my own and do not reflect the opinion of my employer or this web site, nor am I asserting a universal claim about every individual, group, or company or any particular proprietary tool or technique of which I am unaware. Rather, the assertions made in this opinion article are based on my evaluation of the software industry as a whole.|
About the Author
Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Check out his upcoming book LINQ Unleashed for C# due in July 2008. Paul Kimmel is an Application Architect for EDS. You may contact him for technology questions at firstname.lastname@example.org.
If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org. Glugnet opened a users group branch in Flint, Michigan in August 2007. If you are interested in attending, check the www.glugnet.org web site for updates. Glugnet is hosting a Day of .NET on June 21st, 2008 at Lansing Community College.
Copyright © 2008 by Paul T. Kimmel. All rights Reserved.
Page 3 of 3