Software Estimation is Hard
Posted Wednesday, April 4 2012 by jonathan
I stumbled across a blog post this morning by Dan Shipper that riffs on one of the classic challenges in software: How Long Will It Take? This has been in my mind a lot recently, and is something we talked about at BarCamp Portland during a session on how to learn programming.
In my opinion there is one aspect of software development that is far harder for non-programmers to accept than any other. The apparent complexity of a product based on it's visible surface has a highly non-linear relationship to the actual complexity. Almost universally, when we build software we are assembling a large collection of pre-cut building blocks into a finished product. Some products can be assembled with a little mortar and almost no custom cuts while others require us to re-cut the blocks, invent a new kind of keystone, or even find a whole new quarry.
The challenge is that only someone with experience building many products can tell up front which type of project it is. To continue my strained building analogy, there is just no way for an inexperienced person to know that making the hallway 6 inches wider means you will need to re-pour the building's foundation. That's how non-obvious software is.
As a little example, let's look at toolbars in iPhone apps. Apple has a beautifully designed toolbar that you can use in any app. It comes in shiny black, translucent glassy black, or gray; and has a pre-ordained height. You can add buttons to the toolbar with text and/or a number of icons that all fit well aesthetically. Placing and wiring up a toolbar might take an hour or two of my time, depending on exactly what it needs to do.
Now, let's say you want that toolbar to be green or you want an icon on a button that isn't one of the standard icons, or you want to make it 20% taller.
Well, changing the color only takes a few minutes but the icons and buttons were designed to coordinate with the standard colors. Depending on the shade of green you choose you may or may not need to get a designer to render a new toolbar, button template, and icons in Photoshop, in 3 or 4 different styles (remember: buttons can be active, disabled, pressed, etc. and each of those has different visuals). That could take an hour or 10 hours depending on the design.
Making those non-standard button icons takes time and requires both information design and visual design skills. You'd better make sure the icons communicate their utility and fit in well when sitting next to Apple's standard icons.
As for making the toolbar 20% taller? The standard toolbar doesn't do that, and everything from the icon design to the way the device measures the conductivity of your finger tip on screen has been fine-tuned to work with the exact size of that toolbar. Apple has invested hundreds if not thousands of hours designing that toolbar at that size. They have reasons for choosing 5 buttons across and 44 pixels in height. If you want to change that you're going to have to invest an awful lot of time cutting and fitting a new piece of stone, and odds are it won't really match the color and texture of the stone around it because those came from a different quarry and a different mason.
You may find that it's better to live with what Apple gives you. If not, I hope you can see that you're going to at least double the amount of time required and you may be turning an hour of work into a week.
I don't want to make excuses for inexperienced or lazy developers who grumble and rumble about non-technical customers being hard to work with. It's not a Baron's job to understand engineering. Just realize that what looks like an insignificant detail can have a huge impact on the complexity of implementing a product. You should expect the engineering team to ask how important seemingly inconsequential elements of your design are and work together to make informed decisions about them.