There are laws and politics and other shenanigans going on at the mid-management level. Kind of makes you want to stay away from management positions. Check out what one cranky system administer turned manager has to say about the subject.
Challenges and Surprises
There are laws and politics and other shenanigans going on at the mid-management level. Kind of makes you want to stay away from management positions. Check out what one cranky system administer turned manager has to say about the subject.
Tracking Actuals
I am surprised that the estimates are actually pretty reasonable and reliable. After all, the guys who do the work create the estimates. I think there is a problem on how the estimates are being used. If an estimate for a change comes out to 80 hours, you cannot schedule the thing to be done in two calendar weeks.
Nobody works eight hours a day on a change. There are interruptions and other activities going on. I would hope that management 101 dictates that you use some percentage of your resources' time to estimate progress toward using up the hours from an estimate. Ha. Maybe nobody else heard of this novel idea.
Currently we are adding the tracking of actual hours worked. We track how many hours we spend each day on which tasks. That will give us a clear realistic picture of how many hours of the workday are spent on the changes we produce. You would think that with this information, plus accurate estimates, one could reliably predict our project schedule.
Then again, I may be expecting too much.
The Naive Manager
So I visually mapped out my pieces of the system on a white board. Then I graphically showed what I thought I needed to complete. There was still a long way to go. I showed the project manager. He said we would somehow make up the slips. LOLWUT? I did not care too much because I was having fun writing all this new code.
Eventually you need to pay the piper. When the date for delivery came and passed, we were still nowhere near a state to ship. We got the order to halt that project not too long after that. They brought in outside teams to assess the situation. They switched out to some outside teams to do more management. I jumped ship shortly after that.
The only real thing that caught me off guard was out project manager acting surprised when we missed the delivery. There was no way we could deliver given our rate of progress. This was evident to me. And I was a noob. Perhaps this was all part of some elaborate show. All I know is when I see management tendencies like this, I know utter failure is near at hand.
Remote Management
These days team are split up geographically. How does a good manager cope with this challenge? Start by putting your expectations in writing. This is advised even if you have local employees.Next you should offer a bonus to those who finish their tasks ahead of time. There should be some incentive to stay on task when you are physically away.
I hear that you should also have a short talk on a daily basis. This is like the daily team standup meeting. Personally I hate these. They seem like a waste of time. I find that they usually are never short.
Require your developers to have a predictable work schedule. Even if they are at home in their pajamas, they should still be working regular hours. Finally put some short milestones in the schedule. This also applies to local workers. It allows you to detect problems as early as possible.
Do Your Best
We were looking to hire some developers about a year ago. We went through a lot of candidates. It was important to get the right fit. There is so much domain knowledge to pick up on the job. Therefore we don’t have time for people to pick up the tech knowledge as well. You got to know our technologies already.
During our interviewing process, a manager from another group approached our big boss. He had a dev that was working for the company but did not have a project. From one big boss to another, there was a request to put this guy on our project. I was asked whether the guy could make any contributions.
This guy’s resume was not a good fit. However I determined we could have him do some work. One would think some work it better than nothing. Big mistake. It turns out the guy was not happy with the transfer. He did not like our project. He wanted to improve his career by learning hot skills. Our project is filled with legacy technologies.
Fast forward one year. This new guy we acquired on our team is just not working out. He can’t or won’t complete any of his tasks. We are constantly reassigning his work to other developers because it needs to get done. Last week was the final straw. We were late on a delivery because his part was not done. So we split his remaining work. After everyone else finished up, the guy could not even complete his lessened workload.
I told my manager that we need to deal with this situation now. It was affecting morale. I myself was tired of doing my own hectic job as well as doing some of the lackey’s work. Plus I was getting extra tasks to plan how we could deal with his inadequacies. All of this could have been prevented by sticking to our guns and demanding we have a good fit before we hire anybody new on the team.
Mythical Man Month Wrapup
Today I want to finish writing about some gems I read in The Mythical Man Month. One quote that rings true is that "authority comes from accomplishment". You got to earn it.Here is some more guidance that we do not practice on our system. You should put the documentation right into the code. I am not sure if that is the same as saying your source code is the documentation, or whether you should add a lot of comments.
Do you want high developer productivity? Then focus on quality. In fact, quality is the single biggest factor which determines whether the team shall succeed.
P.S. Do nightly builds. It will increase your quality.
Keeping to Schedule
I continue with some more random thoughts related to keeping on schedule during a software development project. The best design is one that plans for future change. And know this, there will be change.Here is a crime. Managers often think their best staff members are too valuable to simply write code. That's nonsense. Yeah you might have a guy that does a lot of design. But they will get stale if they do not have hands on practice.
Beware when developers fix bugs under duress. The result will be more new bugs. To prevent problems in the first place, you should do a test on your specification.
When you are marching towards a deadline, you will almost never be able to make up day by day slippage. So how can you keep on track? You need developers with hustle. That means they just don't try hard. They try harder than needed. I want people like that on my own team.
Design Implication
A small team consists of 10 developers. Any projects that are non-trivial will need more manpower than a small team. However many people can actually get in the way during the design phase. You need an architect to be in charge or the design. Otherwise you will get a design that lacks unity.It would be optimal to hire a large team of programmers after the design is done. This is the way construction jobs work. However it is not always feasible to ramp up developers quickly during the implementation phase.
Since we are speaking about design, here is a worthwhile quote. "The second system is the most dangerous one ever designed." That is because the designer will have the tendency to over design everything. This is detrimental. A good designer must learn to leave out a lot of good ideas that just don't fit into the solution.
Next time I will discuss writing and programmer productivity. We still have a lot to cover before fully understanding the Mythical Man Month.
Brooke's Law
You can get in trouble if you try to arrange your software development schedules to match a customer's dates. This will only lead to false schedules. False schedules in turn cause evil death marches.Once you fall behind the schedule, there is usually no way to recoup the loss. Brooke's Law states that "adding manpower to a late project makes it even later."
On choosing developers to work on a project, you might think that you want senior developers. However some research has shown that performance does not correlate with years of experience.
Next time I will focus on the effect of team size.
Problems with Projects
The odds are against the team when they try to develop a system. It can be compared to a big pit. You are most likely to get stuck and never return. The design becomes obsolete before you even start coding.Most projects fail due to time constraints. A big factor is poor estimation techniques. This is especially true for the time allotted to test. You really should leave half the time for unit and integration testing. Another problem stems from computer programmers being unreasonably optimistic with there estimates.
Programmers are not all to blame. They often discover what they do not know during the implementation phase. There goes the estimates. Managers are also notoriously bad at monitoring the progress of the schedule. Here is the memorable point from the Mythical Man Month. If you add people to a late project, the result is counter intuitive. Adding people actually makes the project later. More on this strange effect next time.
Types of Projects
One person can bang out a little program in no time. Why can't we do the same for bigger systems? To find the answer, let's consider some items more complex than a little program.A programming product is the next level up from a program. This product must have documentation. It also needs to be developed so any developer can step in and maintain it. These extra constraints mean it will take three times longer to develop than writing a little program.
Next up is the programming system. It contains multiple programs which communicate with each other. Developing such a beast takes three times longer than a programming product.
Finally we have the programming system product. This one cost even more in terms of development effort. You can quickly get to a level of complexity where the development might be problematic.
Next time I cover some issues that come up when you try to work on a programming system product.
Mythical Man Month
I finally got around to reading The Mythical Man Month. This key text has been around since 1975. I actually read the 20th anniversary additions. There were a few updates. But most of the advice still holds true today. Amazing.The book was written by the gentleman who managed production of the IBM OS/360. It is actually a collection of essays that the author penned. The OS/360 system was no walk in the park. There were late deliveries, more hardware requirements, higher costs, and low performance. I guess the hard lessons learned helped educate the author.
This text requires a lot of discussion. So I will spread out my talks about it over quite a few posts. First we need to define a couple terms used by the author. These include programming products, systems, and system products. Let's start there next time.
Bad Manager
How do you spot a bad manager? I read a whole article on the topic. Sure it was a humor piece. But many of the tendencies rang true. I guess I have worked for a lot of poor managers. Haven’t we all? I thought I would share some of these are they are precious.One such trait is that a bad manager is a vacation policeman. In other words, they are a vacation Nazi. You have to fight just to get one day off from work. On the flip side, they never say no to more work. They don’t do resource balancing. They commit you to more work that means you must work longer days and the weekends too.
Bad managers are overly concerned with their physical appearance. This is because they cannot stand on their merits. They need other ways to look good. Bad managers spend all day in Microsoft Project. This software is not inherently evil (unless you hate Microsoft). However you will accomplish nothing by trying to perfect a schedule in a project plan.
You can spot a bad manager because all they contribute in meetings is recording action items. You only hear from them when they need clarification on an action item. Weak. Bad managers are good a blaming others. How else do you think they get away being slackers? Finally a bad manager will jump ship even before the ship sinks. Why should they stick around when they know the project is doomed under their lacking skill set?
Priorities
We are a little short handed on the software development team. The workload is increasing though. Things were getting just too crazy at work this week. We have production trouble tickets to attend to. We just released some new functionality to our customer’s acceptance test team. They are generating trouble tickets as well. Finally we have new features to implement. My head was turning with all of this work on my plate.I put out a call for help. What I asked my team lead and manager was the relative priority of these tasks. The manager set a definite order of priorities from top to bottom. Then seeing how we had a number of high priority items, had me and the other key members of the team divide and conquer the list. The result was a less stressful environment. There is still a lot of work to do. But at least I am not getting killed.
These types of management tasks should have been done already. You need to either conduct resource balancing to ensure people are not over worked, or set priorities and let the low priority tasks slip. I would think that a proactive manager would attend to these tasks,. But I am not against encouraging this get done. After all, I am directed affected by the chaos otherwise.
Risk Management
I read a blog entry by Glen Alleman entitled “Risk Management is How Adults Manage Projects”. From the title, I get the impression that Glen has been on some projects that lacked adult supervision. The sad thing is that it sounds familiar. Glen had a lot to say about risks that hit home with me. I figured I would review some of his thoughts, and share some thing I learned after reading his blog.You cannot hope that things will be done in software development. Estimates from developers are usually random. You need a risk management process, as well as a risk management plan. The factors involved include cost, schedule, and performance. If you do not mitigate risk, you are already failing.
Now I have been on some software projects which lacked risk management, and they turned out fine. That may have been luck. I have also been on project with both risk management plans and processes. However many of those project failed terribly. Therefore I would not say that the presence of such a plan does not guarantee success.
Perhaps you need to do risk management correctly. The first project I was with that bombed had a risk management plan. However it was taken straight out of Risk Management 101. And it was mostly lip service to impress the customer. I will say that the customer was not impressed when the project fell apart and was deeply behind schedule when they needed it delivered.
I have been on other disaster projects that had huge risk management plans. They did a little more than provide lip service. There were processes that tracked some top risks. However the mitigation plans were totally lacking. This too resulted in huge failure. Embarrassing.
Some people who commented on the original blog entry referred to the DoD handbook. I can say that I never heard of such a thing. So I researched it on the web. The official name of that document is MIL HDBK 1908B. It covers early risk reduction through prototyping. It defines risk as a “possible loss of function and/or degradation in performance”. There is a lot more to this handbook. I just skimmed it today. It might be required reading for managers.
Lead By Example
As the author of the Software Maintenance blog can attest, a great Project Manager will lead the troops by example. Developers often need to stay late due to strict schedules. This is accepted as part of the business. One would think that the project manager of such a developer would want to stay late as well. It does not matter whether the manager has any real work to do. There is something to be said about being in a tough predicament together.Merely staying late does not immediately qualify you as a good project manager. A truly exceptional one will manager a project such that you normally do not have to stay later. However there are often circumstances beyond the best intentioned manager's control. So at the minimum you should be willing to stick around or pull the all nighter if your staff is doing the same. Otherwise the staff will be asking themselves why they should be making the sacrifice when you are not willing to do the same.
This principle is a specific case of the general one to lead your troops by example. You can make all the speeches in the world. However if your actions betray your words, even simpletons will see through your hypocrisy. Step up to the plate. Roll up your sleeves. Stay in the trenches with your developers. They will take notice.
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.
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.
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.
Putting Lessons to Work
Through some unfortunate circumstances, I got drafted into leading a software development team again. I don't like doing management type work. But I might as well do a good job while I am there. It is easier to lead when you have seen examples of good and bad leadership to learn from.
One thing I try to do it make sure I disseminate information to my team. It is no fun when you are a rank and file employee, but don't get important info from your boss. Some managers try to do this by holding regular meeting. I personally think meetings are evil and a big waste of time. So I just pass information along via e-mail. If we need a face to face, I keep the invite list small and do the meetings ad hoc.
Another thing I do is try to help developers when they get lost. I don't want to step in and do the work for them. But they frequently need guidance to make sure they do not get into trouble. And I try to take over the administrative tasks so developers can do what they do best. A developer needs access to some data? I fill out the paperwork and make all the calls to make it happen. Another developer needs some the ability to do a new task in our trouble ticket system? I submit a ticket to system administration on their behalf. I like it when a manager takes care of these things for me. I just do what I would want somebody in charge of me to do.
However not everyone is cut out for management and/or leadership. In fact, I do not think it is a good role for me. Yes I can get the job done effectively. But my self satisfaction is sacrificed. Time to see how I can get out of this role and back into development full time.
One thing I try to do it make sure I disseminate information to my team. It is no fun when you are a rank and file employee, but don't get important info from your boss. Some managers try to do this by holding regular meeting. I personally think meetings are evil and a big waste of time. So I just pass information along via e-mail. If we need a face to face, I keep the invite list small and do the meetings ad hoc.
Another thing I do is try to help developers when they get lost. I don't want to step in and do the work for them. But they frequently need guidance to make sure they do not get into trouble. And I try to take over the administrative tasks so developers can do what they do best. A developer needs access to some data? I fill out the paperwork and make all the calls to make it happen. Another developer needs some the ability to do a new task in our trouble ticket system? I submit a ticket to system administration on their behalf. I like it when a manager takes care of these things for me. I just do what I would want somebody in charge of me to do.
However not everyone is cut out for management and/or leadership. In fact, I do not think it is a good role for me. Yes I can get the job done effectively. But my self satisfaction is sacrificed. Time to see how I can get out of this role and back into development full time.
Subscribe to:
Posts (Atom)