Dealing with big systems, some considerations

As ambition goes up, organizations try to solve bigger and bigger problems. This often leads to bigger systems. This is fine, but does need some awareness of management. Bigger can be done, but it does have a price.

– As the size of the system increases, programmers (or project members) need to consider more side effects for each found error. Think of side effects like the size of the code, the quality of the code, design integrity, testability of the code, completeness of the documentation, etc. The price –> maintainability costs will suffer if these side effects decrease.

– As the size of the system increases, both the number of faults as and the number of places to look for faults will increase. The price –> both effects have a negative impact on the total time to find the fault(s).

– As the size of the system increases, the complexity of the system increases as well. This causes a problem, because one’s ability to manage complexity remains a constant. You just can’t increase the capacity of your brain (hiring smarter people has limitations), like you can increase a hard disk on your computer. Adding people to manage the complexity is limited due to Brook’s Law (Man Mythical Month).

So how to deal with these challenges?

Make use of good software engineering practices. They are invented for a good reason, use them wisely. Good engineering practices are; technical reviews, a solid definition of done, or something like a requirement management tool. But please consider the context, please don’t just apply a “best practice”.

Reduce the size of the system. Eliminate something. Yes elimination. Eliminate the scope, drop specifications, cut the worst part of the system, remove the least valuable part, eliminate that feature that isn’t finished yet.

Invest in your own people, don’t get addicted to (expensive) hired consultants.

Allow for extra time.

Note: the story still holds if you change system by project.

The map and the territory

When the map and the territory don’t agree, always believe the territory.

— Jerry Weinberg —

What does this have to do with software? Everything!

This dictum is valid in many ways:

• Does your documentation really match your software?
• If the software metrics are good, why is your software maintanence department so busy?
• The software is built conform specifications, why are users complaining?
• Are you confused/upset about a missed deadline, perhaps the plan (the map) doesn’t match reality (ouch).

My advise? Update your map, so it matches the territory. Oh, I understand that’s hard and possibly painful (on limited resources like time, money, manpower), but not updating .. is that really an option?