Op-Ed: Fish or Cut Bait
Attributable to U.S. Judge Levi Hubbell in an 1853 land dispute, "fish or cut bait" means do something productive or desist entirely. It's the same as put up or shut up or the one my dad liked that ends with or get off the pot.
What's my point? Good question. I am going to rant a bit, but there is a point coming.
Building software can be a very profitable business. Building custom software for a single company can be profitable and building shrink wrapped software can be very profitable. Figuring out what to build may be the first challenge, but if you have a customer that knows what they want built, the next challenge becomes how to make money building it. The answer: fish or cut bait.
There are thousands of books on how to build software and on almost every aspect of software development one could imagine. Presuming that reasonably intelligent people read these books, they should know (or have some idea) of how to do these things—write code, debug, build databases, design web pages, or whatever. Let's further assume that some of these people who write these books know at least as much about the things of which they write than the rest of us. The point is, then, why would anyone write a how-to guide for a single application development instance? The material exists. If one doesn't know the answers, read or ask someone who does.
Further, let's assume that any single company decides that they need to write a how-to guide anyway. Perhaps they feel that all of the existing material on the subject is bunk. Fine, but why would you ever write a second version of the guide? Maybe, maybe update the original over time, but this is an expensive and time consuming endeavor. Fish or cut bait.
The point here is that if a group of people are in the middle of building software, it's too late to write how-to guides. Get the best people you can, people who know how to do the job for which they were hired, and get out of the way. No amount of documentation at this point will help.
Sure, you need to have a project plan for software, but this can be a rough story board that shows resource allocations and when the chunky bits will be done. Sure, you need version control, but you don't need a how-to on the best way to use the version control. Same with coding standards. Never have coding standards meetings. For example, with coding standards just dictate that everyone should please write it such and such a way. Or, better yet, if the source code is part of the deliverables, pay an intern to paginate it later. Fish or cut bait.
You need a design, too. A design helps you solve sticky problems and experiment with solutions much more quickly than code, but what you don't need is a one-to-one correlation between models and code elements. What you really don't need is a how-to model guide. The modeler should bring these skills to the table; if not, get a new modeler. Fish or cut bait.
A problem I have seen for twenty years now is that technical people make estimates and managers try to do a little arm twisting to shorten them. The result is not enough time and everyone ends up looking bad and the project is late. Tell a thoracic surgeon he only gets 45 minutes for open heart surgery and it might be the manager's chest cavity that gets opened up.
The role of a manager should be facilitator, not guesstimator. The role of a technical person is to build technical stuff. When it comes time to build software, there is no time to write how-to guides and no one should be spending their time that way. It's a waste of time. The problem here is that up front, one-shot fixed estimates are always crap and everyone knows it. It's like the king has no clothes but everyone keeps slow dancing with him.
[There, I feel better.]
To summarize: Keep the documentation short, no how-to guides, and focus on deliverables.
Of course, now the project has run long, the customer is upset, and your company is bleeding money. Well, pull out all stops to get done. How-to guides and what went wrong meetings should not happen here. Just keep going. Ah, finally, we finished. Over budget and under-featured, but we finished.
Now, now is the time to have a post mortem. Now is the time to analyze what went wrong and maybe come up with some better practices. The best way to do this is to buy some books, take some classes, attend some seminars, and learn some better ways of doing things. More than likely, the answer is very simple: Give yourself more time next time or hire better people.
In closing, only certain groups of people will ever learn to be wildly successful. When you find these people, hold on to them. Keep them together as a cohesive unit, bring other people on and off that team so they can learn to be wildly successful, thus pollinating your organization with ultimately wildly successful people. Weed out the rest. Brutal, but fish or cut bait.
To paraphrase Joel Spolsky: It is impossible to write a Hamburger U how-to guide for software, unless every piece of software you write will be the same, and that is ridiculous. And for criminy' sake, if you do write a Hamburger U sort of document, never write a second one.
[Clarification: A fixed calendar is different than a fixed estimate. A fixed calendar means you do whatever it takes to finish by such and such a date. A fixed estimate means you will do all of the things in the estimate and be done by such and such a date or time. The former means making tradeoffs. The latter is rubbish.]
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#; preorder your copy today at Amazon.com. Paul Kimmel is an Application Architect for EDS. You may contact him for technology questions at firstname.lastname@example.org.
Copyright © 2008 by Paul T. Kimmel. All Rights Reserved.