Can we write code, create software applications, without doing estimates*? I think there are at least some cases where estimates are not needed.
In The Beginning
I bought a computer in 1982 or 83 for the purpose of managing aspects of a business I had. My business was essentially a small custom manufacturing business of sorts, and I had very little money. No capital, just cash flow. I would sell some work, get a deposit, buy the materials and supplies for the work, do the work, get the balance on delivery, pay some bills, pay the rent, and go on to the next job. Every hour I had was needed to earn money, or support the overhead of doing business. Additionally, I would spend some time improving my capability to more effectively make money, reduce costs, or “take care of business”. Payback for that time needed to be quick, not in two weeks, but in two days, or two hours. Every penny counted.
So I now had a computer, but none of the software I bought worked well enough to help me. I wanted to do simple stuff – like mailing lists, simple bookkeeping, making estimates for manufacturing jobs, writing invoices – stuff like that. I also wanted to do some very specialized things, like controlling devices: material cutting plotters, measurement devices, and imaging equipment. But software was expensive, and it was mostly useless in those days.
Computers can help us do bookkeeping, right?
One important reason I wanted a computer was to keep my books. I wanted to spend less time doing my bookkeeping. I had bought an application that was supposed to do simple bookkeeping: Keep track of money spent, allocate it to varioius accounts, keep track of the checkbook, reconcile the checkbook, do income and expense reports, profit and loss reports, year end stuff, and so on. Trouble was – it didn’t work well at all. It was difficult to use, made mistakes, and the data got corrupted after a couple months of using the application. It was truly useless and worse: it wasted a lot of my time. I tried several other applications that friends of mine were using – but none of them made things easier than doing the work by hand. I wanted my computer and software to save time, and make it easier for me to focus on getting and doing work. It wasn’t able to do that.
Earn as you Learn – Or At Least Try
So I decided to try writing my own “bookkeeping application”. It’s just numbers, right? Computers work with numbers, right? Shouldn’t be too hard. Before we go any further, I’ll “skip to the end” and let you know: It was not hard at all. It turns out that computers ARE good at working with numbers, and you just have to find a reasonable way to let users interface with the computer, and some way to show stuff on a screen, and some way to send stuff to a printer, and some way to save data to a disk so you can use it the next time you want to work with it, and some way to do the calculations and other work actions. These are all easy things.
I had no experience writing applications at that time beyond some games and little text editing apps and similar things that came from books I was learning from. For my first project I needed something that would return back the time I spent right away. Seemed the checkbook part of the bookkeeping app would be the place to start – you need to put expenses and income into the system before you can do much else, and it would save me some of the time it took to do that work by hand.
A Simple Checkbook Application – Find A Small Bit Of Potential Value
Balancing a checkbook is easy enough, it took me about 2 hours a week to do the hand entry of checks and deposits into the paper system my accountant had set up for me, and to update the balance. It also took about 3 or 4 hours once a month to reconcile the checkbook. I had always made mistakes in entry or calculation, so sometimes it would take longer. I was spending about 11 to 14 hours (or more) each month doing the paperwork for my checkbook. There was no Quicken in those days.
If I could write something that would allow me to enter a check into the system, enter a deposit into the system, reconcile the registry, catch mistakes, correct mistakes, and print out the details – that would save me 11 to 14 hours every month. Well… not really: It would take some of my time to do the entry of checks and deposits, and to review the output, and correct mistakes. So there is the value: A time savings of perhaps 8 hours a month.
I had NO IDEA how much time it would take to write that software. I had nothing to base it on. It seemed worth a shot, but I had no way of knowing that. The only sure things was that I’d learn a bit more about programming. The key is: I had identified a small chunk of work with POTENTIAL value.
Learn By Doing, Decide Based on Real Time, Real Value
So, I had a vague idea about value. I figured I could put in about an hour each night and I would soon learn if it was worth trying to write this code. In doing the work I would learn the things I needed to learn to do the work, and I could make decisions about the value being delivered. At any point I could decide to cancel the project or keep going. The decision would be based on value delivered for time invested. NOT value that MIGHT be delivered for time that MIGHT be needed. That seems like a bad way to make decisions to me, at least in some cases. Real value, real time. Take action, make decision, take action, make decision. A small amount of real work delivers enough value upon which to make a decision. Deliver early, then decide: Should we do more, or try again, or change directions, or expand or reduce… whatever. Baby steps every step of the way.
The First Bit Of Functionality: Data Entry
The first value I could see: Ability to enter in checks (number, payee, date, amount, etc.), save as a file, and print it out on paper. This would be exactly what I was currently doing with pen and paper, and I could do the totals by hand with a calculator just like I had been doing. So that is where I started. Not much value, but provided a way to “amplify learning”.
Now, it seemed that this “functionality” could be “written” without writing any code. The user (me) could just use the existing text editor to type in the data in a specific format. How long did it take to code that? No code, no time. I just needed to define a format. How robust was that? Not very! It would be easy to make mistakes in data entry – but I needed to get real functionality quickly. Same old same old. That’s software development, so I’ve learned. Once the code is in use the most painful stuff will be revealed, and we can fix that first. Might never need to do anything more than the minimum. Try to keep it that way.
Writing to a file was easy enough. What to do next?
I wanted to calculate the balance of the checkbook. I would be very close to having something truly useful if I could do that. That would require that I take into consideration deposits as well. That was easy to do, of course. Deposits are positive, checks and withdrawals were negative. Or something like that.
Again, I had only an hour a night or so to spend on this – so everything was very “bare bones”, but reading the file, reading the records, and accumulating a total was easy enough. And essentially, the application was ready for production. It was useful. Lame, but useful. Value was delivered, and it showed the project was viable. There were a number of features to add before it would be “easy to use”. I still often made data entry mistakes, but I could fix those by simply opening the file with the text editor and making the needed change to the data. Over time, I added much of that functionality, and eventually it became my bookkeeping application. The development was paid for by the time I saved every month.
So, that was the start – No Estimates
I don’t think I did any estimates in this work. If you think I did, please let me know and I’ll clarify the process. Or maybe I was wrong!
The process for me: Choose something of potential value, find the simplest thing I can think of, and try to do it. If it works, I go on to the next bit that seems to have value, if it doesn’t work I try something else. Repeat until the payback doesn’t seem worth it anymore – at which point I can move to another “project”.
This is a very minimal example. It’s real, and it is where I started. I used this same basic pattern to write a lot of software for myself over the next 15 years. I never had a need to estimate anything. I didn’t even think of making estimates. Someone once told me that necessity is the mother of invention. I’m not sure about that, but I just haven’t had enough time to waste on inventing things that I don’t need.
I’ve used this same apporach on much larger projects, in various situations, and with a number of different projects types. I think some form of this approach can work for just about any project.
Please don’t yell at me
Before you start yelling, and before the veins start popping out on your head, please understand: in this post I AM NOT SAYING THAT ESTIMATES ARE NOT NECESSARY FOR MANAGING SOFTWARE DEVELOPMENT in your situation. I am simply saying that estimates are not needed for designing, coding, testing, and delivering software into use.
The process you implement for managing the business of making software might require that you do estimates. But that necessity has nothing to do with writing software – that necessity is imposed by people who haven’t yet invented a better way to manage their software development, their customer interactions, their collaborative abilities, etc. Maybe you can find a better way. Maybe there isn’t a better way. Regardless, if there IS a better way, maybe you can take a tiny step every day that moves you to a better process that does not require that you do estimates. That’s up to you.
Can We Code Without Estimates?
Still, I hope you can agree that we can write code without estimates. If you don’t think we can, I’d like to hear about it – especially if I am wrong or am missing something.
Some other posts I’ve written on the topic of estimating:
NOTES:
* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.
Disclaimer: There are many situations where estimates can be meaningful and useful. This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.