Tuesday, July 1, 2008

Web Development: How it REALLY happens

I have a love/hate relationship with web development books. Don't get me wrong-- some of them are well-written, filled with amazing advice and insights on how web development *should* be done. And yet, few of them, if any, bother to talk about how web development is actually done presently in the chaotic work place.

Here's how it works: the "web guy" in the office gets a visit from a middle-manager (who is not usually his supervisor, I might add) who wants to ask a few questions about a new web app they are considering. It's kind of a rush-job, so "we don't have time for any of that formalized process nonsense, like gathering requirements, so how about if I just tell you what the app needs to do and you just build it for me?"

You could try to explain the value of the requirements and planning phases, except you know from previous experience that managers don't know about technology, they don't know about software development processes. They also don't want to know-- it's not on their radar, and they don't see it as having any value in securing what they do want, so they aren't willing to invest time in learning it.

So, you pull out a notepad and interview the middle manager on "what the app needs to do", and as you take notes, you are also frantically drawing screen mockups/illustrations to try to elicit better quality feedback from the middle manager. It's a fairly small application, with automatic email capabilities, doesn't require log-in authentication, needs to log transactions in a database. You estimate that you can do it with six pages in ColdFusion.

In these kinds of situations, where I'm dealing with the "middle manager/bypassing the formalized process" scenario I have a rule of thumb to estimate how long it will take me to complete the application. I call it the "page a day" rule of thumb. If the application has six pages in it, it will take me six days. If it has four pages, it will take four days.

That's when the middle manager wants to argue/debate the time estimate with you. "Well, you can combine three of the pages into one, so it should only take you four days tops!" Before you think this middle manager (who hasn't done any web development coding since before Firefox was first released) is completely insane, let me tell you the part he hasn't shared with you yet. Prior to meeting with you, this middle manager was in a meeting with his supervisor, and he's just been saddled with an additional requirement out of the blue because someone above him failed to plan appropriately. To make matters worse, he's got no resources to spare and even less time, so he's hoping that you can somehow magically automate most or all of this new responsibility-- because that's ultimately what all technology is about, right, automation? And if you could make that happen before next week's meeting, that would be really super because then he can tell his supervisor that it's all been handled and it will make him look good.

Here are the take aways:

1) For ColdFusion at least, I find the page a day estimate works pretty well.

2) Avoid working for companies where managers think they have the authority to delegate to people who don't even report to them.

3) Managers of web developers should have at least some first hand, recent experience in web development themselves.

No comments: