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.