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.