Wassup Jose Weblog nonsense at its best!

Counting Widgets

One of management and accountings favorite past-times within the organizational landscape is Bean Counting. They love to count them some beans. And why not, knowing how many widgets gets sold off the line is an essential part of planning and forecasting. A company needs to attain and manage the raw inputs and outputs of their product. That way when they sell 500 widgets in month A and sell another 500 in month B, you may be able to predict that month C will also sell 500 widgets. The whole supply and demand, running a business thing kicks in from there, but seeing as how essential this task is I can't help wondering if sometimes it goes too far.

Obviously, sometimes the process does go too far, but the difficulty about pondering such a task is illustrated by drawing a line in the sand. How much bean counting is too much? Is all of it useful? What value is contained in all the counting. Certainly, a lot of these questions are issued moot if the data is collected automatically. Then it really doesn't matter how much data you collect or even if you use it. The information will just sit unused. But when people have to put in an effort to help you count beans then you're starting to effect productivity. Irregardless of the amount of time put in to help count a completed task, time, even if its small, is still being spent that could be spent elsewhere.

Maybe I'm making mountains out of mole hills, but allow me to illustrate my point. I have been a big proponent of attaching code check-ins to work items within our source control product, TFS. The task allows for greater visibility at the build level and helps keep track of developer changes when testers reopen or resubmit bugs. Well, I've got my just dessert and management as made mandatory that all check-ins must be accompanied with a work item. That's all well and good after all why make changes to the code if not tasked to do so? Well perhaps someone spells Ajdusments wrong on a file name. Perhaps someone left out a script out of the database version upgrader. Perhaps you just noticed a small thing here and a small thing there. These all need work items? Current organizational policy here answers yes. ok, that's fine. I can roll with that. So I create a work item for every changeset that I now check in. Often this takes me as little as a minute to create the item, fill out a scant description and relate my changeset to the work item. However, often what happens to me is that I notice all of these changes separately. That's one work item for each changeset. For smaller changes work items begin taking longer to create and fill than doing the actual work.

To add insult to injury, I'm now required to fill out an impact analysis form which is required for every work item. One work item per change set, one analysis form per work item. Subsequently, I'm suppose to find a fellow developer familiar with the code space to review the analysis sheet and approve the analysis. So you can see the processes are starting to add up and I can't help feel that I'm getting closer to that proverbial line in the sand. On top of that, there was actually a process instituted that would have me complete and submit a form any time I wanted to talk to one of my peers. The idea was that hanging out in people's cube wastes people's time (understandable), but the realities of such limiting communication in a fast paced development project are absurd. People need to communicate in order to complete tasks and if you're on a good project, people like to talk with each other. So sometimes there's a little BSing going on. I think its a small price to pay.

In conjunction with my Organization Tree post, where I essentially layout that management should be supporting their staff instead of firmly directing them, I believe that the process should be lighter or at least different. I actually had A LOT of difficulty writing that last sentence. I had to essentially put my finger on exactly what I'm trying to say. Originally, my sentence read "management should be supporting and directing," because I feel that management should be directing the work of staff. However, there's a difference between giving your staff a blueprint of a house and letting them go to work, and telling the electrician where to put the wires. Yet when you're building a house there are all kinds of rules and regulations to follow. I guess I've hit the nail on the head here (no pun intended) in that you don't need to tell the electrician where to put the wires because there's already a plethora of regulations dictating where to put those wires. Software is nothing like this. Although, its not from a lack of trying. I've seen dozens of methodologies. They all of their pros and cons, but the only thing that's constant in software development is change. So managing a software development project takes a completely seperate skill set in order to make the project a successful endeavor. Ultimately, you have to let go a little on the developers, but hold them accountable on the test front. Yes, that's where you can get them. When code goes to test, there should be a library of tests that ship with it. If you want to micromanage and hold a developer accountable for the work he/she is doing, you must do so in the test cycle. 3.5 tests per function point.

I think my thought have started to spiral out of control and may be losing focus. So let me close by saying its easy to add roadblocks to the development of a project in the name of counting beans. Make sure the beans are being counted if staff is making the effort to make the beans available.