Saturday, February 23, 2013

Why do projects take so long?


Some projects take a long time to develop. In different contexts, the definition of "long" may vary. It was always interesting to me, what are the reasons for it. Recently, though, it became my obsession.

I've started collecting some thoughts on this topic.

Ask yourself and your teammates about the last project you've been working on. "Would we be able to implement the same result in 1 month? In 1 week?".

Surprisingly often, I'm answering to myself - yes, that would be possible, given some assumption. I've had similar answers from my colleagues.

Where does it come from?

Is it the known tendency to underestimating a problem by developers? I don't think so, as we're talking about a project, that has already happened. We know what is to be done. We are aware of edge cases.

"This is time it will be different, faster"

This is another popular trend among us, developers. Most of us are optimistic, even the experienced ones. It's not some kind of a student-syndrome (I'll do it tonight), but a well-thought statement. Is it really different and faster? Not always…

Where does this optimism come from? Good developers become better at solving technical problems. With each problem solved, we know that we solved the problem forever. We love solving problems, every day we're smarter by this attitude. We're progressing and the optimism may come from that.

It's almost impossible to get a second chance of working on the same project. What would that even mean from a business perspective? We rarely get that chance.

Is it the technology that let us think, that we could do better this time? That's a serious candidate. Every time, I switched to better technologies or to better architectures, I noticed the speed increase. I was more confident. I saw the results.

I remember a situation, back in 2004/2005. I was involved in preparing an estimate for a new project. The estimate was about 6 months for 4 developers (assuming ASP.NET). Very shortly after that I learnt Rails. I realised, that the project is perfect for Rails. It was a CRUD-based web app. I kept convincing the management to give it a try. No luck. Finally, I had a chance of coding live in front of some managers. I implemented the main path in about 1 hour (I was well prepared). That convinced them. We've finished this project in 1.5 month, with one junior programmer and me being mostly a PM and a Rails mentor.

What's the lesson? It's hard to tell. I'm not trying to say that only Rails was the reason. Motivation? The passion behind it? Trying to prove something? The focus? I think it was a combination of all of the above aspects.

Is it easy to repeat those aspects? Do they sound familiar?

Have you ever attended a hackathon?

There are many kinds of hackathons. What's most important in this context, is how much can be done in a very limited time. If you look at the results of Rails Rumble, some of the apps are quite big. Many features, everything is polished.

Hackathons are proves that we are able to develop apps quickly.

How can we apply hackathon lessons to our every-day projects? Is it possible?

What else can help us developing software faster?

I would love to know your opinions.

3 comments:

zigomir said...

Interesting observation. I also came to an idea that motivation can be really powerful driving force to get things done.

To convince management (like in your case), for me, sounds like a perfect situation, where you are really motivated because you want to prove you're right about something.

I, for a moment of speaking, am in a similar situation, where I'd like to show my employer that I can get more stuff done with language/framework I know (and love) than in something I don't like at all.

Roberto said...

I don't think hackatons prove anything.

Actually they prove that when there is nothing in place it is very easy to go fast, but that is not the case of common projects that lasts months or years.

After the first initial period, the productivity drops, most likely because of lack of disciplines by the developers.

Unknown said...

Estimates are hard. We tried (sort of) scrum yet all numbers proved us wrong. Kanban is better because it helps to keep a steady pace. No time wasted trying to pull numbers out of thin air.

I've seen projects where just a mock took three months to finish. The hard part was the data flow not coding or technology. That said the number of developers
assigned to the project (way too many) did not help :)

A classic answer applies http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3