All posts by Thomas Zeman

Order of Magnitude

I am a big fan of Carlo Pescio’s work on the Physics of Software and his way of discovering analogies in software for physical terms like force or friction. Looking at a large code base by myself every day, I could not help it and started to develop my own ideas about the structure of software code in general. What is the natural logic behind it? In the following few posts I will summarize my thoughts on this.

This first one is about a general observation: We, humans, tend to invent different names for things that are just a different order of magnitude of the same type of thing. For example when you think about places where people live together, we know a hamlet, village, town, suburb, city or metropolis. These are different words but describe the same characteristics for a place: The amount of people living there. Of course, a city is more than just a dozen joint hamlets when you consider for example available public infrastructure. However, this is a result of the size and history of the place and does not come with their descriptive. Sydney and Berlin are both a metropolis but Sydney does not have a subway whereas Berlin does.

Another example is the wording for the size of a group of soldiers: Corps, Brigade, Division, Battalion, Regiment, Company. While most people know these terms they leave a lot of room for ambiguity because except people close to the military hardly anyone knows how many soldiers a division really comprises. Contrary to having names for different levels in a hierachy (or orders of magnitude) it sound reasonable to simply number them:

AmountCodeRelates to
1-99PL1Hamlet
100-999PL2Village
1.000-9.999PL3Town
10.000-99.999PL4City
100.000-999.999PL5Larger City
1.000.000-999.999.999PL6Metropolis

So instead of talking about a “Hamlet” or “Metropolis” we could use the codes “PL1” or “PL6” which leave no room for interpretation and foster clear communication. By the way, something that has also been put into place by the NATO to describe the rank of an army officer (sharing properties of power or responsibility) – again with the goal to provide a common language for all the different ranks existing in their respective member countries. See: Nato Ranks

Another example where this idea was applied are the different levels of a CPU cache. They could have been called something like “brisk cache” or “sedate cache” but are actually just numbered: L1, L2, L3 cache. Foster clear communications.

Unfortunately when it comes to the structure of software it’s very common to talk about things like: Block, Class, Component, Bundle, Module, Building Block, Assembly, Package, Subsystem, Container, Program, System but what e.g. a “Module” or “Component” really means heavily depends on the idea and picture individuals communicating with each other have.

Flattr this!

Having conventions is lean

In this article about how software was/is written for space rockets one particular sentence stayed in my mind:

“… you can’t have people freelancing their way through software code that flies a spaceship, and then, with peoples lives depending on it, try to patch it once its in orbit”

I interpret “freelancing people” as software developers who do not care about things such as conventions, best practices and principles that a team or organization has set up. For example instead of following a common coding guideline they continue to do their own thing which in their opinion fits best. From a lean perspective this is actually nothing more than creating waste because it causes constant friction with the rest of the organization. As a result others have to use their time arguing with “freelancing developers” about their code in reviews, they need more time to understand their work or might have to rework it. It becomes tedious and frustrating for them having to deal with this situation which in turn is not good for the entire work atmosphere and can result in second level waste such as less communication. Instead of implementing the next feature together, people are stuck in senseless dicussions. Having this in mind it’s obvious that establishing and following conventions, principles and practices does not result in waste but actually helps to avoid it and increases efficency.

Flattr this!