codemonkeyz

There are a lot of management books out there but not all management problems are created equal. Software is eating the world, and only now we’ve come to realize certain truths about managing of software teams. Most conventional management theory can be applied to support or sales teams but there is something unique about software that just makes certain things work differently.

Take for instance, the infamous Mythical Man Month, although we all know deep in our hearts that adding manpower to a late project will only aggravate the problem, senior management in a lot of companies still manage to err on this matter.

For instance, the most common issue management tackles is the issue of estimations. Imagine a simple system with a working feature X. The system works fine on both Windows and Macs but feature X was only developed for Windows and it took around 2 weeks to develop. Would it be safe to assume that building the same feature for a Mac would also take 2 weeks? Is it possible that it’ll take less than 2 weeks? I mean, we already have this running on Windows right? Is it possible it’ll take longer than 2 weeks?

If you’re an experienced developer and you’re reading this you know that both answers (longer and shorter) are correct, each in its own scenarios. We’ve all seen features that take longer to implement on different operating systems and we’ve all been on the other side of that as well. So the question here again, is why is this like that?

So what makes software so inherently different? Why isn’t software more similar to something like classic engineering? I believe the deep reason for this lies in the fact that software teams operate with less information than most people think they do. Programmers must “pay” to receive more information about a task, and that payment is collected with their most valuable currency - time.

Here’s the secret then - companies don’t have a lot of time and companies rarely know how to manage time well. From the business side, management will take a look at a late project and just label it “late”. From the technical side, things might look completely different, heck sometimes it’s even surprising that the job can even be done at all with the given resources. When a “late” project becomes “really late”, management usually feels like it needs to intervene, in order to make get the project to meet the deadline. In such a scenario, management will turn to the tools it has at its disposal. It will either change the manpower that’s currently working on the project, shuffle, move around and change the project’s requirements or change how the project itself is managed within the company. As a developer, if you’re unlucky enough to be in this situation, you probably know what it feels like when management pulls out all the stops and tries all three tools simultaneously. The results often are not pretty.

I believe that managers that work in software companies, not necessarily just managers of developers, need a better education when it comes to dealing with software development and the people who do it. I intend this blog to include several writeups on varying subjects that concern management and software development. Sometimes the topics are a bit technical, but most will can apply anywhere. Hopefully someone somewhere will find this information useful and maybe it’ll help save some project somewhere.