Management Debt

Posted by indomitablehef | Filed under Anti Patterns

Extending the concept of Technical Debt to Management: Musings about Management Debt.

I see this especially in cases where an organization is running in crisis mode all the time. I especially love what one of the commenters said:

A manager who is responsible for project management, software development, etc. asks decision-makers which project is the most important and the answer is “all of them.” [Which actually means] “all our projects are equally unimportant.”

It’s Caves AND Commons…

Posted by indomitablehef | Filed under Anti Patterns, Agile, Productivity

…not Caves OR Commons, and not Commons only.

Australian scientists have reviewed a global pool of research into the effect of modern office design, concluding the switch to open-plan has led to lower productivity and higher worker stress.

“The evidence we found was absolutely shocking,” researcher Dr Vinesh Oommen from the Queensland University of Technology’s Institute of Health and Biomedical Innovation, said.

“In 90 per cent of the research, the outcome of working in an open-plan office was seen as negative, with open-plan offices causing high levels of stress, conflict, high blood pressure, and a high staff turnover.

If you have to choose one or the other, you’re better off giving everyone a cave than forcing everyone into a common area. It’s feasible to cram multiple developers into a cubicle for pair programming and collaboration. It’s not feasible to focus and achieve “flow” in an open plan office when working alone. The last time I worked in such an environment, it turned into a shanty-town. Developers would build little “forts” around their half-cubes with marker boards, stacks of books, and pieces of cardboard. They’d hang up signs saying “do not disturb”, and invest their own money in expensive noise-canceling headphones - just to be able to get a little work done once in a while.

Amazingly, this is one of those fundamental things that almost nobody gets. I’ve never worked in any place that got it right. Software developers are expensive resources, especially good ones. And as a manager, you would think that getting the absolute most out of that expensive piece of equipment would be one of your top priorities. Instead, developers are crammed into cubicles instead of offices, and at worst, forced to sit out in an open floor plan. It’s money down the drain.

How about a little math?

Let’s say you’ve got a good developer, and he makes 90K year.
Now let’s make some assumptions…hypotheses, if you will.
1. Assume that working in an office would make him more productive by 1/2 hour per day, over working in a cube
2. Assume that working in an open floor plan would make him less productive by 1/2 hour per day than when working ina cube.
3. Assume that having an office with a door, and a common area to work with and collaborate with a team would make him more productive by 4 hours per week.

There are 260 working days per year. Assuming an 8 hour day, your developer’s half hour is worth approximately $21.60. His four hours per week is worth approximately $173.

So, in one year:
1. If you give him an office, he is more productive to the tune of 21.60 x 260 = $5,616.
2. If you sit him in an open floor plan, he is less productive to the tune of $5,616
3. If you give each developer an office, and the team a common area to collaborate, each member of the team is more productive to the tune of 173 x 52 = $8,996

Assume your office floor plan will last 3 years or more and you are considering an open floor plan. Can you afford some sort of an office for every developer for less than $33,696? Not a corner office with a view, mind you…just walls and a door.

Assume you have a team of 6 developers, average salary of 90K, and you are considering an open floor plan (for 3 years)…can you afford to set up offices and common areas for less than $161,928?

Can you afford not to?

(I think my productivity assumptions are highly conservative, and that the real return would be much higher. Probably double. Maybe more.)

Also, I have at least heard of one place that got it right: Joel Spolsky’s Bionic Office.

AntiPattern: The Proxy Product Owner

Posted by indomitablehef | Filed under Anti Patterns

I am not the sort of person who never makes the same mistake twice. I may swear up and down that it’ll never happen again, but I forget. And it happens again. If, however, I can identify a pattern, some immutable law of the universe that I can internalize to keep me from making that mistake again, it helps. It may push me towards dogmatism, but at least I won’t get bitten on the ass by the same dog next time.

So, here are a couple of mistakes from the past, recently repeated, that I am now going to attempt to quantify, categorize, and put to bed for the remainder of my career.

I’ll do one today, and plan to do one tomorrow.

AntiPattern: The Proxy Product Owner
This one is an oldie for me. It happened to me on my very first production web application, in my very first job out of college. It happens when there is a “proxy” between you and the real users/product owners of the application you are building. This person may be a well-meaning project manager, trying to shield you from stupid users or shield users from asshole developers. It may be a piss-ant IT manager who is protecting his little fiefdom. It may just seem more “convenient” and “cost effective” than introducing the actual developers to the actual product owner.

In that first web app I wrote, I had the piss-ant IT manager as a proxy between myself and the department that was going to use the app. I got all the requirements from him, showed all my progress to him, and stopped working on it when he was satisfied that it was done. He was thrilled with the result. Absolutely thrilled. Then they asked me to teach training classes to the end users. When I got to class, it was the first time that any of the users had met me OR my application. They’d never seen it. And they hated it. They couldn’t understand why anyone would do things that way. They certainly wouldn’t be able to use this to get their jobs done. Eventually, the app was updated to meet some of their needs, and they gritted their teeth and learned to live with the rest of it. And the piss-ant was still thrilled with it. And the users still hated it.

That’s the “explode on impact” scenario - where everything looks fine till the end, and it turns out that neither side understood each other at all. There’s a more gradual way of playing out this charade as well.

1. Week (or Month) One
   Developer Meets PPO (Proxy Product Owner), and hammers out application requirements, screen mockups, estimates, and schedule. Developer starts work, confident that he has diligently picked the product owner’s brain so that he really understands their needs.
2. Week (or Month) Two
   Developer delivers first progress to PPO, who is thrilled. PPO decides to wait till next week to show the application to real customer. No reason to get them involved just yet. Developer keeps working.
3. Week Three
   Developer delivers progress to PPO, who has bad news. PPO showed demo app to customer late last week, and customer has changes. Just some “tweaks”. PPO sends Developer an excel spreadsheet with new requirements, new screen mockups, and changes to the names of several features. Also requests additional administrative options and reports. Developer informs PPO that these changes will probably affect our ability to meet a rapidly approaching deadline, and some features will have to be cut.
4. Week Four
   Developer re-designs application layout to meet new specs/mockups, removes some features from week 1 and starts on some new features from Week 3.
5. Week Five
   Developer delivers progress to PPO, who has recently spoken to customer again. They’ve heeded the developer’s advice from week three, and decided to stick with most of the original plan, except for some of the name changes and screen layout changes. They believe this gets them back on track to meet the deadline, maybe even ahead of schedule.

This process continues until the money runs out, the customer is not happy, the product is barely usable at all, and the developer takes up smoking again.

Update: It occurs to me that I’m just restating the importance of “On Site Customer“, not saying anything new. Just saying with more bitterness.