If you've been a regular reader of this blog you probably know my stance on Gantt Charts. I've often went out of my way and said that it's a team of competent programmers that builds applications and not your software development process and Gantt Charts. This post is not about reiterating any of those posts or my opinion on Gantt Charts. I am here; on the other hand; dear reader; to tell you that project plans and planning as we know it traditionally has already become utterly useless in the world of software development.
Don't knit your brows and frown on me just yet. Don't call me a just another happy-go-lucky Maverick out there dying to write code every time he sees a problem. Yes, I do understand the importance planning in software development and as important as you might consider planning to be; I am here, to tow with the idea that maybe; just maybe; planning in software development is not as important as most of us make it seem to be. I am also here to suggest, dear reader, that maybe there's something other than planning plays an important part in deciding the success or the failure of your next project.
Joel Spolsky in his article describes how he and Jeff Atwood started out with Stackoverflow.com without any plan what-so-ever:
|
Then one day this guy named Jeff Atwood called me up. Like me, Jeff had a blog, on which he mulled various programming topics. He wrote well, so he was attracting quite a following. He had begun to put advertisements up here and there, and was making a little bit of pocket change, so he started thinking, Gosh, I can do this for a living. It sure beat the heck out of his day job working at a California company called Vertigo Software, which is where he was when he called me, asking for advice. "Hey, I know exactly what you should do!" I said. And I told him the idea about the Q&A site with voting and editing. A site like this would need a lot of smart programmers to ask and answer questions. Between our two blogs, we felt we could generate the critical mass it would take to make the site work. Jeff liked the idea, so we decided to make it a joint venture. We named it Stack Overflow, after a common type of bug that causes software to crash -- plus, the domain name stackoverflow.com happened to be available. I had no idea if the site would work or exactly how it might make money, and I didn't have a ton of time to put into it. I have pretty deeply held ideas about how to develop software, but I mostly kept them to myself. That turned out to be a good thing, because as the organization took shape, nearly all these principles were abandoned. |
Joel admits Jeff and him committing six mistakes but ends the article with a positive note and a rather happy ending described in his own words:
|
I advocate a fairly simple method of creating software schedules. At the very least, I think, you have to make a list of all the things you plan to do and how long you think those tasks might take, and only then can you reasonably start work. Jeff kept telling me, "It's going to take six to eight weeks." I knew there was no chance that would happen, given that Jeff pulled his timeline completely out of thin air, but I humored him. In reality, it took about twice as long as that, which wasn't that bad, but it was still a 100 percent overrun. In summary, Jeff and I made six major mistakes. Oddly, though, none of it mattered. In August, Jeff unveiled the site, and instantly it lit up. Programmers used the site to pose their technical questions, and more important, they got great answers. The voting system worked well - you could see that the answers to a given question were getting sorted with the best at the top of the rankings. |
What Joel and Jeff lacked in planning they made up with something that is much more important. That something is called coordination. They had started their conversations and pod-casts on the idea of stackoverflow.com even as they were taking their first steps to building it. The community was involved with not just selection of the name but designing the logo for the system as well. With a coordination level this high you hardly need a detailed project plan.
Clay Shirky, in his talk on Institutions vs. collaboration at TED describes how modern day collaborative systems like Flickr and Wikipedia are overcoming challenges institutional setups have faced for years as these institutions continue to rely heavily on planning while the modern day collaborative systems rely on coordination. Clay explains in his TED talk on Institution vs. collaboration:
|
What Flickr does is it replaces planning with co-ordination and this is a general aspect of these cooperative systems. You would have experienced this in your life whenever you bought your first mobile phone and you stopped making plans. You just said, "I'll call you when I get there."; "call me when you get off work"; that is a point-to-point replacement of co-ordination with planning. We are now able to do that kind of thing with groups; to say instead of, "We must make an advance plan. We must have a five year projection of where the Wikipedia is going to be" you can just say - "let's coordinate the group effort and let's deal with it as we go because we're now well enough co-ordinate that we don't have to take on the problems of deciding in advance what to do. |
I've always compared software development to fighting a war and irrespective of how well your war plans are; in the midst of confusion and panic solid communication and co-ordination should be your primary tactic and is your only chance against continuous defeats; not an elaborately detailed project plan. Both your project plan and your dead-lines will change every single day; and that to be honest, doesn't matter.
If all of us in the world of software development understood the importance of communication and coordination it would be much more easier for us to realize just how much un-due and non-deserving importance we tend to given to project plans when clearly, they are nowhere close to being that important.
For your next project, try spending lesser time creating a detailed plan, fixing deadlines which run two years in the future and then panicking. Instead, try building a concrete relationship with your client and if they ask for the delivery dates two years from where you stand, talk about the first sprint, where you are trying to get to when the first sprint ends. Once you've told them all where you will be when your first sprints end, tell them; "I'll call you when I get there".
After all, when you “get there”, chances are, that the rest of your project plan might not even be relevant at all. Software Projects change all the time and all we need here is some good old coordination; not a whole lot of planning. As far as software development is concerned planning is just one of those things that is highly overrated.
Comments are closed.