Category Archives: Project Management

A Tough Call

This other day I’m like coding and stuff when a co-worker walks by and asks to have a word. It turns out he needed some advice after he got himself in a pickle by checking in slightly more code than was supposed to. Something about refactoring a bunch of code instead of just fixing the dozen or so bugs he was assigned, which resulted in some frowns.

At this point you’re probably wondering why he came to me, given that I have nothing to do with his project. To that I would say I sometimes play the role of the bartender among developers with the exception that I don’t serve drinks and expect no tips. Hopefully that make sense.

So it turns out this guy set out to fix those bugs when he realized he’s dealing with a bunch of spaghetti with a full can of past-expiration-date bolognese sauce ton top. Being a fearless engineer, he took matters in his own hands and decided to refactor the offending code. But there’s trouble in paradise – the refactorings didn’t go too well with the management.

As we talk about this, I can’t help remembering so many past instances when we had some prototypical loose cannon make frivolous changes all over the place and breaking a bunch of stuff. The worst part was when I got stuck cleaning up after them. But there were also times when that was the right thing to do and it brought about a lot of good. The question is – which is it this time?

I put on my metaphorical referee uniform and tried to reason through this. Refactoring can definitely be risky and its benefit must be weighed against the risk. However, after deliberating for about 10 minutes I called the move – legal. The deciding factors were:

  1. This engineer stands behind his work. He expressed the willingness to “work all night” to rectify any issues that may arise as a result of this.
  2. He knows his s*%t. He made a convincing case why that old code was no good (monolithic methods, incorrect abstractions, etc), and why his code is likely to be more maintainable.
  3. He has a history of good coding practices.

In addition I decided to give his superiors yellow cards for taking the short-sighted approach of “if it aint broke don’t fix it” because they don’t know enough about the code in question (or code in general IMO) to make that call. Surely there are cases when it’s better not to fool around with messy code when it’s fully contained and debugged, but this was not one of them.

As a result of my decision, nothing happened. This was in part because we didn’t tell anyone so in the end it was just two dudes talking about some work stuff. For what it’s worth, I remain very pleased with my decision.

Advertisements

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…

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!

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.