The Agile Man-Month, Part II

You have ten developers for a five man-year project. How long will it take to complete the project?

Analogously, you sell lemonade for 10 a glass. Yes, 10. The currency is totally immaterial. Canadian dollars, Kazakhstani tenge, or sea shells – I give ten, you give lemonade.

How are these two analogous?

It is a truth universally acknowledged that a software developer is like a ninja. Each is unique, carries a distinct set of abilities, and, surely, has a different force multiplier. One’s force multiplier varies depending on the type of work. For example, some ninjas do better during mortal-style kombats. Others excel at stealth assassinations. Others still specialize in sabotage and infiltration. The total amount of damage that can be inflicted by a team of ninjas depends on the collective force multiplier of that team for that specific type of mission.

Likewise, the total amount of work attainable by a team of developers is the sum of those individual developers’ abilities for that particular type of work.

But, you will argue, the man-month number is just an estimate, and as such is perfectly acceptable. After all, how big can be the difference in force multipliers among ninjas? A ninja is a ninja, and a developer is a resource with some variation.

There are no scientific methods to quantify the difference, but, according to Fred Brooks’ The Mythical Man-Month, “good” developers are five to ten times as productive as mediocre ones. If that’s true (and many developers would agree), one man’s year can be as valuable as another’s ten! This means one developer’s five-year project can be another’s six-month stint, and such.

You have ten arbitrarily-chosen developers for a five man-year project. How long will it take to complete the project?

 

To be continued…

Advertisements

The Agile Man-Month

It was bound to happen sooner or later. I was just minding my own business, you know, coding and stuff, when the question popped up:

How many man-years is this project going to take?

The rationale here is you take m workers and have them work for n years for the total cost of m*n man-years. Since the estimation is now reduced to basic algebra, you can compute things like total duration of the project:

Total Duration = Man-years / Number of workers

Or, given a fixed duration, you compute the number of workers you need as:

Number of Workers = Man-years / Total Duration

Now you can finagle the numbers to figure how much time you can save by adding three more people to the project and such.

Well, that’s the rationale. Is it any good?

To be continued…



Being Dufus

A former junior colleague of mine asked me for some career advice, which I confidently promised to offer. I’m fully entitled to offer such advice because I’m an experienced and wise engineer-turned-project-lead-who-also-architects-and-likes-to-talk-a-lot. I’m surprisingly good at keeping track of the big picture and never suffer from any bouts of complacency or tunnel-visionitis, unlike everyone else around me. Really, I’m pretty amazing that way.

The same colleague mentioned this book in an unrelated conversation. Even though I’m way past needing any career advice, I decided to give it a try because I had an open slot on my Safari books online and some time to kill.

Having read the first part of the book I realized I could easily spare the world of my career advice because there’s more useful information expressed more eloquently in there than I could ever muster. So, I guess that part’s done (check).

On to Part II: Deconstructing Management, there’s a pretty rare glimpse of the management from the point of view of the managed . Usually it’s the reverse, especially in those serious-looking MBA textbooks. It’s a vivid and slightly whimsical classification of different types of managers out there with all their insecurities, arrogance, indifference, and just plain old incompetence. Pretty entertaining read, especially if you vaguely recall having a few of those…

And then it struck me. Good God, I am a manager! Great, now I’m dying to know which type my team figures I am. Is it the Doof? The Leaper? The Interrogator? The Prioritizer? The Enemy? Come to think of it, I have no way of knowing that because I haven’t been giving them much attention lately what with all the messy code I’ve been digging through and intense correspondence I’ve had evangelizing my previous project…

So, dear former junior colleague, sorry it turned out I don’t have any advice for you. Also, thanks a lot for recommending that book – it’s great! Going forward, I will take it a step further and attempt to actively network with my guys, as defined in the book:

Networking is the art of finding those who are willing to listen to and critique your stories…

It’s funny how this actually summarizes all my complaints I’ve ever had about my managers. They clearly failed to network with their team. A little networking could have spared us a lot of morale damage…

Note to self: gotta network.

Tribute to the Earliest Users

As a project manager, you’ve surely thought about the earliest users of your software. Or have you?

They live where you live. They breathe the same over-conditioned air and walk by without judging you for reading slashdot at work. They invite you to Chipotle on Fridays. They have opposable thumbs. They are inarticulate. They are indispensable. They are awesome. They are – your developers!

While you were busy talking to partially informed customers in long meetings and drawing up flow charts in fancy documents that no one fully understands, they were right by you. They were consumers of your product before the product even began to exist. They were in the first line of fire when you presented that partially convincing requirements doc. They had to work up the courage to point out your embarrassing omissions. Did you appreciate the feedback?

It’s really simple. If you can’t sell the product to your own team, what chance do you have selling it to finicky buyers?

You’d think this would be common sense, but I see it over and over again – managers try to ram down requirements down developers’ throats and care not about the consequences. The demoralized team eventually delivers the half-baked product, probably later than anticipated. Someone then puts together a vague but well-articulated excuse that makes it alright with the management.

Seriously, if you ever find yourself doing this you should immediately drop and do twenty. If that doesn’t help, repeat until you come to your senses.

Love your users. Starting with the earliest ones.

Of Project Scope and Agility

You hire a shoe manufacturer to design the perfect shoe for you. You know, the one shoe to rule them all, the shoe that agile makes you (tsk tsk).

Umm which won’t be a problem for you because  you are, after all, a seasoned shoe user. You’ve worn many a shoe for decades and rightfully consider yourself an expert pavement trotter.

The manufacturer calls and asks for the specs. You know, things like your preferred outsole dimensions and vamp style. How about a welt? Have you considered a balmoral-type shoe or would you rather go for a moccasin with a simple plug? Gaiters are all the rage nowadays – wanna go for it?

It doesn’t take too long to realize you’re pretty clueless about what you want. You need the project manager to guide you through the process and help you figure that out – and it’ll take you some time.

Right after the meeting, the management at the shoe manufacturing plant ask the PM the magic questions: how long will it take and how much will it cost? The PM has exactly twelve milliseconds to provide estimates (in man-years, mind you) or risks getting fired. But, we know you, the client, will take longer than that to even decide what you want.

And this is how a typical software project begins.

Ideally you would like the shoe manufacturer to build you an early prototype just to get the conversation started. You can wear it for a few days and get some impressions like “it feels good when I run, but I’m off-balance going up the stairs” and “I wished it were waterproof the other day I got caught in a thunderstorm.” A couple of weeks later, the new and improved prototype is ready for further testing and you’ve had some time to ponder. The creative juices are starting to flow. You are becoming more and more agile in your new shoes…

Agile programming openly acknowledges the pointlessness of setting a fixed global scope for the project when there are obvious unknowns. Instead, do your best to estimate what you know, acknowledge what you don’t; try not to make up fictitious requirements to fill the gaps. Break down the project into iterations that are each meaningful and complete on their own to reduce the risk. And work hard to discover the missing pieces sooner rather than later.

Don’t try to make up a half-baked plan just for the sake of having one. It will give you the false sense of security when you should be scouring for still unknown requirements.

Keep everyone in the loop as you go in order to demonstrate progress and any setbacks. With a little bit of luck and right choice of words, our hero PM will manage to survive once again!

Stop That Thread!

You start a long-running job in a separate thread and then decide it’s not really worth it. You’re thinking there’s got to be an easy way to just kill the thread and be done with it.

However, the thread may have acquired system resources like a database connection or a lock. It may have created a bunch of temporary files. If you stop the thread in its tracks, those resources may not be released. Worse, if it’s a lock or a semaphore, you can wind up with a deadlocked process.

The solution is to cancel jobs cooperatively. This means you code the background job so that it checks for a cancel signal as often as it can, and if that signal is set the thread cleans up and exits gracefully. The signal can be as primitive as creating a file called canceljob.txt in a predetermined location so the background job checks for it every so often and acts accordingly.

There’s a problem with that approach. If the thread is stuck waiting on a lock, your cancellation routine can wind up waiting for that thread for quite some time. Ideally you should be able to just send a signal to the thread even if it’s asleep. In Java, use Thread.interrupt() to do just that and in the thread itself check Thread.interrupted() as often as you can:

 
while(!Thread.currentThread().interrupted() && hasMoreWork)
{
    // process next batch
}

Compassionate Project Management

Nearly all of the Project Management Body of Knowledge (PMBOK) is about flipping spreadsheets and pushing people to meet deadlines. However, too many software projects were managed by-the-book just to find out that users are displeased with the final product.

What happened?

It’s pretty simple. Project managers, architects, engineers, and everyone else were too absorbed in the formalities: make those spreadsheets extra neat, use all design patterns in the book, and add the obligatory premature optimizations. Just a minor hiccup: no one thought about the user.

It’s not that they didn’t think about the user. In fact, the user is all over the design documents. However, they didn’t really think about the user. Had they done that, they would have realized that an innocuous-looking feature can become annoying after some time (remember Clippy?), while a frequently used procedure can lead to headaches if not easily accessible.

But you are smarter than that. Thanks to your work the user interaction is smooth like a mirror and you think you’re done – but you’re not! You completely forgot the other users: IT personnel who will install, run, and manage your product; engineers who will add customizations on top of your ultra-polished UI; support staff who will take calls from users; maintenance engineers who will enhance your product over the coming years and maybe decades.

As a truly compassionate person, you will spend sleepless nights thinking about those condemned to suffer through your designs. You will be haunted by the slow-motion image of the embittered editorial user who slams the keyboard in a futile attempt to vent that anger buildup caused by your completely misguided features. You will see the exasperated datacenter admin who couldn’t attend the family reunion because your product crashed again with only a vague error message. You will see the desperate support engineer who stands no chance against your black box of horrors.

You then feel the irresistible urge to find your users, get to know who they are, and understand what they need from your software. That is when you become a master project manager. That is when you discover what it’s like to be truly agile.