No Miracles

Our development team migrated our code to use new development tools this year. The install package and build scripts had to be modified. Our customer decided to perform a functionality test to ensure nothing got broke during migration. The updated installation worked on development and internal test machines. However we were unable to procure any workstations that matched the customer configuration. We delivered the installs for the functionality test. Of course the install did not work. A developer spent at least a day speaking with a system administrator at the customer site. But there was little to no progress.

I got the message that the development manager wanted to have a conference call to discuss the problem. We got all the facts regarding what our install developer had found. The manager wanted to see if there was anything we could do to speed up the install process. We decided that we could have the system administrator manually install and configure our application on the test workstations. The estimated time to complete this task would be about noon the next day. Fearing increased risk and schedule slippage, the manager asked how we could reel in that estimate to 7:00am the next day. This is where the conversations broke down.

Development proposed that the install scripts could be broken up which might relieve some of the risk. However the estimate was still at 12:00 noon. And so the manager continued to ask what we could do to reel in the estimate. That’s when we heard crickets chirping. We had already factored in developers staying late and bringing the work home to complete. So the manager wanted to review what it was that we were going to do from the top. It was unanimous amongst developers that we could minimize risk and accelerate the task if we got a workstation configured like the client’s site. Apparently that was not an option. So the manager continued to ask what could be done to reel in the estimate.

There were all kinds of problems going on with our meetings to deal with this problem. One part was that the software development manager was wasting a lot of time by keeping the whole development team in a meeting. The other problem was that we were not given the correct tools to do the job. Yes this might be normal for those of us who work for a pointy haired Dilbert style manager. But there has to be a better way to work in the software development world.

Technical Work

Throughout the year I have dealt with a lot of software managers and project managers. Most often than not, they have no clue as to what work needs to be done. So they are lost when it comes to producing schedules. Then a developer like me comes in and must spend a lot of time explaining everything to them. This goes on until the manager can produce a meaningful schedule. To me this is the opposite of adding value. If the entire task of creating a schedule was left to me, I would be able to get the job done faster. Instead I need to waste a lot of time bringing a clueless manager up to speed on the assorted development tasks.

You will imagine my surprise on my current assignment. My manager told me we had a lot of change requests to review and cost. I dreaded a lot of wasted time. Initially my manager thought there would be minimal impact to the application suite that we maintain. I found this strange and dug into the technical aspects of the changes. It was nice to find out that my manager was right. There were a few exceptions that I mentioned to my manager. He asked me a couple questions on each of the tasks I thought we would need to do. The next thing I know, I get a whole level of effort document listing all tasks and anticipated hours required to complete them. The manager did this for my team and for a number of other teams as well.

I find myself having more and more respect for this current manager. Perhaps he was a developer in a past life, and knows how to get technical work done. This enables me to focus on the matter at hand. I am currently designing the changes required for another huge change to our application. There is not a lot of wasted time in this arrangement. I get to go home on time. And I do not feel disgruntled because some lackeys are using up all my hours at work. Why does this good setup have to be the exception rather than the norm. It might be due to the fact that are few really good technical managers out there. Or maybe the time wasting schedule sessions are a necessary evil and will be a way of life as long as I am in software development.

One thing is for sure. When I find a good manager, I really want to continue working under them. Hopefully this is a win-win situation. I get to work on the things that developers should be doing. And then we deliver good software on time that meets or exceeds customer expectations. Then the manager gets the big bonus for setting the team up for success. The only chore I have right now it to make sure this good manager does not get promoted to higher position or another project. I wonder how someone in my position can do that.

Manager Jokes

I work for a pretty conservative manager right now. He is known to call "short meetings" which last forever. And I have noticed that he is always good for a bad joke. When I say bad, I mean the joke is just no good (not funny). The funny thing is that the guy is trying at least. We all laugh because the jokes he produces are weak. That in and of itself is amusing.

A couple weeks ago I found myself in the office working by my manager. Some girls walk by and asked him if he was good. He replied, "No. I'm bad". And do you know what? That line actually worked. Finally my boss nailed the punch line. Everybody including myself was cracking up. The irony of the statement was that my boss is not a bad dude. He seems like a goody two shoes. That's what made it so hilarious. I have confessed to him that his game is weak in the joke department, but that the "bad" comment was priceless.

You got to give the manager proper credit for trying to lighten the mood with weak jokes. I do.