Category Archives: Agile Programming

A Total Communication Breakdown

This other day I was just minding my own business, you know, coding and stuff, when I suddenly felt the full wrath of a dissatisfied user. As it turned out, my last year’s project completely missed the mark for this user and he just casually dropped by to give me a piece of his mind. I’m guessing it’s a matter of time before he’s back again.

I’m not exactly troubled by the fact that there are dissatisfied users. It’s hard to build something that pleases everyone and I don’t think it’s realistic to work under such constraints. What really gets to me though is the fact that I completely failed to realize that there were such users while I was running the project. In fact, had I realized that, I would have definitely done something to make up for it – if nothing else, at least a pre-emptive PR campaign.

No, it’s not that I was slacking off. Even though I’m a developer, I typically also run a part-time product management shop out of my cubicle to verify and rectify the original requirements (trust me, I discover a lot of problems that way). In addition, by keeping people involved throughout the project, I can usually claim some pretty satisfied users.

But it still bugs the crap out of me that I didn’t detect these other users who expected something else.

Playing this back in my head, a few things come to mind. The satisfied users were:

  1. Easy to communicate with, which led to in-depth conversations that helped me understand what they want
  2. Proactive with feedback and eager to try out new features right out of the oven
  3. Equally obsessive about getting this done right

As for the dissatisfied users:

  1. Communication problems. For example, I had distributed beta builds in the hopes of getting some good criticism but didn’t get any. Case in point, the same person who came by to yell at me was given a copy of the said beta build. However, he somehow decided to hold his silence until it was too late. This turned out to be a widespread issue among dissatisfied users.
  2. Lack of mental connection. For example, I’ve had people express scepticism about Subversions’s ability to automatically merge concurrent changes. Since Subversion has been doing that really well for years (and before that we had CVS and others), I had to disregard such comments and take the person with a big grain of salt. Not to say that these people actually offered any constructive feedback on the beta build – the discussion never gained any depth. There were a number of such incidents and my course of action each time was to stick with the information from people I found reliable.

How to do better next time? First, you could say the dissatisfied users had their chance and blew it, so they fully deserved this. Well, yes, but I still can’t stand the idea of having dissatisfied users period so I’ll need something better than that.

Looking back at it, it’s a puzzle. I’m building something. I have to figure out what it is, sometimes while I’m building it. There are hidden clues everywhere, reliable and unreliable informants, some of whom withhold crucial information for irrational reasons (too shy, embarrassed, high…). The plot thickens with every conversation, every demo, every new realization. Put it together correctly and you’ll have a project that’s deliverable within specified constraints, and will have a reasonable number of satisfied users. Get it wrong and you might wind up doing it all over again in a couple of years.

When dealing with inarticulate users, remember to ask very specific questions. For example, asking “do you need a vehicle with off-road capabilities?” might give you some of the same blank stares and perhaps amusing answers like “I don’t think it’s possible for cars to operate off the asphalt”. However, ask “do you want acceleration right and brake left?” and you’ll be more successful at jogging the underpowered neurons on the other side, and maybe even have a decent conversation.

I think I’m gonna try that next time…


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.

The Agile Man-Month, Part III

Project Scope

Sometimes the management tends to see a project as a monolithic unit of work. The thing is either complete or it’s not. While this is often true for buildings and cars, most software can be easily broken down into pieces and prioritized in various ways. You sometimes achieve a big impact with just a small set of carefully chosen features. Other times you need more than that, but it’s very rare that you need all the features in order to have a usable product.

It turns out during man-month tennis matches between developers and the management this is rarely considered in its true glory. It does get some attention, of course – when the estimate comes out a bit more than desirable and something needs to get removed from the list. Once that’s done, however, the warm and fuzzy feeling of being somewhat in control can finally settle in.

But you’re too agile to get sucked into that and surely remember to expect a few surprises down the road.

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…

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.