Tag: Estimates

Categories
Software Development Web Design

The Golden Rule of Web Design Implementation, Part 2

This is part two of The Golden Rule of Web Design Implementation. In part one, we learned that pages aren’t views, and that thinking in terms of views is much more beneficial. Today we’ll wrap up our analysis by looking into development.

As you may recall from Monday’s post, the Golden Rule is:

The time it takes to implement a web design will always average out to one view per day.

Our first corollary was related to views. The second is about development. Or more specifically, developers.

There’s a reason I put that always in there. It’s to remind myself (and you) that this rule can stand up to a lot of variables. As I’ve mentioned already, the technologies being used and the platforms being targeted are irrelevant. Plenty of other things are too. But what I found most interesting was this:

The developer’s skill level doesn’t matter.

This is counter-intuitive. If a weak developer needs an average of one day to implement each view, then shouldn’t a more experienced developer be able to get those same views done faster? The answer is no. In fact, it will take a strong front-end developer and a weak front-end developer about the same amount of time to implement any given design. We’ll get to why in a moment, but first let’s clear up some definitions:

  • By weak front-end developer, I mean someone that knows the basics of front-end development in the technologies being used. That statement above is obviously false for someone with zero experience.
  • By strong front-end developer, I mean a real ace. Someone that can put “HTML/CSS Expert” or “Adobe Certified Flex Expert” on their resumé without exaggerating.

All set? So how is it that a below-average developer and a bonafide expert will require the same amount of time to implement the same design? It all comes down to the perceived level of what constitutes a correct implementation. In other words:

Better developers don’t code faster, they code better.

Picture a standard HTML/CSS implementation. The design is there, and you hand it off to your weak developer and your strong developer, and tell them each to get to work. After X days (where X is the number of views, of course), you get both implementations back. Here’s what you can expect:

The weak developer will have done exactly what you asked. The pages will look just like the mock-ups, pixel for pixel, and work as intended. There will be nothing wrong with the design from a typical user’s point of view.

The strong developer will deliver an implementation that looks about the same. Surprised? Don’t be. That’s all these two implementations will have in common. Let’s look at some things the guru probably did that our weak developer didn’t even consider:

  • The HTML and CSS both validate, with no errors.
  • Each page has a proper doctype.
  • There is a clear separation of structure and presentation.
  • Accessibility has been accounted for wherever possible.
  • The HTML is semantically clear, and would be easy to restyle.
  • The CSS is beautifully minimal, and optimized for maintainability.
  • There are <noscript> blocks for users that don’t have javascript enabled.

Do you see the difference here? On the surface, it’s barely noticeable. But just beneath that surface is a trove of quality that goes far and beyond what was asked. To the guru, this isn’t even extra work. This is just how HTML and CSS are used.

Don’t blame the developer.

You may be thinking: “The guru shouldn’t waste time doing what wasn’t asked of him; he should be able to translate that extra time into finishing the implementation faster.”

Please don’t ever ask this of your developers.

Would you ask a master carpenter to build a simple chair as quickly as possible, and not “waste” time without worrying about quality, durability, ethics, or craftsmanship? Of course you wouldn’t. That’s simply not how experts work.

The solution to this problem is simple: choose the best developer for the job. If you don’t care about the internals of a deliverable, assign a developer that has lots of room to learn. If the project requires some baseline level of quality, consider a developer that is better versed in the fine art of building interfaces. Only call in the guru when the project requires an unmatched level of care.

And remember that no matter how hard you push, and no matter which developer you choose, you’ll never beat one view per day.

Categories
Software Development Web Design

The Golden Rule of Web Design Implementation, Part 1

Hi folks! Today’s post was so full of awesome that I had to split it in two. This is part one, about views. Part two is about development.

Estimating is hard, and I hate doing it. But I have a trick.

Specifically, I’m going to talk about how to estimate the implementation of a web front-end project. Maybe it’s a UI refresh for an existing web site, maybe it’s a new take on e-commerce, maybe it’s one of those new-fangled web-apps… it doesn’t matter. As long as you’re implementing a relatively well-spec’d-out design, this rule will work every time.

Oh, and the technology doesn’t matter either. It can be HTML/CSS, with or without JavaScript. It can be Flex, it can be JSP or ASP or anything else. As long as you’re not doing any significant back-end work, this truth still holds.

This is really important so I’m going to write it in a really big font:

The time it takes to implement a web design will always average out to one view per day.

So if the design has 16 views, the implementation will take 16 days.

There are two interesting facets to this rule. Today we’re going to talk about the first one, the significance of the term “view”.

Views != Pages

This is an important distinction: it’s not about pages anymore. We’re past that. We have bigger monitors, and that means we can have more elaborate pages. In fact, we often put several views on the same page, just because we can.

Imagine you have a page in a standard two-column layout. The main content is one view, that’s obvious. What about the sidebar? These days, if it’s anything other than nav, it’s probably also an independent view. Even the main content can be more than one view, if it separates logically and especially if part of it will be re-used on another page.

Of course, not all views are created equal. Maybe the sidebar view in our example is a lot less work than the main content view. That’s bound to happen, and it’s fine. The rule states that this will average out, and believe me, it will. For every super-easy “only took an hour and a half” view you find, you’ll get stuck with one that takes nearly twice as long as it should because you hit some silly browser compatibility issue.

Get used to thinking in terms of views.

There’s another reason for looking at the design in terms of views: That’s how implementation works. You start with the overall page architecture, build out a grid or column structure, and then tackle each distinct view one at a time. The developer’s standard divide-and-conquer approach.

Doesn’t it make sense to estimate the same way? By considering the design in terms of views at scheduling time, you’re estimating the same chunks you’ll be implementing. This will lead to more accurate estimates.

It will also make your estimates easier to defend if they seem too high. Write out a list of all the views in the design, and say “this is a breakdown of the implementation in one-day chunks”. If there are 12 chunks, that’s 12 days. You don’t even have to use the term “view”.

By throwing away the pages metaphor and instead thinking in terms of views, you’ll get better estimates that are more accurate and easier to track, and easier to explain to others.

There’s still more to learn!

We’ve only looked at the first interesting corollary from the Golden Rule. In part two, we dig even further to reveal the secrets of development.

Categories
Software Development

How Much Longer will it Take?

Let’s talk about re-estimating software projects. Here is a situation I find myself in every now and then:

Say I’m the lead/best/only developer on a project, and partway through that project, we realize that we’re going to miss an important deadline. My manager will come to me with a question that I absolutely dread:

How much longer will it take?

It’s a perfectly fair question. Since I’m the lead/best/only developer, I’m in the best position to estimate how much more time is necessary, and my manager needs this information to make important decisions (add more people? talk to the client? etc). But it’s extremely difficult to answer! If the initial estimates (which I either came up with or approved) are wrong, how am I supposed to magically come up with better, more accurate ones?

The most important thing is to not answer on the spot; a great manager once told me that the best answer any time anyone asks you for an estimate is always “I’ll get back to you” and he’s completely right — there is absolutely no way you can put together a sensible estimate off the top of your head. Ever. You’ll always have to do a bit of math and take a few things into consideration, so give yourself time to do those things.

Now, let’s talk specifics. There are three main approaches I’ve seen myself and others use to re-estimate a project. For the following examples, let’s pretend that you’re in charge of a project that was initially estimated at 10 weeks, and after 5 weeks of work you find yourself 1 week behind schedule. How much longer will it take?

The Naive Method

The knee-jerk reaction that you might even say out loud if you answer on the spot is that you’ll need 1 extra week for a total of 11 weeks. The naive thinking here is along the lines of: “hey, we’re 1 week late, so give us 1 extra week to make up that work and everything will be fine”. The problem here, of course, is that if you have been late on your initial estimates for the first 5 weeks, you’re probably going to be late on your initial estimates for the next 5 weeks as well. We need to account for more than just the time missing so far. This brings us to:

The Logical Method

You may be thinking that the correct answer is 2 extra weeks for a total of 12 weeks, since if you need 1 extra week after the first 5 weeks you’ll probably need 1 more extra week on the 5 remaining weeks. That’s no longer a naive answer (it’s indeed logical) but your math is flawed and we can do a bit better.

Look at it this way: it took 5 weeks to do 4 weeks’ worth of work. So after 10 weeks, we’ll have done 8 weeks’ worth of work. Historically, if 4 weeks’ worth of work takes 5 weeks, then that last 2 weeks’ worth of work will actually take 2.5 weeks. So what you should be asking for is an extra 2 weeks and 3 days (always round up) for a total of 12 weeks and 3 days.

Now we have an entirely logical answer, and by all accounts you should be able to tell your manager with confidence that the project will be done after 12 weeks and 3 days. But here’s the thing — you’re probably still wrong. The fault lies in the very concept of estimates: you’re assigning a logical, mathematical number to the actions of real people with real lives and real feelings. If your team was entirely composed of robots, then yes, the logical answer is probably a great estimate, but that’s not how teams work. There are a number of estimate-affecting factors that the team dynamic adds:

  • Some people will work longer days, evenings or weekends.
  • Some people will “speed things up” by skipping test cases or code review.
  • Missing milestones affects team morale.

None of these are always going to be good or bad for the project schedule, but it is foolhardy to ignore them outright. That’s why I believe in:

The Human Method

This is where it pays to know your team.

The idea is to take the proper logical answer, 12 weeks and 3 days for our running example, and tweak it based on the team dynamic. Does one of your fellow developers step up her game when the project falls behind schedule? Knock a day or two off the re-estimate. Do you have a teammate that gets easily overwhelmed? Add a day just in case. Is a stakeholder in the project going to want to have frequent meetings about why the project is late? That’s another day or two as well. You might be surprised at how things stack up: maybe it’s not as bad as you thought, maybe it’s much worse. But at least now you know.

Of course, you can’t always predict everything about your team, so sometimes you have to ballpark the team-dynamic chunk of the re-estimate. The best thing to do in this case is to err on the side of caution and add a buffer — something in the 20~30% range. For our example, that means adding another 25-ish% of the 2 weeks and 3 days that we’ve already added, call it 3 more days, bringing us to 3 weeks and 1 day. This means that our originally-estimated 10 week project is actually going to take a little over 13 weeks. Probably longer than what your manager was hoping for, but at least now we have some numbers to back it up.

And what’s your alternative, really? Make something up off the top of your head?