In my last post I talked about the importance of estimating development time/effort on a software project, in the large. In this follow-up, I’ll bring it down to a personal level. A bit of career advice for anyone crazy enough to take up software development as a profession.

In my first IT job, at a public utility in central Illinois, much of upper management in the IT department came from other disciplines (utilities tend to be kind to those with engineering degrees). At one point, my director (boss’s boss) was a nuclear engineer who somehow found himself running software development.

And guess what – he did it better than most of the folks who had grown up debugging PERFORM-VARYING loops in COBOL. (This was a while ago, people.) Why? More than anything, it was his ability to bring us ethereal, software types down to reality. To remind us of the business function we performed, and how we fit into the company as a whole – so we could better provide value. It was quite empowering, in a tear-you-down-to-build-you-up sort of way.

I remember much of the good advice given to me over the years in the form of phrases or sentences. It’s as if there is a fluorescent yellow highlighter in my brain (which is odd, as I never used the things – I thought it a terrible thing to do to a good book).

So, anyway, a key lesson I learned from Dick was first handed to me thusly: “You don’t want to be known as having alligator-mouth, hummingbird-asshole syndrome.” Or, its rough equivalent (but not nearly as memorable): “Always remember, it’s better to be an asshole at the beginning and a hero at the end than the other way around.”

Two different ways of saying the same thing: It is a very good thing to under-promise and over-deliver. You will be remembered fondly – with words like “hero” and “rock star” and “brilliant.” And it’s a very, very bad thing to over-promise and under-deliver. You’ll be remembered, all right – but alongside words from a very different mental pool. “Slow.” “Unreliable.” “Untrustworthy.”

The key point I want to make to you, dear reader, is that the stark contrast has little to do with how hard you work, or how brilliantly you discharge your software engineering duties. Rather, it has everything to do with how you interact with your customers, and how you Mange Their Expectations. Borrowing the analogy I used in my last post, it’s in how you construct the ruler by which you will be measured.

Look. If you’re a reasonably talented software developer, and you have a reasonably well-developed work ethic, you will find a way to deliver your work – whether it be an application, an API – whatever it is – in a reasonable amount of time. You just will.

What far too many of us fail to do is ensure that those who are important to us in our careers – our customers, and our managers – really understand what constitutes “reasonable,” and understand it up front, before work begins.

When we estimate a piece of work, we should always expect that our stakeholders will think it should take less time (and money) than we do. It’s human nature. First, they are probably paid incentives to minimize expenditures on things like software development – so their brains are wired to question every estimate and try to get us to agree to do things “for less.” Second, they are not as close to the problem as you are, and therefore don’t see the complexities, and the risks.

One of your most important jobs as a software professional is to educate your stakeholders. Point out the risks. Explain why something is likely to take as long as you say it will. Be calm, and kind, and try to use analogies and speak in non-technical terms. But be firm, and speak with conviction. Be “the asshole at the beginning.” It might be a little uncomfortable, particularly if the other conversant is the guy who signs your performance review. But remember how devastating it will be if you cave to pressure and revise your own estimates downward – only to be that “asshole at the end” who can’t deliver on a commitment.

If more of us in the software industry took the time and energy to really hone our estimating skills, and our defense-of-estimate prowess, we might be able to reverse our long-running history of time and cost overruns on projects. Managing expectations in the large, at the project level, starts at managing expectations in the small. With the work each of us is asked to do on a day-to-day basis.