You can’t learn in school what the world is going to do next year.
According to the Merriam-Webster dictionary, arrogance is an attitude of superiority manifested in an overbearing manner or in presumptuous claims or assumptions.
To deem to tell the software community how to successfully build software could be construed as arrogant, except my manner is not overbearing. I simply offer this humble homily up to the reader, but you don’t have to read it. Contrarily, my claims are presumptuous. I think that many software projects are bungled, and I assume that they do not have to be. Consequently, one can accuse me of some little arrogance.
Worse than arrogance is indifference. That is, to write or say nothing is worse than being accused of being a know-it-all. By offering up this article, the reader is encouraged to participate in the discourse of why software projects and prognosticating seem so unreliable. Hence, you also may presume that you do not have to agree with me although in writing this you can deduce that I believe these things with a degree of certitude.
When everything seems to be going against you, remember that the airplane takes off against the wind, not with it.
Software projects are made up of time, money, and materials. That is, there is always some finite amount of time available; usually, too little. There is always a limited amount of money; again, too little. And, there is always a desire for features, and these unfortunately seldom are finite or fixed. Consequently, every project is constrained by time, money, and features to a varying degree.
Let me tackle each of these in turn. As a technologist, I am seldom in control of the purse strings and the customer will try to drive features too, so let me start with what every technologist will likely be able to mange best, time.
Every project is comprised of a finite amount of time. So Canon #1 is don’t waste any time on anything that is not a deliverable. Usually, this means spend all of your time on the software—the code, the queries, and the GUIs. If you need a process document to tell you how to do the job, you are on the wrong project.
Time usage is paramount. If you are having coding standards meetings, writing how-to guides, or project planning is consuming an inordinate amount of time, you are dooming your chances of success minute by minute.
However, by referring to time expenditures I am not saying don’t do analysis, modeling, or planning. I am saying do these things to the extent it makes sense. Modeling everything is useless; modeling hard stuff to leverage your coding time makes sense. Multi-thousand line project plans aren’t even read, let alone useful. Think of a project plan as a storyboard. In your project, plan carefully only co-ordinate chunks of resources that have limited availability or induce risky dependencies. And, finally, analysis is critical. The documents have to be detailed and thorough and you need buy-in or sign off, but unless the documents themselves are a deliverable, requirements documents can be informal, but they must be detailed.
To reiterate, Canon 1 is don’t waste time and the second part of that is that the primary deliverable should get an inordinately high amount of your time.
Canon #2 is to work on high risk, high value features first. The reason for this is that most of the technical problems hide in the high risk areas. Get these done and it’s like walking down the mountain after that. Doing high value items first means that as early as possible you are building those items that have value to the customer. About boxes don’t qualify and neither, really, do GUIs in general. The reason you must build value first is that time and money will always run out and the more real features you have first, the more likely it is that you will go into production at all. Dogmatically seek out risk and value and do mitigate those first, even if you get a little tunnel vision.
Very often, developers will do easy stuff like GUIs first to show progress. The customers are initially happy because GUIs are cool and everyone recognizes the visible stuff. Although this will make the customer happy at first, a GUI-first approach is wrong. GUI-centric development is the weakest form of development. Everyone should know that now. Database-centric development is the second weakest form of development. Everyone should know that, too. Building the objects first is the strongest form of development, but if you build the objects first, the customer will be a little edgy. Impatience for visible artifacts has to be managed, but building the objects first is the right way to go. Here’s why.
GUIs are the easiest thing to build and all those cool components invite incessant tinkering: Move that button, change that color, re-label that textbox. Anyone can do this work and usually anyone does. The problem is that the GUI does not solve the business problem. GUIs are just pretty. Databases are also the wrong place to start. Database technology is very established, and if you build databases first, every object looks like a table and every screen looks like a grid. There are more objects in software than visual components and tables (entities). Boundary, helper, controller, and entity classes are needed. The most important thing to tackle is the code that solves the problem and this is almost never what’s in the database or the GUIs.
Almost everyone has heard of the 80-20 rule. The basic rule is 20% of the problem takes 80% of the time. If you spend your time on GUIs or databases first, you are doing the easy 80% of the problem, but when that’s done the customer will see what looks like a working application, but be unaware that 80% of the time is needed to get over the finish line. The second problem here is that sometimes committing to a GUI or database too soon starts to paint in the corners and may commit you to something that makes the hard stuff even harder. Canon #2 is an admonition to work on the intractable problems first.
|If you hear “we are 80% done” and there are a lot of pretty GUIs, be very wary. This usually means that the project has 80% of the work remaining and it’s all hard. A real 80% done means that 80% of the business capabilities are in place front to back bar none, including the GUIs, database, business rules, and supporting infrastructure.|
Your customers will always think they need features. Like children and cotton candy at the circus, distinguish needs from wants. Unfortunately, your customer knows what the real needs and wants are, but they may not always know that they know the difference. It will require expert communication skills to get them to the point where they know what is needed versus what is wanted.
Canon #2 is assertively mitigate scope creep by starting with the premise that the answer to every change request is no! You can enforce this by offloading change requests to a board chaired by your project’s sponsor. The sponsor really wants the software and knows why it’s valuable, so they will carefully help you avoid risk and veto low-value drivel.
You can’t manage the money. As a technologist, someone else holds the purse strings. You can ask for more, but you may not get it. You can try to spend less, but most projects go over budget. The best thing you can do as a technologist is to build the high value stuff first, so if you need more money the customer is committed and you are more likely to get it.
Canon #3 is make them love the product as soon as possible so you will get more money when you need it, and you will need it.
Avoiding Risk Factors
Any colour, so long as it’s black.
If you simply abide by Canons #1 and #2, a very large part of the battle is won. The problem is that very few projects slavishly adhere to these concepts: high value, high risk first and assertive challenges scope creep.
If you follow Canons 1 and 2, Canon 3 will follow. If you diligently avoid these risk factors, your chances of success will be very high indeed. Here are the risk factors to avoid (that comprise Canon #4, avoid more than one or two significant risk factors):
- Avoid a brand new team
- Avoid a new language
- Avoid new technologies
- Avoid a distributed team
- Avoid outsourcing the primary deliverable, the code. (You can outsource technical writing, first round testing, help documentation, art work, basic CRUD of stored procedures, and defining test data.)
- Avoid projects that exceed previous success thresholds
- Avoid obviously tight schedules
- Avoid a heavyweight process, no process, or flavor of the month/year processes
- Avoid a dependence on heroic effort or more than 40 hours per week of work
- Avoid projects with no clear, ardent, and powerful sponsor
Assess your project against these risk factors. Very simplistically, think of each factor as an additional 10% likelihood of failing. So, if you have three of these risk factors you have a 30% chance of failing. If you have seven of these risk factors, you have a 70% chance of failing. (If you have five or more of these risk factors, you’d be better off taking your money to Vegas.) In all likelihood, more than two or three of these risk factors and your chances of failing catastrophically are very high.
Failure is missing time, budget, or features significantly. Catastrophic failure is cancellation of or removal from the project (or something worse).
Canon #5 is a risk factor and its own rule. Canon #5 is never ever outsource the primary deliverable, the code. If you can’t do it yourself, what is the likelihood that cheaper labor or people speaking another language will be able to figure it out any better across time zones, and cultural and language barriers? I will even go so far as to assert that the US is still the technology center of the world, and we have trouble consistently and reliably delivering based on time, money, and features. What is the likelihood that somewhere else someone has invented a magic wand that makes them more reliable and that we haven’t heard of that magic wand? Zero.
Do I mean that they can’t build software in China, India, or Russia? No; of course they can. Is it substantially better, cheaper, or more reliable and consistently so than in the US? No. There is some very good software written outside of the US, but the process is universally questionable, and so consequently is willy-nilly outsourcing.
Canon #6 is to get very detailed requirements in writing. Programmers know how to program. The problem usually is what to program, and that is dependent on requirements. If you don’t have detailed, written requirements, the customer’s need will be lost in translation.
|Identify the ten or twenty most valuable or challenging problems—depending on the size of the project. If these are in place, and there is universal agreement that they are complete, you are in pretty good shape. If there are glaring gaps, ask “why isn’t that piece done,” “am I worried about it,” and “how much does it worry me?” If the missing gaps worry you, the risky bits haven’t been aggressively tackled first and the project is probably in trouble.|
Budgeting for Every Budget
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages.
If you have made it this far, I would argue that your chances of succeeding beyond any objective standard are exceedingly good. Rigidly adhering to Canons 1 through 6 will give you a 9-in-10 chance of success, a presumption that can only be demonstrated not proven, but I believe it. The last step is to figure out ways to budget your endeavors. If you pick the right type of budget, you will almost assure your success and your customers’ satisfaction.
Basically, writing software is a little like house building. Everyone knows basically how to build a house and what a house is, but every house is a little different. Software is different in that every software project is a radically different kind of house. Some projects are dog houses, some are sprawling ranches, some are Bucky domes, some are sky scrapers, and some may be radically different like a dwelling in space or one undersea. The fact that you will be building a one of a kind something once and for the first time means that any estimates of time and money will be guesses at best. However, the simpler the project or the more consistent a project is with something you have already delivered, the better your guesstimates will be.
To wrap up, I have included several kinds of budgets. Each has a brief explanation and they are listed in the order in which they are likely to help assure success. Canon #7 is pick the correct budget model, and Canon #8 is that optimism is a desirable feeling; realism is an assertible fact.
When you go to a big city and get in a cab, there is a charge. For every portion of the ride (usually 1/8th of a mile), there is an additional charge. In the taxi cab model the meter is running, you can ride anywhere you like for as long as you’d like, and eventually you will get there.
The taxicab budget is the singularly most reliable budget in the world. The customer gets the software they are willing to pay for and the vendor gets paid for all the work they do. Of course, as you know, if you take a cab from New York to Los Angeles it will cost you a small fortune, but you will get there.
The downside to the taxicab budget is that the customer can’t know the total cost at the outset, and the vendor can’t make ridiculous margins by delivering in a fraction of the time. In the taxicab model, most of the risk is weighted toward the customer.
The next best budget model is “paygo.” In this budget model, you pay only for each phase—like analysis, planning, design, implementation, and testing. The key is to fix the time and budget for each phase based on the previous phase. At the end of each phase, you ask: Do we have enough information to proceed, should we cancel, or do we need more time in this phase?
If the answer is to proceed, you fix the time and budget for the next phase. If the answer is it’s a loser, cancel. If more time is needed, you repeat the current Paygo step. Fix the time and budget for the repeated phase and repeat the phase.
The problem here is that you still may not know how much money you will spend all in (or how much you will earn, vendor), but what you have done is acknowledge that you are collaborating to build something that is brand new in the world and there is no way anyone can accurately figure out how long it will take to build such a thing from beginning to end, up front. However, if you come up with a set of requirements, you can say that “based on these 100 requirements, I/We are willing to spend x-dollars and x-months to figure out a sound strategic way to proceed” and so on.
In Paygo, you will have to repeat some steps. Repeated steps are things no one knew about until they knew. No one is responsible for that, so the logical response is to repeat the phase and pay-as-you-go for a fixed time and amount additional times until you can reliably make one of the three possible choices.
No one—not Bill Gates, Steve Jobs, or anyone else—can reliably figure out how long it takes to invent something brand new in the world. The logical and fair conclusion is then that the process should be fair and equitable for all parties. Customers should get what they are willing to pay for and vendors have to make an honest profit; anything else is chasing fool’s gold.
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.
If everyone is working in the best interests of the customer—including the customer—a follow-on project for fit and finish can turn the working prototype into a finished product.
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.