System thinking – 1

One concept that always fascinated me is the whole-parts thing. How the parts become a whole and how you can dissemble the whole into parts.

System thinking is just a thing about it. Usually, when we try to analize some system, we break it into parts and try to understand each part. Once this is done, we hope to understand how the whole thing is working together. However, there are times where breaking into parts misleads.

This is where System Thinking is coming into play (bing for it). It says that sometimes you better off thinking hollistically instead of zooming in as much as possible.

This is an example from software development.

Sometimes it seems that every fixed bug causes 5 regression bugs. In this case the most common response is to make more checks on the code before check-in. this is how it looks graphically:

 

What it means is that when "Regression bugs" raise, the process increases. Notice the "+" on the arrow from bugs to process circle. Now, this is something that we decide.

An arrow from process to bugs is something that we anticipate. The arrow is marked with "-" meaning that when process increases we anticipate that the number of regression bugs goes down. Notice that the number of "-" signs on this loop is odd, meaning that this is a balancing loop. Or in other words, it will stabilize itself.

This is "divide and conquer" approach.

However, from experience it is not always works out like this. Thus, if we turn to hollistic system thinking we get another picture:

This picture introduces another feedback loop. The new loop has 2 (even) "-" arrows in it. This means that this is reinforcing loop and it can go wild.

Clearly, this is a simplified view of the process, but even in this simplified view there are two loops that battle one another.

If reinforcing loop wins, then introducing more process wil not make the situation better. In this situation, it is probably better to educate people to fight off this loop.

to be continued ...

API not changes

I have been to Configuration Management meeting this week. The topic was pre-checkin validations. I will write about them later, but now I want to talk about small sub-topic that was raised during this meeting: description of checkin.

For example, I check-in some file. Let's say README.txt. A little, 19-inch wide, window pops up where I have to fill in few fields. Some of them are completely sensible and some are over the top in my opinion. The entire practice of describing the checkin is totally common. Once I myself defined log format and implemented some system for enforcing long-enough comments. However, the devil is in the details.

In this constellation, there are quite a bit more fields than just a formatted description. For example:

• code reviewer. What the hell?!?!? If you don't trust me enough to checkin the code, why pay me money at all?
• Unit-test: passed, failed, not applicable. Once again. If I, as a professional developer, decide that this code is good enough to be checked-in, then let me decide whether unit tests should be executed or not. Do not make it a-must.
• UI changes. I can understand the need for it, but does it mean that I checkin a code that should have UI, but does not have. Meaning that there is no way to use this code right now? In addition it means, that I have checked in partial code, as some of the code is missing (UI part), which is exactly this field is about.

There were other fields, but one of the managers wanted a new checkbox called: "API change". The reasoning was that: "I want to know that API has changed as it is important. It can break other modules".

First. If you checkin a code that breaks other modules, then you are doing it wrong. Checkbox or no checkbox.

Second, API changes are not dangerous. They are visible. They break build, things stop working. The dangerous changes are those that do not change API, but change the behavior of the code. Class signature remains the same, but its logic changes. These are the dangerous changes.

So maybe there should be a checkbox: "Dangerous change". If the developer feels that the code he just checked-in is dangerous, he should check it. Probably, there should also be a reason to explain why this code is dangerous. Maybe, another field with a name of the person who approved checkin of a dangerous code.

This idea can be taken even further. There might be a checkbox called: "There is a bug in this checkin".

Suckodrom #1: Transition to IPv6

Talk down IPv6 is like kicking in da balls already knocked out man. Image, you are one of the top professionals, you defined a new IP standard of the future. You publish it to the world (in 1996!!!). Nobody pays any attention. Years pass by. Slowly it take off. Every year it seems like the next year or two it will burst forward. It doesn't. And then some anonymous blogger, which will be me, comes and posts a critisism of your 12 years old work. Luckily, nobody reads this blog, as in general me talking down IPv6 is like kicking knocked out man in da balls in a dark alley where nobody can see me. Not something I will tell my parents.

I have no problem, yet, with IPv6 protocol per se. I think that we are unlucky being stuck with IPv4. However, the transition to IPv6 sucks big time. Clearly, two protocols (4 and 6) will run side by side for years and years. And then IPv4 will continue to run in data centers disguised as IPv6 for even more years. So you would imagine that transition is a pretty important subject. It is, and it has been under intensive research. Just take a look at IPv6 Wikipedia entry to see the number of references and RFCs. Unluckily, transition still sucks.

1. NAT-PT. It was designated as a device/software that will translate from IPv4 to IPv6 and vice versa in a completely transparent way. In addition to architectural problems of NAT-PT there is a performance thing. It is slow. It slows down the traffic and does not make IPv6 looks good.
2. Tunneling technologies. There are few of those: ISATAP, 6to4 and Teredo. There is inherit problem with all tunnels: they waste bandwidth. They make IPv6 "feel" slower than IPv4, which reduces the drive to move to the new technology.
3. End-to-end IPSec. IPv6 hosts must support IPSec. The problem is that end-to-end authentication cannot work with NAT-PT. This means that there are severe limitations on topology. If IPv6 host wants to talk to IPv4 host with end-to-end IPSec, the traffic cannot pass NAT-PT. What if you do pass NAT-PT and you have to work with IPSec, after all it is a must for IPv6, then what do you do? You fall back to IPv4.

The world will move to IPv6 in time, South Korea and Japan are good examples. However, it does sucks that the transition itself is puts potential customers from the protocol.

This post is short. I am still getting on track with this blog thing.

Comrade Trotzky

I am a newbie in MS. As a good American company MS appointed someone to be my buddy. This idea is not specific to MS, but rather common in the industry. Buddy's job is to teach me the company ways, answer my questions, take me to lunch, guide me through the first days (or maybe weeks, if I am a slow learner) in the company. Managers usual choose one of the nicest persons on a team to be a buddy for a newcomer. The newcomer is in a vulnerable situation: he does not know much about the group, he has no idea what are the problems of the product, he didn't see the code, he never debugged the product, his development environment is not set, when build fails he does not know what to do, he is not aware of all possible tools, he has no idea who is who on the team, so he might take advice from the most dumb person that was fired a week ago but still cannot find its way to the elevator. Buddy remedies this situation. Suddenly there is someone from "inside" who can explain the situation to the newcomer. It is much less threatening to enter a team this way, as it is like you already have a friend. It is like you are coming to a party Great idea, this buddy thing. There are few caveats thought.

1. Newbie and buddy should be of the same intellectual level. Neither "smart newbie and dumb buddy" nor "dumb newbie and smart buddy" will work. It is either "dumb and dumb" or "smart and smart", can't be any other way.
2. "Smart and smart" situation is problematic as you get a competition situation in many cases. Newbie has to prove his worthiness, while buddy has to establish himself as an alpha developer according to his buddy position.
3. Companies in general ignore social dynamics related to sexes. For example, if newbie is "he" and buddy is "she", in many cases newbie will work harder to prove himself than in case the buddy were "he". The opposite case ("she" newbie and "he" buddy) works much better, as buddy will go extra mile to impress newbie.

So the problem is when you hire a smart "he" developer. You cannot appoint him dumb buddy, as the buddy willl teach newbie how to use coffee machine during the first week boring the poor newbie to death. You can appoint a smart "he" or "she" buddy, but be ready for some friction, which kind of negates the idea of the buddyship.

Obviously a manly guy like me finds himself in "smart smart" situation. My buddy proved that he is a smart guy by brilliantly playing his part. He came to me after I have been a week at the job and said:

"Hi. I am your buddy. If you have questions you can ask me."

He never come to me again, but was ready to answer my questions.

This is the way!!!

He showed me the real, hard day-to-day work:

Not some pansy "eeha, we are having such a great time here. we are such a nive people!" This is the way. Respect your newbies. Throw them into a deep water and let them swim. If they will have a question they will come. Not everyone will survive, but those who do will become your true comprades.

Not like comprade Trotzky.