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?

Technology Transfer (part II)

Monday, the Technology Transfer started. What happened? Well, take an educated guess. We are still trying to find out what when wrong and why…sigh. No news anymore from the migration team. Yeah, let maintenance solve it…..sigh.

The Plan
Yes, the migration team made a plan. Thou salt have a plan to lead thee out of the wilderness.

It was a specific plan, very detailed. The plan contained activities, durations and involved people. Not bad, a plan helps building structure. Unfortunately, something went wrong (OMG). How was that possible? Hmmm the plan lacked an activity called “solving problems”…

Simple math
The assumption of the plan was that all the activities would be successful (100%), none would fail. Let’s think. What is the assumption was different? What if we say that each activity had a low probability of failing, say 5%. That means that the chance that at least one of them will fail is nearly 65%. That is, one minus the 20th power of 0.95. That’s no rocket science, but simple basic Math.

I don’t know yet when we will finish this migration. Luckily, this was the migration of the Acceptance Environment.

No happy ending yet…..

The Ten Commandments of Technology Transfer

Technology Transfers, I just dislike them, especially when they are driven by the IT department. No matter what they tell you, it’s always more complex and end users usually suffer.

A major Technology Transfer is currently taking place in my organisation. The Big Cheese decided all applications will have to move from the current data centre to a brand new one. Sure, if the Big Cheese decides so, it will happen. What could possible go wrong? It’s “only” moving a server to another place…the software doesn’t change. This can be done quickly.

May I suggest a little reading dear Project Team? Try Quality Software Management volume 4 Anticipating Change, chapter 23.5 Jerry Weinberg discusses his Ten Commandments of Technology Transfer;

  • Thou shalt have a plan to lead thee out of the wilderness.
  • Thou shalt not worship thy plan.
  • Thou shalt not ask for no person in vain.
  • Thou shalt not work 7 days a week.
  • Thou shalt honor thy users and listen to them.
  • Thou shalt not kill support for change.
  • Thou shalt not adulterate from the work.
  • Thou shalt not steal resources from the work.
  • Thou shalt not bear false witness against thy plan.
  • Thou shalt not covet they neighbor’s optimal technology.

After reading this chapter, please don’t ask me to agree with a testing period of maximum 10 minutes. Don’t be upset anymore if I don’t want to work on my free day, after all it is my day off. I spend my days with my kids, and you didn’t consult them when you made your planning. I wish you all the best with the Technology Transfer, you will need luck.

Much appreciated.

Bug? No it’s a non documented feature!

Don’t you just love those kinds of discussions? I love to hear them from other people. Yesterday it happened to me. I received this e-mail after some previous phone calls earlier this week.

From: Frank
Aan: Ronald
Subject: Proposal regarding “prefix” issue

Hi Ronald,

The application, we are talking versions 2.5 up to 2.9 contained department names that were not unique. Therefore, prefixes (XC, YD, YD) were used to uniquely identify them. This prefix mechanism was and still is used for data import of departments, and also to create the filter terms in the GUI. There was no requirement to change this behaviour for release 3.0 (this release is currently under development), on the other hand it is kind of hidden requirement to you, because obviously it was forgotten to document it in the SSS. So since you were not aware of that feature, you didn’t request to change it in version 3.0, consequently.

Therefore, I would like to propose the following:

  • <Some information which is irrelevant for this blog>

Thanks, best regards,

My thoughts while reading this e-mail;

    • There was no requirement to change this behaviour for release 3.0
    • On the other hand it is kind of hidden requirement to you
    • Because obviously it was forgotten to document it in the SSS
    • So since you were not aware of that feature
    • You didn’t request to change it in version 3.0, consequently.

Hmmm fascinating sentences. So we are talking about a “kind of hidden requirement”…which is “obviously” forgotten to document….and because of that I was not aware …and didn’t do the proper request…which got us into this (small) mess.My first reaction was: yeah right…blablabla…change it the way I want it and don’t even think of wasting my precious time on this issue anymore.But then….hmmm….when is a specification ever complete? Let me share a secret with you……specifications are very rarely ever complete. There is such a thing like the existence of non documented features in applications. So Frank can be totally right, even when I’m not aware of this hidden not documented requirement. Luckily the effort to fix the issue was minor, just a few hours, hardly discussion the issue to long. So we reached an agreement fast. But the value to me is great; it reminds me something I forgot for a while: the notion that specifications are incomplete almost by definition and that it can take several releases until you find out this incompleteness.

Microsoft fixes ’19-year-old’ bug

IBM researchers discovered the flaw, which affects Windows and Office products, in May this year – but worked with Microsoft to fix the problem before going public.

The bug had been present in every version of Windows since 95, IBM said. Attackers could exploit the bug to remotely control a PC, and so users are being urged to download updates.” (BBC, 12 November,

Wow, fixing a critical bug in the software that had existed for 19 years. 19 years!

I can’t even estimate the amount of testing hours Microsoft did over the years, 19 years it took them to find this bug. According to IBM the bug had been “sitting in plain sight”. (how rude to hide in plain sight)

So this happened to Microsoft, could it happen to all of us? Missing a bug, missing a critical bug for 19 years? Even if you test the software, you asked those testers to test “all” didn’t you? Making a decision to release the software with that bug?


Yes it happens all the time, because we seem to forget/ignore the fact that testing is sampling. There is no way you can test 100% of your software product. You don’t have the time and money to do it. Sure you are testing “risk based” perhaps even in an agile environment.  It is no guarantee you find all your critical bugs.

Microsoft just reminded me of the lesson that you never know all the information about the quality of the product at the time you need it. I’ll apply this lesson next time I hear some saying “I’m done with the testing”.

Probably a couple new bugs

Release notes are specific to each version of the application. You hope to find what you’re looking for, valuable information. Mindless Dribble Inc. updated their GroupMe software recently. Hereby the release notes (

What’s New in Version 5.0.4
– Can paste GIFs again!
– Can meme on iPad again!
– Can now see full names of people who like messages and start DMs from their like avatars!
– Can share photos from the Messages app again!
– Many minor bug fixes.
Probably a couple new bugs.

If you have additional feedback or issues, please don’t hesitate to send us a line at And if you’re enjoying the app, we more than appreciate positive reviews in the app store. Thanks!

Mindless Dribble knows about;
– Early bug findings are the best predictor of a component’s future behavior.
– The Fault Feedback Ratio (FFR) – the % of fixes that actually feed another bug into the system

I appreciate both professionalism and honesty of the company in its release notes. I promise I keep working with the software and report any issues found.