Christopher Hawkins - effective Software Development and Web Design project management

RSS Feed now available

For those of you who've been badgering me about adding a feed to my site, here it is.

11:29 AM Permalink

"To Have More, Become More"

Jim Rohn, quoted from this week's Gitomer newsletter:

When asked, "How do you develop an above average income..." a friend of mine has always answered, "Simple. Become an above average person. Work on you." My friend says, "Develop an above average handshake." He says, "A lot of people want to be successful, and they don't even work on their handshake. As easy as that would be to start, they let it slide. They don't understand." My friend says, "Develop an above average smile. Develop an above average excitement. Develop an above average dedication. Develop an above average interest in other people." He says, "To have more, become more."

Simple, undeniably true, and yet so easy to forget.

01:07 PM Permalink

21 Rules of Thumb - How Microsoft Develops its Software

Best blog entry ever? It is possible.

This morning's edition of David Gristwood's blog boasts an absolute gem entitled 21 Rules of Thumb - How Microsoft Develops its Software. The item, originally written by Jim McCarthy, deals with how to get a team to gel, be productive, and produce great software. To be perfectly frank, I feel extremely validated reading it. Most of the things on his list are things that I have pushed for at development jobs over the years, but have rarely gotten through official channels (although I usually implemented similar practices on whatever team I happened to lead anyway). Now that I run my own company, however, I can implement any development guidelines I like. Let's look at the top 3 items from Microsoft's playbook:

1.Don't know what you don't know.

It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn't early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.

Here we have a classic example of one of the 5 Pitfalls of estimating projects - Pitfall #4, to be exact. This is arguably the most important concept in the whole industry - eliminate the unknowns, and if you cannot eliminate them, acknowledge them as unknowns. I think we're all familiar with the old saying about the word "assume".

2. Get to a known state and stay there.

The function of QA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly.

It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyone involved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you've observed every single painful step toward it.

The only reason you've been able to make these micro-observations is because you got to a known state and stayed there, and your QA is how you did it.

There isn't a developer among us who doesn't have at least one war story related to a problem that stemmed from the build being in an unknown state. So far, so good.

3. Remember the triangle.

There are only three things that you are working with as a development manager: resources (people and money), features and the schedule. Changing one has an impact on at least one other axis, usually two. It is a simple enough matter to mentally run through the sides of the triangle, or force others to do so, when discussing any part of it. Since the people, the product or the schedule is almost always what you're discussing, this means that you must constantly envision the triangle. This leads to the most fruitful line of thought.

OK. Remember when I wrote that eliminating the unknowns was arguably the most important concept of all? I am now arguing with that position. Without fail, the single most destructive act that can be committed on a project is to try to violate the relationship between resources, features and schedule. To do so is to fall right into the fifth of the 5 Pitfalls of estimating a project - taking too large a bite from the apple. It's good to see that MS (or at least, individuals within MS) are acknowledging this publicly.

Those are just the top 3 items from the list; take a look at the remaining items. You'll find things like "Low tech is good", "Beware of a guy in a room" and my personal favorite - "Never trade a bad date for an equally bad date".

Now if only I could answer the question of why so many organizations fight these type of best practices tooth and nail...

10:51 AM Permalink

Why the Desktop is Never Going Away

By now we've all read Joel Spolsky's rant on how Microsoft has lost the API war and it's too late and desktop development is dead and web development rules all and everything is going to h-e-double-hockey-sticks in a handbasket. I'm not even going to bother linking to it - you all have either read it, or know where to find it.

Now that Joel has the industry all abuzz with his prognostications of doom for desktop applications, I would like to tell you that the desktop is not going anywhere.

Pointe the first:  I am not anti-web. I think web development is a very cool technology, and I can absolutely see the benefits for businesses, although I am convinced that web apps will never catch on with consumers. So as you read this, remember - this is not an anti-web rant. One platform need not die in order for the other to live.

Pointe the second: As you already know by now, NewsGator got funded. Who says VCs are not funding Windows apps anymore?

Pointe the third: Desktop = Power. Nobody - and I mean NOBODY - like the high latency of your typical web app. They simply do not. Sure, Gmail has managed a reasonably snappy interface, but it is still nothing like having "real" software living on your computer. Users like horsepower. Users like ownership. Users like systems that react as quickly as one can click the mouse. Period. And even ASP.NET, as cool as it is, cannot give that to them.

Pointe the Fourth: Users do not trust computers in general; the relative level of trust is inversely related to how physically close the computer is. By far, the number one objection my clients raise to web apps is this: what if my internet connection/network goes down? Even with the economies of scale inherent in hosted apps, many businesses think them too risky to use. Web apps that are hosted on the company's own intranet do much better in the trust equation, but even then the thought is frightening to some companies. Sure, you can talk about how you're going to build failsafes into their system so that they can keep working under those circumstances, blah blah blah, but by then one of two things has happened - a) the client's eyes have glazed over, or b) they're thinking "so you're going to make the project more expensive just to safeguard against something that should never happen I the first place?" and once you get to that point, you have lost. When an application actually lives on the user's machine, the user feels as though he has a little bit of control over the destiny of his workday.

Pointe the fifth: Consumers still buy lots and lots of software. As dicey a proposition some businesses might consider web apps, the general corporate consensus is that it is OK to use them. But as always consumer behavior is different. Going back to NewsGator, can you imagine an app like that being a web app? How about PhotoShop? CorelDraw? MS Word? WinAmp? There's no way.

To be fair, as long as I am pointing out the shortcomings of web apps, I should also say that the desktop does need to do some work. Although it enjoys the advantages of psychology and power, it needs to improve in the arenas that the web truly excels at - deployment and portability.

I was talking with Richard Caetano about this just the other day, and we agreed that although the problems of desktop-app deployment can be cured (or at least mitigated well enough to please people), portability is the real problem that the desktop must overcome to remain a viable platform for application usage. How DO you use an app that is installed on your computer, when you are not on your computer? This is the questions that nobody seems to have an answer for yet. Perhaps a next-generation method of hoteling could allow a corporate user to quickly pull an image of his usual desktop onto a "blank slate" PC in a satellite office? I'm not the most qualified person to theorize on this matter, but it is clear that in the war between those who favor the desktop and those who favor the web, the desktop needs to improve its portability at least as much as the web needs to improve its performance.

This is quite the incoherent ramble, and I'm not really saying anything others have not said before. So allow me to wrap up by saying this:

Predictions of the desktop's demise in the application market are premature and overblown. With Whidbey, it is said that Microsoft is betting the company on the desktop. Well, if Bill is willing to bet the company on the desktop then I am willing to bet my career on the desktop. But the beauty of the situation - and the point of my wide-eyed, frothing-at-the-mouth rant - is that nobody HAS to bet anything on any one platform; the universe of potential applications is large enough to support both desktop and web models. To suggest otherwise is to look at the glass as half empty.

Discuss 'Why the Desktop Is never Going Away' here

06:14 AM Permalink

Excellent Interview with Scott Collins of Mozilla

ArsTechnica has posted an excellent interview with Scott Collins from Mozilla.org. He covers open source, Mozilla mistakes, and competing with Internet Explorer.

06:58 AM Permalink

Microsoft Gets Into the Anti-Virus Business

Yesterday, Mike Nash of Microsoft's security business unit told reporters that Microsoft is developing anti-virus software to protect Windows machines. The core technology comes from a Romanian company that was recently acquired by the Redmond giant.

No release date was indicated, but Nash did say that the anti-virus software would not be bundled with Windows. Let me repeat that - Nash did say that the anti-virus software would not be bundled with Windows. It is going to be separate product.

This is pretty interesting.

Microsoft has been getting hammered for bundling things into Windows that put pressure on their competitors. Now they declining to bundle a product that probably deserves to be bundled more than Internet Explorer or Windows media Player do. Interesting, especially when you consider that Central Point AntiVirus used to be bundled with DOS.

For my money, I'd love to see Windows Server 200x or Longhorn ship with anti-virus software built in (as long as you could turn it off if desired). I've never been a big fan of the argument that bundling is anti-competitive; if a bundled product is weaker than a competing, non-bundled product, the consumer will use the competing product every time. It would be no different here.

I won't turn this into a rant, as the point is moot - this anti-virus product will not be bundled, and that's alright. It is nice to see MS throwing some of its considerable heft behind increasing the security of the computing experience.

Do you suppose MacAfee or Symantec or Trend Micro are nervous? Do you suppose they have reason to be? I do. Despite the invectives frequently hurled at Microsoft as to the quality or stability of their products, the fact of the matter is that MS is where it is because it created more value for more customers than any of its competitors did in the operating system and desktop application marketspaces. Period. End of story. If their anti-virus offering turns out to be another Excel, the established players in the anti-virus space are going to be in for a bare-knuckle brawl just to hang on to their respective bits of market share. Of course, if Microsoft's anti-virus offering is a dud then...nobody cares. The product will fade away, and the established players will all enjoy a big sigh of relief.

I'll be keeping an eye on this situation. ;)

Discuss 'Microsoft Gets Into the Anti-Virus Business' here

04:40 AM Permalink

Why Web Apps Will Never Catch On With Consumers

I just got around to reading yesterday's entry at JoelOnSoftware. Joel made an interesting comment while talking about Firefox:

"Microsoft took over the browser market fair and square by making a better product, but they were so afraid that Web-based applications would eliminate the need for Windows that they locked the IE team in a dark dungeon and they haven't allowed improvements to IE for several years now. Now Firefox is the better product and there's a glimmer of hope that one day DHTML will actually improve to the point where web-based applications are just as good as Windows-based applications."

If that is (or was) truly a concern of Microsoft's, I'm not sure it's entirely founded. Now, I think that web-based applications are cool. Very cool. But I can also recognize that the psychology of web apps runs counter to the psychology of the consumer. The consumer does not particularly like to rent; the consumer has a predisposition to buy, or more specifically, to own. The prevailing sentiment is, "if I give you money in exchange for some item, the item is MINE; I now possess it and can do with it what I will, with no further input from the seller".

Our current software model works this way. You go to your local computer superstore, or log on to Amazon and purchase a copy of, say, MS Office, and in return you get an actual thing - a heavy box with disks and manuals and rebates and coupons inside. It is a thing, an object, and you own it. You can use it for as long as you like (or until a version of Windows comes along that renders it useless; but then again, nobody says you have to upgrade from Windows 95?), and nobody can stop you. With regard to this box of software, you are The King.

Now contrast this with the subscription model that comes with using web-based software. You set up a recurring monthly charge on your credit card with the application service provider. You log in to the provider's site and use the application to complete some task, right there in your browser. When you are done, you log out and continue surfing ArsTechnica to look for a decent review of a 21" LCD.

You should have some sense of satisfaction. After all, you completed your task, whether it was writing a letter or making a list or drawing a picture. And it was convenient, too - you got to do it right in your browser, with no worries of version incompatibilities, hardware problems, file corruption, nothing! But you don't feel satisfied, do you? In fact, you probably feel thoroughly unsatisfied, and somewhat empty inside. Why is that?

It's because there was no take-away from the experience. You spent your money, you got access to what you needed to complete a task. You don't actually own anything, and that's an insecure feeling. What if you lost your job and went broke? If you own a copy of MS Word and can pay your electric bill, you can churn out resumes all day long until you find a new job. But with the subscription model...nothing. In fact, spending money to use a web app seems a little bit like paying to do work. And that doesn't seem right, now does it?

That may seem a bit hyperbolic, but I think it illustrates the basic psychology behind a consumer's use of web-based software. Microsoft once wanted to go subscription-based with Office - not even web-based, just subscription-based - and perhaps still does, but they're smarter than that. The few times that such rumors have hit the Internet, outcry has been fast and unmistakable: "my dollars, my software".

You may have noticed that I qualified this entry's title by adding "With Consumers". If this leads you to believe that I feel businesses are not sensitive to the same consumer psychology as individuals, you are incorrect. However, I will say this: I believe that businesses are (on average) somewhat less sensitive to these concerns. Economies of scale are at work when making purchase decisions for a business that bring elements into the decision - bulk discounts, lower deployment costs, decreased employee theft - that do not exist when making a purchase decision for a single consumer. But businesses are ultimately just groups of people - people who like to actually own something when they spend their money.

Discuss 'Why Web Apps Will Never Catch On With Consumers' here

12:20 AM Permalink

More Feedback on The 5 Pitfalls

Regarding The 5 Pitfalls of Estimating a Software Project, Jonathan writes in about an estimate his manager asked him for:

"His first comment was that he had never seen an estimate given in hours. I explained to him that I didn't like to give dates because of unexpected company meetings, sickness, etc. I don't think this ever occurred to him. His second comment was that my estimate was too large and that he would have to "massage the numbers" so that the executives wouldn't be upset. I was absolutely furious. What's the point of even asking me if you're not going to listen to my answer?"

Sounds like I should have included a sixth item - not listening to your developers. But I think that probably falls under the heading of "allowing non-technical staffers to give estimates". After all, once you override someone else's estimate, the new numbers that you give the client are no longer the other guy's numbers - they're yours.

I'm getting a lot of great eMail feedback on the 5 Pitfalls, but not much in the discussion forum. Everyone feel free to drop a comment in there about any item in this blog - for that matter, feel free to start new topics to discuss.

Discuss 'The 5 Pitfalls of Estimating a Software Project' here

05:35 PM Permalink

Christopher on Gmail: The Review

I guess you can call me Charlie, because I've found one of Willy Wonka's Golden Tickets - a GMail invite, that is. I set up my account about 10 days ago and have been playing with it ever since. I'm fairly impressed, but I expected to be. Google does not produce garbage. For the benefit of those who do not have a GMail account but are curious about the service, I'll do a mini-review here.

I Feel Pretty...

First off, the interface is nice - minimalist, clean and effective, just like the main Google page. The first thing one notices about the GMail interface is that instead of presenting a list of eMails, GMail groups entire eMail threads together under one subject line - that is to say, you only see the subject line in your Inbox one time, instead of seeing it one times for every message sent with that subject line. In my opinion, this alone is sufficiently compelling to justify a move to GMail from whatever web mail you might be using now. If the benefit of threaded eMail is not clear to you, let me put it this way: you'll never again feel dread when a client or colleague asks you "Did you get my last eMail about that that?".

Got Ads, Shown Live If You Want Them

Next you have the targeted advertising. This is upsetting a number of people for some reason, but I love it, especially because a lot of my eMail consists of consulting with colleagues on programming and tool matters. It never hurts to have a fast link to relevant items at hand. Notice the ads along the right-hand side of the page in Figure 2; not only are they context-appropriate to the current eMail message, they are unobtrusive enough to keep me happy, all tucked away off to the side like that.

Bells & Whistles

One of the better features is the keyboard shortcuts. I defy anyone to think of anything they might want to do with an eMail message that cannot be done with GMail's keyboard shortcuts. Compose message, Search, Reply, Forward, Archive, Next Message, Previous Message - iit's all in there. Having these keyboard shortcuts will go a long way for some people - we all know that some users have a hard time using the mouse. Including these shortcuts takes GMail one step closer to being a "real" eMail application than other web mails services currently are.

Go, Speed Racer, Go!

For the those who complain of the lag inherent in doing anything over the web, let me tell you - GMail is pretty snappy. I have cable internet, so my connection is snappy in general, but the web mail offered by Hotmail and Yahoo! have always seemed sluggish to me.

My, What a Big Inbox You Have!

Now, on to storage. It is no secret that GMail has allocated an unprecedented 1GB of storage to each GMail user, the idea being that one should never have to delete an eMail. In truth, Google does not want us to delete eMail because it wants to analyze the spam we get, so it can offer filtering services in the future (it is worth nothing that Microsoft and other industry notables are working on the spam problem as well. Whoever comes up with a good solution first will have a huge foothold in a lucrative market - who DOESN'T want to filter out spam?), but whatever the motivation is, it is nice to not have to worry about butting up against some dinky size limitation.

This Is Not A Conspiracy

The paranoid among you can rest easy - GMail does indeed allow you to delete eMails, even if you don't need to - you can send an eMail to the Trash, then select the 'Delete Forever' action, and *poof* the message is gone. It is interesting to note that there is no keyboard shortcut for 'Delete Message'.

And the Winner Is...

...the users! There are a ton of free web mail providers out there - we've all got more than we need. That said, the threading, the 1GB of storage, the easy-to-use interface and even easier-to-use keyboard shortcuts make the switch to GMail make sense. If ever there were a better mousetrap, this is it. Also, by using GMail you are helping Google to fight spam. And who wouldn't want to fight spam?

Discuss 'Christopher on Gmail' here

01:12 PM Permalink

Feedback on the 5 Pitfalls

Richard Caetano over at Strongly Typed made a great comment related to my 5 Pitfalls of Estimating a Software Project item:

"An off-the-wall thought: When I'm able to pull it off I do a project/time estimate as the inverse. I ask the customer how much time I have...then figure out what I can do in that amount of time. In a way a time estimate is a requirement. What good is a product if it can be delivered on time (which may be at arbitrary length) but not at an *applicable* time."

Richard brings up an interesting point - sometimes you get a project that is only useful to the client if it can be implemented by a certain date. I often had to do the kind of inverse estimating that Richard refers to when I was building variable compensation systems; those Fortune 500 companies do their compensation processing on a certain schedule, and if I couldn't deliver certain features by certain dates, the value of those features dropped to 0 until the following year! These days, most of my consulting work falls into the category of "things the client wants to do as soon as I can build a tool to do it with", but that is not going to be the case with everyone and it is good to bear in mind that sometimes you have to back in to your estimates.

Now that I'm thinking about it, backing into an estimate is also a great help in managing expectations. Once you present an estimate containing x number of features, if the client later has to change the due date for some reason, they won't always understand when you come back and tell them that given the new date you can only deliver x - y features. They won't always understand why you can't just "work faster" and deliver the original feature set - they're experts in their own businesses, not in the very unique (and sometimes strange) rules governing software development. Some might even be taken aback and think you are punishing them for giving you less time to do the project. It sounds outrageous, but it does happen.

Better to present an estimate with fewer features that you KNOW you can implement in the time allotted, if date constraints exist prior to your taking on the project.

Discuss the '5 Pitfalls' here

08:04 AM Permalink

Site Changes here at ChristopherHawkins.com

As everyone who visits my site - yes, I mean both of you - can tell, I've been doing some cleaning up. I'm hoping the revamped is cleaner, more readable, and more interesting than the previous incarnation. The big changes are :

• Condensing the site from about 20 pages to 5 more focused pages
• Changing the overall look
• Adding a weblog
• Adding a discussion forum

There used to be a Projects page, which will be making a return as soon as I have enough screenshots to justify it. Who wants to read about the apps I've written when you can see them instead?

05:52 AM Permalink

How Wrong Can One Guy Be?

I just caught this article in the Seattle Weekly. The author is a former Microsoft employee who now embraces the Mac platform and now has predictions of doom and failure for his former employer.

So how can the supposed failures of Microsoft be sensationalized? Let me count the ways:

Why are Microsoft products so endlessly frustrating to use? Even techno-geeks like me get annoyed by Windows. I'm tired of spending the first 10 minutes of my day rebooting just so I can get to work. Microsoft Outlook 2003, the latest version of the company's e-mail and calendar software, hangs for me about once a day, requiring me to restart my PC. I also have a problem with Word 2003: Whenever I bullet a line of text, every line in the document gets a bullet. Asking Windows to shut down is more of a request than a command-it might, it might not. And recently, Internet Explorer stopped opening for me.

I have seen this kind of system behavior before, and its name is virus. For Pete's sake, I've been using Windows since 3.1 and I have NEVER seen a system fail that often or that severely in the absence of a virus or a hardware problem. Sure, you get the occasional blue screen (and when I say occasional, I'm talking every couple months at worst), but...Internet Explorer won't open at all? And that's Microsoft's fault? Look at your PC, my man.

But in the first five minutes on my new Mac, I was surfing the Internet, sending e-mail, and ripping a CD. OS X has been a breath of badly needed fresh air after Windows.

And you couldn't do this on your Windows system? Millions of other users manage to do these very tasks on a regular basis. Something's rotten in Denmark, I think.

This made me wonder about Microsoft's willingness to innovate and compete. Why are Microsoft products still so difficult to use and so unreliable? Why is the company improving them so slowly? Is Microsoft losing its competitive edge? Has the company seen its best days?

This strikes me as the thinking of somebody who, having embraced a new computing paradigm, is now trying to over-justify his change by finding fault in his former paradigm. I mean, Microsoft is far from perfect, but if we're going to bash them, let's bash them for things they're actually at fault for.

Jeff, here's some news for you: it is OK to decide that you prefer the Mac platform to the Wintel platform. No, really - it's OK. This is a free country and if you love your G5, more power to you. But what is NOT OK is writing up hyperbole and inaccuracies in order to justify the change.

Discuss 'How Wrong Can One Guy be?' here

12:29 PM Permalink

Christopher on Eric on Ries and Trout

Eric Sink has been doing something very cool for the past few days: he's posting an opinion piece each day about one chapter of the Al Ries & Jack Trout classic, The 22 Immutable Laws of Marketing. As anyone who knows me can attest, this is one of my favorite books.

Anyway, Eric hit a sour note with me today. :P I feel compelled to razz him a little bit in response to his assertion that:

"We underestimate the value of mindshare when we try to change the minds of people. Ries and Trout say that "The single most wasteful thing you can do in marketing is to change a mind." I would love to know how much it will eventually cost to convince the world's VB6 programmers to move to VB.NET. The audacity of this move is simply amazing. For any other company in the history of the earth, it would be suicide to try and change the minds of several million of your own customers."

Now, I won't challenge the premise that the industry often underestimates the value of mindshare. But using MS as an example just doesn't fly.

No other company in the history of the Earth has ever had so much control over the environment in which customers use the company's product as MS has right now, and that makes all the difference. Sure, the transition from VB6 to VB.NE will be expensive - but the end result is a lock; given sufficient time, most VB6 programmers WILL end up using VB.NET. The issue is not so much one of cost as it is one of value; however much it will eventually cost to force the transition, MS must think it will be worth it.

My point is that MS is not a good example to illustrate underestimating the value of mindshare because the consequences of that underestimation are miniscule for them. A company that attempted such a radical shift with the prospect of severe consequences might have been a better example.

Suppose (for example) that Pacific Bell tried to force all their residential customers to abandon their landlines and go cellular. Would they be guaranteed to retain all or most of their customers, even if they were handing out free phones? Probably not. Cellular service is largely undifferentiated between providers (they all suck equally), so rather than getting any kind of lock-in, Pacific Bell would lose a lot of customers.

But when you are a VB6 programmer who is largely dependant upon Microsoft's operating system and IDE to do your work, who else can you turn to in the "operating systems and development tools for creating and deploying VB6 programs" market for the gear you need to continue being a VB6 programmer once there are no more flavors of Windows or Visual Studio that support VB6? I can't think of anyone. Can you, Eric? ;)

Discuss 'Christopher on Eric' here

12:15 PM Permalink

The 5 Pitfalls of Estimating a Software Project

I am frequently asked why software projects are chronically late and/or over budget. Naturally, I always take that question as an opportunity to brag about not having gone more than 10% over any estimate since 1999. ;)

It took me 6 years to learn how to produce an estimate that accurate, however, and along the way I've noticed a set of behaviors that always lead to blown estimates and broken budgets. Avoiding these pitfalls will put any organization on the road to more accurate estimating, happier clients, and profitable projects.

1) Allowing non-technical staffers to give estimates. I know, I know, you think I'm about to launch into a typical software developer's tirade about how talentless the people on the "business side" of the house are - but I'm not a typical software developer. I will say, however, that allowing a non-technical employee to provide an estimate for completing technical tasks makes about as much sense as allowing a hardcore C++ programmer to commit the company to a marketing plan of his own design. I'll even go so far as to say that NOBODY should be allowed to give an estimate for a piece of work except for the person who is actually going to perform the work.

Remember Adam Smith? He wrote an obscure little book entitled The Wealth of Nations, maybe you've heard of it. In it he argued for the specialization of labor, using a pin factory of the day as an example:

"...where each of a dozen workers engaged in only one part of the process of manufacture, so that together they produced far more pins than if each worker produced whole pins; the price of pins then fell, and more pins could be used by more people."

When businesses violate the principle of specialization of labor with regard to creating their product, trouble is soon to follow. It is far better to allow the specialists to do work that falls within their specialty than it is to placate a client by giving a totally fictional estimate.

Because of the Iceberg Effect, a salesman out in the field is likely to think to himself, "Well, that's just a couple of screens and buttons, it shouldn't take very long". So he gives the client a number, and the number may as well be 1 hour or 1 million hours, because it cannot possibly have any connection to reality unless it comes from the person who has to build the item being estimated.

Let your salesmen sell, your marketers market, your executives execute, and your developers develop...estimates, that is.

2) Being afraid to look in the mirror. Most development shops I've interacted with do not do any "post-mortem" reviews at the end of an over-budget, past-due project (or even a successful project, for that matter). Therefore, they never learn what went wrong, never disseminate information that can help other teams to avoid what happened, and then promptly repeat the exact same mistakes. This causes the next project to be over-budget and past-due, and that project doesn't get reviewed either, so the same mistakes are made on the project after that, and so on. Even seasoned developers of whom you would expect sufficient experience to avoid common pitfalls fall into this trap.

Don't be afraid to take a look in the mirror and ask "what did I do wrong?" - this applies to everyday life as much as it does to software development. Always analyze your projects for both mistakes and best practices. Failure to do so is the equivalent of flying a 747 without visibility or instrumentation through the Himalayas; way too much risk for most client's tastes (and checkbook).

3) Underestimating design time and debugging time. Most software developers are not in tune with The Business, they are in tune with The Thing - that is, they focus tightly on the act of construction and sometimes miss the other, equally vital, things that go into a successful project. Design is one of the most commonly underestimated things, I think.

Figuring out how to build something takes time - sometimes more than it took to figure out what to build. On the other end of things, debugging and refining and polishing up the code takes more time than anyone ever anticipates - in fact, in my 11 years in this business, I have never seen an accurate debugging estimate. Never. Not once - except for my own, of course. ;)

Budgeting 50% of total development time for debugging is absolutely reasonable, if not necessary. Any developer who fails to accept this is still in the Age of Unlimited Wisdom (more on that later).

4) Inadequate/unclear requirements. Gathering requirements is difficult, gathering requirements well is rare, and gathering requirements correctly before asking a developer to start designing is just this side of miraculous. I would estimate that 90% of my pre-consultancy projects suffered from inadequate requirements. Ask any developer - they all have war stories about the unbelievably poorly-written spec that had more holes in it than Swiss Cheese when they got it from the Business Analyst (to be fair, Business Analysts have war stories about OCD-affected developers who suffer from "analysis paralysis" and cannot do anything without every fact under the sun available to them first, but I digress), and most of those stories are true.

It is tempting to rush the requirements gathering process. It is tempting to just assume the answer to questions that are not addressed in the requirements. Mapping a client's business process is hard, and very few people want to do it - those that actually relish the task are of a rare and strange breed. Uncovering and documenting every seemingly hidden nuance of how a company does business is hard. Going back and forth until everyone agrees that what is detailed in the requirements is an accurate representation of needs to be built is hard. There is a tremendous amount of room for inaccuracies to creep in, especially if you are in a rush.

By slowing down just a little bit - and by little I'm talking 10% - and making sure that the requirements gathering is done right before construction begins, everyone will end up happier and the project is infinitely more likely to be a success.

5) Taking too large a bite from the apple. I cannot count the number of times I watched in horror as a project manager approached a junior programmer, asking "How long will it take to do X?", only to hear "Not very long - maybe Y hours" in response from the snot-nosed young know-nothing. Now, whether X was "re-write Microsoft Office from scratch in Assembler" or "change the color of this font on the home page", the only correct answer to that question is "Let me see the requirements". And if you don't have requirements, you need to get some, even preliminary ones. Even then you cannot commit to anything better than a "plus or minus 50%" estimate until everyone has agreed that the requirements are complete. Even then you cannot give a good estimate until you break down the requirements into bite-sized chunks.

That is the secret weapon of estimating - the more small chunks you can reduce the requirements to, the more accurate your resulting estimate will be. But most people are lazy. Analyzing requirements is almost as difficult as gathering them, and again - very few people want to do it. Those that do will consistently deliver more successful projects than those who do not.

I'm not saying anything here that people in the industry don't know. But I am saying a lot of things that people in the industry don't do. I wish that were not the case, but I can only control my own projects.

Discuss the 5 Pitfalls here

09:39 AM Permalink