Estimating front-end development
Just after I had begun to work as a front-end developer in 2005, my manager started to ask me the question: “How long it will take you to implement this?” It was apparently easy, but I had been always failing to give the correct answer. However, my manager was smart enough to figure out the real numbers from the ones I gave him. He just multiplied them by the factor of 2. Thus the infamous Szafranek’s constant was born.
Szafranek’s constant equals 2
Soon thereafter, I applied this breakthrough discovery in my estimations. And a strange thing has happened: I was now able to provide correct numbers when asked for the time needed for a job. Though I regained some credibility, the damage was done and Szafranek’s constant is still a running joke among people I work with.
Proper estimation of front-end development tasks is hard and for any but the simplest tasks just applying the constant is not enough. How to estimate correctly? And first of all:
Estimation doesn’t sound too cool for the impassioned and young. Isn’t it better to start banging out the code right away? Well, surely, but unless you have unlimited amounts of time and money, you’ll need to face the reality and evaluate how much of the resources you need versus how much do you have. You’ll need to perform the estimation exercise whenever:
- You work alone as a freelancer. Your estimation will determine how much time you’ll need for the new project and how much you should charge.
- You work in a team. Other people (back-end developers, graphic designers) depend on you. They need the timelines from you to plan their own work. Most likely there’ll be also a manager over your neck, asking how much time do you need for this new task, so he could prepare a project plan and report the date to his boss or the customer. And if you think your manager is pesky about the dates, be assured that if he won’t ask you, he’ll come up with the (wrong) numbers himself. The results will be much more disastrous. For you.
Regardless of the context, you need to learn estimation fu to establish credibility. After all, people will like to work with you more if you’ll keep your own word.
Let me share with you few tips that I learned the hard way during the last few years. Let’s imagine a scenario: you work in a team of few people, building a simple web application. You have the vague idea what it will do, but the requirements are far from deserving the noble title of “specification”.
Lesson 1: Estimation takes time
This is probably the single most important fact about estimation. If you want to get any helpful numbers, you need some time to think about them. So if you are asked a question “How much time do you need to implement the user interface for this simple web application?” and you’re expected to provide the numbers immediately, they are unlikely to be relevant.
Lesson 2: Break it down
What you need the time for? To break the project into managable tasks. Don’t even think that a 2-week task is a managable one. The following quote from Getting Real nails it down:
Estimates that stretch into weeks or months are fantasies. The truth is you just don’t know what’s going to happen that far in advance.
So shrink your time. Keep breaking down timeframes into smaller chunks. Instead of a 12 week project, think of it as 12 weeklong projects. Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time.Getting Real: Shrink Your Time
I approach this analysis by drawing a user’s page flow. This a simple diagram showing what screens the application needs to have to satisfy all the tasks the user can perform, from start to finish.
This method is very user interface-centric and likely to underestimate graphic design and server-side development. Thus the next lesson is:
Lesson 3: Don’t do it alone
Unless it’s a one-man project you’re working on, the work breakdown can hardly be done by one person. I usually do it together with the back-end developer. This second person is able to spot missing elements on the page flow.
The page flow is a good starting point, but it doesn’t cover every activity in the project. If you’re a front-end developer, you also need to consider some common but often forgotten site elements:
- error pages
- print version
- mobile version
The list could go on, depending on the project and split of the roles. For instance, in my team front-end developer is also responsible for prototyping. Together with user testing this activity can take significant part of the project time. If you’re a project manager who wants to estimate the whole project time, you must also consider graphic design, data model design, server-side development, testing and a whole lot of other activities. It’s a topic for a book, not a blog entry. In fact, more than one book, as the search for software estimation on Amazon confirms. For the sake of the exercise, I’ll focus here on front-end coding only.
Even in this area it’s easy to fall into:
Lesson 4: Common pitfalls
Software developers are widely affected by a disease called optimism. Front-end engineers are no exception and I don’t exclude myself. It’s hard to find a developer who is not overly optimistic about the timelines and complexity of his tasks. 80 percent completion syndrome is very typical for this reality distortion: regardless when do you ask the developer how much work on the task he’s already done, the answer is usually around 80%. It’s fine after first day of the development, but too often the same answer is given on the deadline. “Only few fixes here and there and it’s done.” But it’s usually these “few fixes” that take most of the development time.
If you play an optimist in order to be nice to the manager or the customer, be asured it will backfire at you when you miss the deadline. I know at least one company where people are expected to give unrealistic estimates and cross the deadlines. But if the project manager respects himself and his people, he will treat underestimation as a mistake, not a rule. In that case developer is obliged to do his best to provide honest estimates. I’m lucky to know at least one other company that follows the second path.
How to avoid the trap of optimism and provide realistic numbers?
Development is more than just writing the code
This simple realization was something that helped me to recover from undue optimism. My own estimates were usually wrong because I didn’t consider work other than coding. But that work still needs to be done to finish the task. For a front-end developer it includes:
- Problem analysis and solution design. It’s the essence and the hard part of software development. It’s, basically, thinking. Because results of thinking are not very tangible, this part tends to be underestimated. However, it still needs to be included into estimates if they are to be correct. A proven way to make this activity more transparent is to create prototypes. One of the cool things about prototyping is that it forces you to think about the problem and allows you to experiment faster than you’d do with the fully-blown code. It’s also more effective than vague discussions or writing the documentation prose, since usually people think more effectively with visual aid than in pure abstract terms. Of course prototype could be an overkill for small tasks. In that case just make sure you have enough time to think about the problem, not only to code it.
- Communication with server-side developers and graphic designers. Especially in ajax applications server and client side are deeply intertwined. On the other hand, image files often require explanation or fixes before they can be implemented.
- Interfaces with other code. The more complex the application is, the more time is required to make sure that newly added piece of code won’t break some parts of it. It’s especially true for CSS which is highly reusable and thus can easily break a lot.
- Documentation is one of these things that everybody praises, but nobody does. If you won’t plan the time to write it, it won’t appear magically.
- Novelty. Unless the application you write is just another version of what you wrote a hundred times, you will need some time to research how to re-use other people’s code or write it by yourself.
Lesson 5: Try, fail, repeat
Taking all the above factors into account results in much stronger connection between estimates and the reality. It allows developers to provide project leader and other team members with numbers that can be actually used for planning. Still, developer’s input alone doesn’t automatically produce the delivery date for the product. Sicknesses, unpredicted hardware failures, sudden requirement changes and Jupiter phases will probably wreck the initial schedule anyway. In that sense software development is not far from the warfare:
In preparing for battle I have always found that plans are useless, but planning is indispensable.Dwight D. Eisenhower
The good thing is that with each project you should come up with more sound estimations. Reality will always have the nasty property of surprise. But the experience you get through failures will allow you to reduce your own magic factor to a value smaller than the infamous 2 (or even more). If you repeatedly achieve the factor of 1, you can begin writing your own book on software estimation and future-telling.
The true value
Eventually, the value of estimation doesn’t come from predicting the future. Though vital in this business, it’s far from reliable predicting. But it forces you to think about the problem, analyze it and, eventually, solve it.