In my first job as a programmer I worked on the administrative software for a small twentyfive person company that maintained and repaired computers. That could give you a clue about my age; at that time computers were still worthwhile fixing. As any overoptimistic young programmer would do, I looked at the existing code of the application and pretty soon figured out that it needed some serious rewriting.
So, after convincing Jimmy, the sole programmer of the software, who, by the way actually was a computer maintenance engineer with a soft spot for developing software, I went to see the owner of the company and enthusiastically explained to him my ideas about this brand new version of his software, that would be much easier to work with, thus improve productivity and that also could be better maintained and extended. Friendly nodding, the owner of the company overheard my speech about rewriting the general ledger, customer and contract software, the sales support software and the billing software all at once.
After I finished the room filled with silence. I caught him by surprise. At least, that’s what I thaught. However, it didn’t take the owner of the computer maintenance company much more than a split second to come up with the inevitable question that’s destroying our beautiful profession: “How much is this going to cost, and how much time do you need to write this software?”
Reality hits in
And this is where reality hits in. Hard. When it comes to estimating software development projects, we programmers always seem to get into trouble. How long does it take us to write a particular piece of software? In this case, we value our experience. But what if you don’t have any experience, because you’re still at college and this is your first work placement? What if this particular company is using a programming environment nobody ever heard of – in this case a 4GL language called Today, for which there were no other users in the country at that time.
“Well”, I said, “we, that is, Jimmy and I, estimate that this will take us six months to complete the new version of the software.” Jim and I actually did our homework. We tried to count the number of screens that we would have to build, based on the current application. Then we figured out how much time it took Jimmy to write some of the existing screens. Our estimate was the result of multiplying the number of screens to produce with the amount of time required for producing an average screen. Six months. We got the job.
Now, just for the record, programmers tend to be optimistic in their estimations. We tend to oversee the complexity in our software. How difficult can an automatic billing application for contracts be? Statistically, programmers overestimate their powers of programming by a mere 20%.
After about four months Jimmy and I had worked on about twenty of the screens in the new software. We talked a lot to the actual users of the application, and built the first modules. People appeared rather happy with the new software. But along came the contract billing application. And this was a totally different ball game. It had to contain six types of regular contracts, four types of master contracts and also incidental billing for non-contract customers. It took me over a half year to write the software. As a consequence the company was unable to send bills for three months.
To cut a long story short, Jimmy and I worked on this company’s software for over four years. New and changing requirements, hidden complexity and unwilling technology kept messing up our plans, and every now and then we were called to the spot by the owner of the company for mis-estimating our work and for missing the according deadlines.
Finally, when I left the company after five years, most of the original promised software was delivered. Additional applications were built, and even some of our software was already replaced by newer versions. And our estimate? Where our initial estimates were of by a milestone, the next generations gently improved over the years.
Now, as twenty years have passed since, the company still exists.
Pages times tables
About a year passed since and I was working for a large international system integrator. Strange phrase that is, system integrator. At that time nobody integrated any systems. Each new application was built as a stovepipe, merely a bunch of forms to display and modify data from a database. Not even the databases were integrated back then.
Anyway, there I was minding my own business, writing some PowerBuilder code, when my manager walked in the door. “Sander,” he started with a friendly voice. “We are working on a proposal for a project with an important customer.” Did I mention that all our customers were important back then? So much has changed! “We desperately need a good estimate for the size of the project.” It was about then that my manager presented me a nice one hundred page thick functional description of the system to be built. “OK,” I said, never unwilling to please my manager. “When do you need it?” “Well,” he started, “how about in an hour?”
So I started to read through the document. But as functional descriptions go, I wasn’t quite able to grasp the domain of the project. What was it all about? After three quarters of an hour, I wasn’t even halfway through the document, and I hadn’t counted or estimated anything. And when the hour had passed, I didn’t have a single shread of estimation. Now what? That’s when I started browsing the functional specification. All the forms it described were linked to one or more database tables. Moreover, in the appendices of the document I found a data model and I counted the tables.
At that precious moment in time my manager walked in again. “So, what did you make of it?” It was that moment that I invented my first and utterly brilliant formulae for estimating the effort to realize an important piece of software:
Project effort in hours = number of pages x number of tables
Without a blink of an eye, I gave my manager my estimate. Next, he added 20% for developer optimism and walked away happy. It was the best we could do at the time. And if you’re wondering what happened with the proposal; we won and got the project. And in the end, my estimate wasn’t even far off. But I still consider that pure coincidence.
And that’s where my career in software estimation took off.