Century Support Part 3 - The social aspect

This guest article by Carsten Pitz is the third part on the subject of long-term support. In the first part Carsten describes the development of a documentation system in which second parthow the wrong start can quickly lead to problems. But so far he has only said how NOT to do it. But how do you do it right?

This series of articles led to several discussions between Carsten and me, as we sometimes had different views on the solutions. But such discussions are exactly what makes writing a blog so complicated.

In this third part, Carsten gives us an insight into the social aspects he sees in Century Support. We hope you enjoy reading it.

Prelude and thanksgiving

The social aspects of Century Support described here have led to some discussions between Michael Jastram and myself. I thought two comments were so important for understanding that I have included them in the text. Many thanks to Michael for the open, focused discussion.

In addition, a senior government official (ORR) from my current client gave me a number of extremely valuable tips.

Warnings are ignored, or: Why documentation is not the solution

Mark far above the Fukushima Daiichi nuclear power plant in Japan Hundreds of stones with inscriptions a line under which construction should not take place. These stones are over 600 years old and describe the effects of a tsunami.

Modern science had relegated a tsunami with the impact described on the stones to the realm of fantasy. Despite the warnings, the Fukushima Daiichi nuclear power plant was built directly on the coastline in an area at risk from tsunamis.

Suddenly, in August 2013, there was another tsunami. It wasn't a fairy tale after all, what was carved by hand on the hundreds of stones. And the pain was suddenly great again. Many people were killed directly by the tsunami. The Fukushima Daiichi nuclear power plant was massively destroyed by the tsunami, the nuclear reactors went out of control and large quantities of highly toxic, radioactive material were released. Many people have already died as a result of the reactor disaster and many more will die of cancer as a result of their radioactive poisoning.

After 4 generations (100 years), warnings become myths [tweetthis]After 4 generations (100 years), warnings become myths (Carsten Pitz)[/tweetthis]

From the 4th generation onwards, warnings become myths. Why? Ask yourself the following questions:

• Have you ever had a discussion with your great-grandparents?
• Do you know your great-grandparents?
• Your great-grandparents were probably just as smart as you are!

Conclusion: Warnings are ignored from the 4th generation at the latest. Documentation is not a solution, as the Fikishama example illustrates in an alarming way

My approach - enabling change

Changes are unavoidable, with Century Support anyway. Being adaptable is the ability to respond appropriately to change. Change can be of a technical or social nature. OK, but how?

Being adaptable is the ability to respond appropriately to change (Carsten Pitz) [tweetthis]Being adaptable is the ability to respond appropriately to change (Carsten Pitz)[/tweetthis]

Our task is to enable change in the present. It is also our task to teach the next generation to live the change. This is how we make a start. At some point, we pass the baton to the next generation and the next generation takes over. To create a common basis for understanding my approach, here are three brief and at first glance inappropriate excursions.

Excursus 1 - Charles Darwin: "Survival of the Fittest"

According to Charles Darwin, staying fit means being able to adapt. Only the fittest species survive, the rest die out. It is important to internalize this: A species adapts, not a single individual.

Excursus 2 - The "support trap"

I picked up the term "support trap" from an IBM sales representative. It refers to the phenomenon that "fresh" developers are regularly bought in for new developments. Once the product is on the market, the majority of these developers leave within a short time. The remaining maintenance developers do not have the expertise to develop new, easily maintainable components. Maintenance developers do not have a view of the application architecture as a whole. Symptomatic error handling takes place and the architecture rots.

Incidentally, Michael Jastram has had different experiences, so there are already software manufacturers who avoid the support trap. The key point here, however, is whether software development is a central part of the business model (product) or just a cost factor (internal application development).

Excursus 3 - Numerous species are more stable

Observations from ecology, a branch of biology, consistently show that numerous species are more stable. More stable means being able to adapt better to changing environmental conditions and therefore being more durable.

But what does that mean in the context of product development? An interpretation is a large team. However, this is associated with high costs. Every single person in the team costs money, a lot of money. On the other hand, we must not fall into the support trap. How do we get out of this dilemma?

My approach

The rationale behind my approach is the question: Why should a team only work on one project?

Michael Jastram commented: "I have often seen a team working on several projects at the same time, especially in the Client Services area. This allowed for better time management, as client work tended to be uneven."

In order to take this objection into account, I would first like to clarify the term "project". In the sense of Wikipedia definition I do not consider the creation of a single client service to be an independent project. I assume that the client services were created by a line organization. A separate dedicated project management was not set up for each client service.

In my experience, you will only receive answers to the question "Why is a team only allowed to work on one project?", if at all, that evade the question but do not provide a real reason. From my perspective, it makes perfect sense for a team to only have one task at a time. However, this does not mean that a team can only work on one project. In my view, this is simply a habit. It is a habit that a team is set up for a project that becomes obsolete after the project is the project team.

If a team is seen as a group of people who know each other, know how to talk to each other and form a well-coordinated team, new possibilities arise. Incidentally, the above definition of a team is extremely common in sport - a soccer team, for example, also plays several tournaments together - and is therefore nothing new.

Back to the topic, the new possibilities: If a team is not tied to one project, it can support multiple projects. Since 20% of the people needed for development are obviously enough to maintain an application anyway, this naturally results in an 80/20 ratio of development to maintenance. The team is 80% busy with innovative, intellectually stimulating tasks and 20% with maintenance tasks.

This 80/20 mix does not deter innovative seniors or fresh juniors. The team remains attractive for innovative people and can renew itself smoothly. This fluid renewal is important because it allows enough time to transfer knowledge from the seniors to the juniors. If a new team member fits in well with the team, the transfer of knowledge happens subconsciously, implicitly. If the new, well-fitting team member is a junior, seniors see the new junior as their "child" and subconsciously impart their knowledge to them. The new junior accepts the seniors as "parents" and accepts the seniors' knowledge. If the new, well-fitting team member is a senior, he or she is accepted as an equal partner of the other seniors. If a new team member does not fit into the team, they should not be forcibly integrated. An unsuitable team member must leave the team.

Again, Michael's comment that he has experienced this, particularly in the US start-ups where he has worked. There, new employees in particular were provided with mentors who did this knowledge transfer; jobs were rotated on request to get to know other parts of the organization; and goal-based (not project-based) management to retain employees and their knowledge.

A critical phase in such a team, as in "real" life, is "puberty". During puberty, children emancipate themselves from their parents. Parents still want to be good parents for their children. As a result, parents often don't let their children have their way during this time. In turn, children want to stand on their own two feet, live their own lives and realize their own ideas. And this urge of the children becomes stronger and stronger. This often leads to arguments.

Quarrel? Puberty? And in a business context?
I will answer this question after I have explained what evolutionary advantage a species gains through puberty.

Puberty, a tool of evolution

A species only survives if it can adapt to changing environmental conditions. Although parents generally have significantly more experience than their children, they are trapped in their experiences and the habits and views that have developed from them. This limits the parents' ability to adapt. Children are not yet trapped in their habits and views. The ability to adapt is therefore much more pronounced in children than in parents. Puberty is therefore necessary for the preservation of the species.

Applied to our team, this means that the seniors should allow the juniors to go through puberty and emancipation. Over time, the relationship must change from a parent-child relationship to a relationship of equal partners. Juniors become seniors and thus equal sparring partners for the older seniors.

The team remains innovative, remains capable of adapting to changing "environmental conditions".
What sounds so simple and natural is, however, extremely difficult to put into practice. A team like this needs supervision. It must be observed and supervised by outsiders. The supervisors' task is to observe the group dynamics within the team and intervene to correct them if necessary. This also includes helping juniors to emancipate themselves and checking whether a new team member fits into the team. Supervisors are psychologically trained employees without too much interest in the technical challenges, who focus their observation on the interpersonal relationship level. The plural for supervisors is chosen deliberately, as the supervisors also have to advise each other. This means that an independent team of supervisors supervises several development teams.

"It worked for one employer because we had a talented VP of Technology who set and demanded clear guidelines, for example via strict coding standards. Although this was sometimes more dictatorship than group dynamics, it worked extremely well."

This can work very well in the short term. However, as history shows, dictators all too often leave behind a power vacuum after their demise, which quickly leads to a power struggle. Accordingly, this approach jeopardizes generational change.

Michael again: "Now we are back to a leadership issue and good leadership includes, among other things, filling such a position quickly and competently. I recently described a technique for this„.

In addition, it has already been noted that "documentation is not a solution". As a little mean cliff hanger: I'll come back to the topic of documentation later.

Checkpoint: What level of coverage have we currently achieved?

We have dealt with the handling of generational changes by four generations corresponding to 100 years. We have also looked at how to deal with social change. This leaves only the handling of technical change. This will be the subject of the following articles.

We have now covered approximately 75% of the question. Then let's take a little break.
Even if the remaining 25% don't sound like much at first, there are still a few hurdles to overcome. So, my suggestion: let's take a little break!

Thank you and see you next time.

Image source Tsunami stone: Wikimedia