[/caption]I've found myself in an odd situation as of late regarding my work, I am a programmer by trade and education but haven't done any professional programming for 2-3 months now. It's not that I'm being lazy and don't want to program, I would jump at the chance to fire up Eclipse right now and start writing mountains of verbose Java code, it's that I'm not allowed to program. "Not allowed?" I hear the shock and dismay in your voice, so let me explain.
My role on this project is to design middle-ware but because of the way the business is set up I'm not actually allowed to program, the programming is all outsourced. Instead of actual programming I get to engage in some weird form of meta-programming where I turn a program into long flowing sentences in a Word document that take about 3 times the effort to write than the program itself so that it can be shipped off and someone else can program it. It is an odd situation indeed, but I am no business man, this project is important, and so I shall continue in this weird meta-programming.
This is not my first dance at the outsourcing-prom and with the economy in shambles I'm certain it won't be my last. I have yet to work on a project where the supposed benefits of outsourcing have actually materialized. I did some research (typed something into Google) to attempt to find out how many outsourced projects fail and saw figures between 25-40%. These seem fairly reasonable to me, and with some statistical hand-waving I will use these as "good enough" figures for the rest of this post. This leads to an interesting question though, if this strategy fails so often why do companies continue to outsource?
I would like to posit that a major reason for the continued use of outsourcing is the gap between subjective and objective measure. Subjective measures come from within, they are personal opinions, things like "Frank is a great worker!" or "Jim is so lazy" are subjective measures. Objective measures are fact-based measures things like "Frank worked 48 hours this week" or "Jim only produced 1 class file this week."
Often, like in the examples above, our objective measures inform our subjective measures. The problem with software development is that there are no good objective measures. As much as we like to think of what we do as a science or even an industry, it is still a craft. In the above scenario we are led to believe that Frank is a "great worker!" because he worked 48 hours this week and that Jim is "so lazy" because he only produced 1 class file. If Frank worked 48 hours doing simple things and just racked up the billable hours is he really "working" harder than Jim who wrote a full web server in one week (monolithic in design so it was only one class). Getting to the heart of the value that someone produces is a difficult process and is by its nature subjective.
Here in lies the problem, software development can really only be measured subjectively, which is hard. Objective measures are much easier though, and so those are often used as a proxy for doing the difficult work of subjective measures. There have been many attempts to make sure people are performing up to par, lines of code, commits, bugs, hours worked, etc. None of these are really ideal, together they can begin to form a picture of the subjective nature of the situation, but they are not nearly enough.
Objective measures are also very seductive because you can perform calculations on them, they are easy to compare, they are easy to play out what if scenarios with. No one balks at answering the question which child is taller, but ask them which one they love more and watch them squirm. Objective measures are great because you can throw them in excel and analyze them, this is also a weakness. It's easy to draw up a spreadsheet with your in-house assets pitted against outsourced assets and see that you can save a bajillion dollars by outsourcing, but that misses the bigger picture. What are the subjective downsides?
These subjective downsides end up failing some 40% of outsourced projects, communication, quality control, and responsiveness are hard things to chart and graph, but can easily cause a project to run off the rails. What is needed is either some way to make subjective measure easier or some fantastic new unit of objective measure. I would propose ihumanables per hour be the unit if anyone can come up with some really nifty objective system, but I don't see that happening anytime soon, so all that's left is making subjective measure easier, a tall order indeed.
At the heart of making subjective measure easier is really what a lot of the agile methodology is about, stand up meetings, scrums, kanban boards, they are all meant to produce a tight feedback loop so that the subjective nature of the situation is constantly being polled. I'm not going to sit here and tell you all to start running agile projects, although they can be a good bit of fun, but if you are managing people you need to get in the dirt with them. Progress reports and weekly status meetings are meant to supplement not substitute actually working with and understanding what the people under you are doing.
Remember the next time you are making a decision based off of objective measure, if you are "going by the numbers" that there are very real subjective side-effects that you should account for and be aware of. And if someone develops a really killer objective measure for software development, remember ihumanables per hour ;)
Your review hints at the critical value of one's productivity being a subjective measure, namely "what have you accomplished?"
ReplyDeleteI believe this is why hourly pay positions are flawed. Measure us by our actual productivity whenever possible, and we can be rewarded appropriately. Motivation becomes perfectly aligned with performance. It's why startups are sought after. Measuring productivity can come down to revenues, or a liquidity event, both actual measures of performance.