Can We Code Without Estimates?

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:


* 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.



  1. Ted M. Young (@jitterted):

    One of the best things I learned from my Agile Journey is the definition of “done-done” (and breaking things down into very small pieces). With that, I knew when I could stop. Previously, I’d keep writing more and more code, making sure that I had covered any variations and possibilities (or at least what *I* thought were possibilities). With the “done-done” goal in mind, I don’t need to estimate, I just keep writing tests & code until I’ve met the goal. Once it’s met, I stop.

    However, businesses/customers may need estimates (in order to “plan”), typically because *their* users/customers need estimates (to plan) and so on down the line. Jump to the end, and often you find out “oh, that was just an arbitrary date”, though sometimes you find out “yeah, we need it on that date because we have to coordinate with marketing/sales/training/other non-just-in-time things”. Most of the time I’ve found that it’s arbitrary and, in that case, just reduce the features to fit the date. “Oh, but we need to tell customers what’s coming!” Why? “Because, otherwise they won’t buy our current release!” Well, perhaps that’s true, but maybe it’s not, I’m not sure.

    Anyway, in my mind estimates have nothing to do with the creation/production of software. It has to do with the rest of the business for planning purposes. If you’re flexible (dare I say Agile) in the rest of your business processes, you’ll have much less of a need for estimates.

  2. Ben Zuill-Smith:

    I agree with you Woody. I thought back to my first job and remember that our project ran twice as long as it estimated from the beginning, but because we took a more Agile-type approach and showed the customer value each week, they kept us and even signed a contract for another large project after the first was finished. The estimate was pretty much worthless, and they were happy to see the incremental value instead.

  3. David Wright:

    I don’t know people, I just don’t know. I think agile and time boxing is good for software that is going to be a product for sale, or utility that people use, but a lot of software is not that anymore.

    Companies use software-based information systems to run their business, and that includes companies that sell software. I am not that concerned about planning, but it is cost that business people do have to worry about. You need an MRP system to support your manufacturing, you have to know what it will cost, buy or build, to know what your overall unit cost is as part of pricing. No VP of Manufacturing is going to accept a new software project without knowing the cost, and then how long it will take.

    I am not saying it is easy to do, and delivering in phases with a transition plan from old to new is a way of doing it that allows for intermediate estimates and opportunities to change plan/direction as you proceed.

    Yes, I am sure Hewlett and Packard, or Bill Gates, or any other tinkerers that started small didn’t do estimates, because they were starting small. At some point they had to produce a product before they ran out of money, and lots of tinkerers never got out of their garages for that reason (let alone bad products).

    But software is spread across our world today, working when we don’t even realize it, mission-critical stuff, can cripple a company if it fails. I hope people who build it do estimates, along with a lot of things like requirements and design, before I get on their passenger jets, or pay my bills online.

    To reiterate, you can do a lot of things without estimating, but that doesn’t mean you always should.

  4. Woody Z.:

    Hello David – Thanks for commenting!

    Well, I know that it is common to think that it’s necessary to know what it will cost to create software we need. It would be great if we had some reasonable way to do that, but I don’t think we do. So, if that is true then it would be useful for us to consider alternatives. I’m sure to write more about why I don’t think we can make useful estimates sometime soon when I get the time.

    For the moment, I’ll just say this: I know by experience that there are Vice Presidents of Manufacturing, and similar other “high level exectutives” who are not only willing, but absolutely thrilled to “accept a new software project without knowing the cost, and how long it will take”. Why would a VP be willing to do this? One reason is that Agile Software Development gives us a way to create and deliver software incrementally. Once it is understood that software can get into use quickly, and that it can be expanded on and enhanced regularly (weekly or even continuously) it is a real “game changer”. Equally important is that the “execs” get a lot more truly useful software for the money spent, and they get a much better set of functionality than you can get with a predicitve approach. The ability to redirect effort when needed features or priorities change is an added benefit.

    I don’t understand your point about the mission critical stuff. How do estimates help with that? In my opinion, estimating brings no value to the actual software – it’s intended use is for managing some part of the process, but not for making the software itself better or more robust, safe, or fit for use. An estimate is a calculation or judgement of the cost/effort/time/whatever to do something. I have never found that I need to do that to create and deliver working software.

    Cheers! – Woody

  5. Sven:

    I think you are right that we do not have to estimate in order to get ready for implementation of a software. But still I guess you did estimate without even noticing. After all you we aware of the time you could spare for programming, a couple of hours, a night… just short periods – and you then looked at the stories (functions) that you thought you might be able to code in this predefined timeslot. Did you ask yourself what would have happened if you were not able to get this small stuff working in one night… or even after working every night of a week? Your estimation saying that you probably could code the ability to enter checks in short time would have been wrong. Odds are that after some time you would have started to think that the ROI of your project was not good enough. It might take just a ccouple of coding sessions or a year to reach that point, but you would have reached it.

    After all that is what we try to do with estimations in agile. OK, there are some differences. When working in teams people need some way to talk about their estimations. Call it Story Points or whatever you like. For complex functionality they might not agree on the sizes. This could be because the experience levels, the way they code or something else is different. Defining sizes will enable them to talk about that. But developers use these estimations themselves – just like you did. They check if they can do it in reasonable time or if they are facing problems during implementation.

    And then of course you were working for yourself. In a perfect world developers would do so – as they would be motivated by their success of delivering working software for the product they are crazy about. In reality however they often will not identify with the product (which in my opinion is bad). They will be working for their bosses who then are checking if the ROI is sufficient. I think we should try to change this attitude / culture by setting up companies owned by teams being committed to the product. Those companies will not really function with hierachies. Developers wouldn’t feel bad about managers trying to find out if they are on track. Take a look at startups or companies like Valve – they are trying to do that and they are quite successful – but this is another story…

  6. David Wright:

    Estimates are important for ‘important’ software because you need to do more than just code, and you want to know how long it will take and cost; if you don’t, I want to work for you. Business cases, scoping, requirements, design, architecture. You might argue this is ‘old’ thinking , because you don’t always have to do it, but there is a lot of cases where you do. And in the end, horror of horrors, the solution may not be new software development: re-use, buy, as well as dev are options – “re-use before buy, buy before build, build for re-use”. It is about solutions, and getting the best solution at the least cost in the shortest time. If you get to actually code in such a project, go agile for sure… but some end date will be in the mind of the person spending the money.

  7. #NoEstimates Part 1: Doing Scrum without estimates |

    […] Can we code without estimates? – Woody Zuill […]

Leave a comment