I’m Sure It Will Only Take You A Few Days To Code

“So the site’s pretty simple, all it needs to do is X, Y and Z. You seem like a good programmer so I’m sure it will only take you a few days to put it together.”

I get emails like this from time to time. The people that write them are almost invariably not technical and working on their first product. At first I got pretty annoyed when people talked like this. Who are they to go around estimating development times? But then I realized, even I am terrible at estimating how long my own projects are going to take. How can I get mad at them if I can’t do it either?

The real reason I’m annoyed is not that their estimate is wrong. It’s that they assume that they can even make an estimate. That’s because as developers we unconsciously realize that the way a layperson naturally estimates complexity breaks down when it comes to software.

That’s not an excuse for being annoyed. But it brings up another more interesting question: why does the way we naturally measure complexity stop working when we apply it to programming? 

To answer this question let’s think about how our brains estimate things. There are some things that are easy for someone with no experience to estimate and some things that aren’t.

Think about watching someone play guitar. Even if you’ve never played guitar you can probably infer from watching a performance of Mary Had a Little Lamb that it’s simple and that the person playing it does not need a great deal of skill to do so. It’s also pretty easy to watch someone play Pachabel’s Canon in D and infer that it is complex and would take a long time to learn how to play.

Why are we good at instantly estimating the complexity of these two songs? It’s because of the way we judge whether something is difficult or easy. Our brains have a few built in tools to do that and the first one is speed. In this case, it’s notes played per second. Notes played per second gives us a really easy, natural heuristic to estimate song difficulty. And because playing a song on the guitar is a physical, sensory activity it’s simple for our brains to measure speed and convert it into complexity.

We also have another natural heuristic: size. Think about a tent versus a mansion. Even someone who has never been to architecture school can tell you that in general it’s a lot easier to design and construct a tent than it is to design and construct a mansion. Why? Because we naturally use physical size as an analog for complexity.

Obviously neither of these are reliable 100% all of the time, but in most cases in life it gets the job done. That’s because in most cases we’re estimating something physical that our brains can relate to efficiently and without prior experience.

Now let’s talk about software. When a non-technical person attempts to estimate software development time they come armed with their two basic heuristics: complexity based on size and complexity based on speed. But what they don’t realize is that software is different. Software is by nature not physical. It exists in the ether. A tiny portion of it shows up on our computer screens from time to time. Because of this when it comes to building web apps (or any type of software for that matter) our basic heuristics break down.

The first one, speed, is essentially impossible to estimate for the layperson offhand. So the natural heuristic they tend to use is size. Some go with number of pages, some go with number of actions or number of features.

Sometimes this actually works! If you’re talking about a static site with a bland design it can be very easy to estimate development time for the layperson. But in general size does not translate reliably into complexity when it comes to software.

Unfortunately, the only heuristic that works when it comes to software complexity is experience. And even that doesn’t work all the time. As a programmer I know I can use my prior experience building similar things to estimate how long each feature will take to implement. Then I add all that up and come up with a rough estimate of when I’ll be done with the project. But the fact of the matter is that in every project there are two or three bottlenecks that crop up during development. These bottlenecks suck up an inordinate amount of programmer time that can’t be reliably predicted beforehand. And so it throws your entire project off schedule by weeks or months.

That’s what someone without experience misses when they try to estimate complexity. They don’t realize that what works in almost any other situation, doesn’t work at all when it comes to software. And so next time you hear “I’m sure this will only take you a few days to code” try not to be annoyed with whoever said it. Just take a deep breath, link them to this post and go on with your day.

If you liked this post you should probably follow me on Twitter. Or check out my startup Airtime for Email. We help you market your products with your email signature.

3 Apr 2012, 11:18pm | 62 comments

  • Ari Hershowitz

    Very good points. Another element that non-developers miss is underlying infrastructure. In some cases, the infrastructure makes otherwise complex tasks simple (e.g. implementing a button on a browser window) or seemingly simple tasks very complex (e.g. highlighting text on a Blackberry). Open source software adds another layer to this: if a library exists that does what you want on the platform you need, a task can become trivially simple to implement, but you wouldn’t know it without searching for the right open source library.

  • PJ Brunet

    A similar thing happens with painting in public. The two most common comments are “I can only draw stick figures.” and “How long did that take?” Some people can’t get their mind out of business and accounting even when looking at art 😉

  • beyroutey

    The reason “it will only take you a couple days” is often interpreted as offensive isn’t because the inexperienced fool is assuming he knows better than you. It’s offensive because it’s assuming that your effort can be bought for a small budget.In other words, I think your analysis neglects the money dimension. If given enough incentive, you could actually drop everything, pull all nighters, and finish in a small time window. In fact, at some point the budget becomes so huge that you could even hire others to get it done on time.A project = time * effort, and effort is a function of incentive (usually financial but could also sometimes be passion). If the budget is constrained, it will take longer, and given an unconstrained time budget, the project will expand infinitely until you stop it (Parkinson’s law).So to me, the right answer when someone says “I’m sure it’ll only take you a few days to code” is “sure, if you’re willing to pay X”. That would help you identify that it’s not just time and scope, but also budget that matters, and there are real tradeoffs to be made. You have a tough conversation upfront, and avoid being dismissive of the laypeople too.For a useful perspective on this, see the orange juice test:http://contrast.ie/blog/the-orange-juice-test/

  • robert carter

    It’s not even the estimation itself that is really problematic. It’s the thing you’re estimating. Is it really fully specified? Have they really spent the time thinking about how people are going to use this thing? What questions the users of this thing might have or, more relevant, the paths they take to get there. And then say they do the thing that is specified. Is it really an atomic process or has the specifier not really asked the question “Now what?”Really good specification development rapidly reaches the conclusion that anything worth building is likely going to take longer than a couple of days to figure out, never mind code.The flip side is the estimation that tries to pad and plan for all these “learnings”. And woe befall the person who actually says “Two days? This is two weeks at least”.Anyway, good article. Thanks for writing it. 🙂

  • Louis Chatriot

    So very true. But having been on both sides of the “developer – biz guy” relation, I think it is also important for us techies to understand why managers (I’m talking large company here) are try to estimate the time it takes. We must keep in mind that this manager is accountable before someone else, someone who will not bear with the “it will be done when it will be done” attitude. Or the manager’s boss understands software but then his boss doesn’t… and so on up to shareholders who really don’t understand.That’s why I always tried to give rough estimates (usually : the time I think it will take times 1.7), and took to explain why a project was off schedule if it was. Relations become much smoother that way !

  • Jeff Kee

    I have both sides of the story. There are times when clients are surprised that a new module or function, which seems simple by “human operation” standards, is much more complex and complicated than expected, based on the existing database model, UI design etc. And then there are the complete opposites (although less common) in which the customer’s expectation of a big complicated upgrade turns out to be a few lines of code.Code & software logics are, obviously, very black and white and to make it as versatile as humans, it needs a lot of extra work. But that also translates, sometimes, into something so much simpler in the computer world.

  • Jan Lukacs

    That’s the exact reason why we decided to build Paymo (a time tracking app) when we were doing agency work. We constantly worked way more then we used to guestimate and everyone ended up being frustrated, including the client.My advice is to use some form of time tracking (whatever fits your workflow) and start form there. It’s easy to justify things to your clients when you have data to back up your claims.

  • webenist

    Worth mentioning is of course this wiki article: http://en.wikipedia.org/wiki/Planning_fallacyFor more in-depth reading search for “planning fallacy” on http://scholar.google.com/

  • Jan Lukacs

    Looks like there’s a bug in the comment system, i closed the a tag 🙂

  • Lee Wei Yeong
  • Criação

    Interesting breakdown of this problem we face from time to time. I will even try to use some of your points next time I find myself in this situation.

  • Saulo

    There are situations, there is no way to run, and have to make some decisions where money is involved. These things appear, independent of your experience….

  • Jonathan

    I’ve been thinking about this the last few days as well. Another problem with estimating software is that there is a vastly non-linear relationship between the visible elements someone wants and the amount of code required to produce them. These days almost all software is built from a huge collection of building blocks. If you can assemble those blocks into the shape that suits the project then things will go rather quickly, whereas if you have to chisel some blocks, find a different color material, and maybe invent an entirely new type of keystone then things are going to take an awfully long time. The thing people often fail to realize is that the two end-products may be _almost_ identical on the surface, and only an experienced mason can tell the difference ahead of time. And it really can be the difference between a week and a year.

  • Rodolpho

    The point around ‘experience’ being the basis for good estimations is really good. You can use it to infer other hypothesis like: if experience determines time, and time being an important leg of the time-scope-cost project tripod, experience affects the balance of the tripod, thus the balance of the entire project. Or, hiring experienced professionals can not only protect the tripod, but add enough value too it to the point time is shortened, cost is reduced for the same scope.

  • Brett Gibson

    Next time, just ask the “estimator” to show a how they arrived at their numbers. It should fall to pieces quickly after that.

  • lukew-od

    +1 on Brett’s comment – who estimated the estimation, was their methodology driven by objective assessment of spec or simply by their own deadlines? It’s rarely as simple as one or the other..

  • Andrew Wang
  • Mom

    Great points. Most likely it is just wishful thinking that the complexity is underestimated. They just hope it will be easy for you to do.

  • Mat

    Answering to beyroutey’s comment:”In other words, I think your analysis neglects the money dimension. If given enough incentive, you could actually drop everything, pull all nighters, and finish in a small time window. In fact, at some point the budget becomes so huge that you could even hire others to get it done on time.”And there goes oversimplification of the problem again. It doesn’t work that way! You can hire 9 pregnant women, still they won’t deliver your baby in 1 month. I find amazing that people still believe money can buy project time that way.

  • Terry A. Davis

    God just said, “Scum evolution hilarious.” I shrugged.

  • Olivier

    Your guitar exemple is not good: when I was 10, I try to play guitar for the first time. I hab been very confuse to do not play like roll&roll stars at my first try.Since I never play music, I’m completly unable to see if a music is hard to play or not.

  • nickhoggard

    The other thing you do have to remember about clients such as these is that their viewpoint is often skewed, given that they all raise very, very smart children. A number of times now I’ve encountered a client with a very similar estimation skill that that described here, only to have them explain to me that their “9 year old son could get this done in a faction of the time”. Can’t figure out why they’d be looking for a professional if their children could do the job, but oh well …

  • Aristotle Pagaltzis

    @beyroutey is closest to the real reason that “I’m sure it’ll only take a few days” is offensive, but I think no one nailed that one yet.It’s because inherent to that statement is an assumption that what developers do can’t be all that difficult. There is often an implied sense that “if I knew how to click the buttons you click then I’d just do this myself (but I’m stuck having to deal with you so here I am).”Some of them learn to appreciate what you bring to the table, but many of them never do.

  • Craig Byren

    One thing we always try is to provide a minimum that we think we can deliver something that can actually do what the business requires (eg. a simple, functional vanilla solution) – we also show examples of what vanilla looks like…. this estimate is usually quite conservative and allows for the unanticipated complexity (anavoidable). Then we try to get a budget (time and money) larger than this minimum and using an agile approach – deliver within the budget … with the client deciding along the way when they want to ‘stop’ with adding trimmings and extras…. this tends to work pretty well but does require a level of trust between developer and biz.

  • Bill McAllister

    “JUST”==> 4 letter word

  • Timesheetmaster

    I am sure if proper facilities are provided programmers will work out their best and get the coding in no time. It all depends on their mindset, when they have some peace of mind, they would do the task better than anytime, what do you think?Project Tracking Software

  • brettlee

    Thank you for sharing this information this post is very useful. Airport Taxi Oakville

  • zudisht

    Your article is wonderfullthanx for sharing this. Pensionskasse

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | 角落 | Stay Away

  • Pingback: ClearCove Software Inc. – I’m Sure It Will Only Take You A Few Days To Code – dan shipper

  • Pingback: DC. » Blog Archive » Don’t estimate software

  • Pingback: I’m Sure It Will Only Take You A Few Days To Code » CodeCube

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | HTML5工作室

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | JSUED ·前端开发· 视觉设计· 交互设计· 用户体验· 界面设计

  • Pingback: 不懂技術的人不要對懂技術的人說這很容易實現 | 電燈柱の部落格

  • http://twiiter.com nick jonson

    it will take you a year to lrean to code then you can code in five days

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 - 天天软件吧

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 - Sina App Engine - 开发者问答

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | KSJO FM92.3

  • Pingback: Hand Curated Readings on Design, Web and Startups – Week 3 by Self Brewed Coffee

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | IT博报 | 实时、前沿、分享

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | 挨踢小胖的博客

  • Pingback: 不懂技術的人,請不要對懂的人說這很容易 - Inside 硬塞的網路趨勢觀察

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | 陈学虎

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 - 博客园

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | 易鸣

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 – Miracle_lucy | 查问题

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | 等风来

  • Pingback: 黑色 – 不懂技术的人不要对懂技术的人说这很容易实现

  • Pingback: 不懂技术不要对懂技术的人说这很容易实现 | 我爱互联网

  • Pingback: 不懂技术不要对懂技术的人说这很容易实现 | | Evolution Unit 进化Evolution Unit 进化

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 | 大网

  • Pingback: 不懂技术不要对懂技术的人说这很容易实现 « ITPark

  • Pingback: 不懂开发请不要说这很容易实现 - Noblog其他 | Noblog

  • Pingback: 不懂技术不要对懂技术的人说这很容易实现 | 乐说

  • Pingback: 不懂技术不要对懂技术的人说这很容易实现 - 安度博客安度博客

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现-TC部落

  • Pingback: 不懂技术别告诉懂技术的说这很容易实现 | 弱水三千

  • Pingback: 不懂技術的人,請不要對懂的人說這很容易 | DUKECAT DESIGN

  • OK Michener

    my company was searching for Shipper’s Letter of Instruction yesterday and encountered an online service with a searchable database . If people are looking for Shipper’s Letter of Instruction also , here’s a http://goo.gl/azJaII

  • Pingback: 不懂技术的人不要对懂技术的人说这很容易实现 - 行业资讯 - 代码豆


Never miss a new post