The human aspect

Spinning Jenny by T. E. Nicholson (1835)

Computer science evolves faster than any other engineering field, as a result developer skills erode at the same rate. It took a decade for electronic design to switch from analog to digital.  Such long transition periods that is in parity with personel churn are things of the past.

SW programming is no longer a universal skill set. SW splits into ever increasingly specialized silos. UI design and embedded systems may have shared programming language and tools in the 90'ies, today they are far apart.  Significant new tools and technologies are spawned every other year. They offer new ways to improve our SW manufacture and design.

These specialized Domain Specific Languages, such as XAML and QML for UI, gets more done with less effort. The associated environments are more productive in their applicable fileds, but new tools and languages require new skills. Programmers have to learn how to handle these more productive environments.

The old stuff works fine, so why change it? New technology is often limited and have teathing problems. From a product perspective the present technology is just fine, possibly even critical.

New technologies and tools need to be adopted from a productivity perspective. Rationalization and future skill availability are critical long term parameters. This calls for a new attitude, maybe even breed of developers. It is not just a matter of being able to solve problems but more about how efficient it can be done and about freeing resources.

Know How and Productivity

Neanderthals kept applying the same technology and tools to all problems even as the world around them changed. A surprisingly successful strategy executed by skilled experts. Similarly companies become increasingly dependent on key individuals with increasingly exotic know how.

It is a rational short term strategy but over time it proves increasingly ineffective. You can kill a rabbit with a spear but it is easier to trap it with a snare. Less skilled spear hunters will find the need to hunt wider areas as the number of mamuts dwindle. Specialization in SW leads to a similar career. Just as our distant cousins, humans resist all forms of change in general. Engineers also entangle what they know with who they are. Skills becomes synonymous with the sense of worth. A change may interfere with deep sentiments linked to identity, prestige and hierarchies.

Engineers will to stick with to marginalized expertise/identity to the point of a personal identity crisis. Job security through key skills is an illusion, it doesn't last an entire career. SW professional have to add a new major area of expertise many times during a career, or find a wider market. Almost all languages and environment offers some sort of solution to general programming problems. The neanderthal effect compels developers to stick with familiar tools and use it for everything, no matter how clumsy it is.

Technical evolution is easily dismissed from a product perspective. There is the “sunk investment”, “special circumstances” or, when all else fails, the ever popular “later” or "after".  The arguments are misdirected, it is not the products that need renovation; it is about produce-ability and stagnation prevention.

Kill the double heroes

The double hero delivers on time and works late to fix bugs. They are the programmer role models, or are they ?

They deliver on key performance indicators that management are tied to. The misguided appreciation can cause major damage to a system. Not only are the initial faults bad, but emergency patches may clear the symptom but actually makes the patient worse off.

The double hero lacks the inner laziness that drives innovation and desire to escape intellectually monotone work. SW community struggles with this conflict between peer and management appreciation. Management often fear that programmers will embark on abstract, but most importantly unsellable, enterprises if not controlled. The loss of revenue due to delays is real and tangible. The reason for this fear is that the SW engineers failed to explain the cost benefits of these abstract activities.

To some extent management needs to understand SW development better. Agile evolved as a grass root reaction movement to this. The idea was to trade control by offering management feature productivity. The key selling point for going agile is to turn up the production rate.  Agile stress' that the key performance indicator is working code. When this is translated to externally observable program traits, we get a feature bias situation. The agile manifesto has a code excellence criteria from which working code should be judge by to balance this.

Management see a chance to wrestle control away from the engineers promises of pie in the sky and non-profitable code. SW Engineers on the other hand must to learn to quantify abstract enterprises into saved € on the bottom line of the quarterly report. Features become revenue and production rationalization is future cost reduction.

 

Code performance needs to be evaluated on its inner properties as well as the observable features. The inner qualities of code then needs to be put in direct relation to development costs. Most importantly the we have to look at the cost of adding another feature, the feature resistance.  Feature resistance is proportional to the system complexity, but what levels can be tolerated depends on the staff performance. The guarantee costs are clear indicators of the double hero effect. It is important to understand that complexity and performance is therefore not uniform in a system.

Complexity and bugs must be measured on a subsystem level and related to the skill level of the available developers. We can then easily target our double heroes as well as our problem areas in the SW. Using structured refactoring the complexty can be reduced. Most importantly an active HR and targeted training efforts towards developers as well management can dismantle the double heroism culture.

A new breed of SW Engineers

Agile teams tr mimic the structure and drive of small start-up companies. This is an environment of multi-talented developers rather than indispensable specialists. There is simply not enough work to support exclusive specialists.

Key assets with indispensable product insights lasts as long as the product and technology remains stable. The job security is neutralized by the short product and technology lifespan in the SW industry.

Agile implies constant change, that also applies to the engineers. Intellectual capital gathers dust very fast in the SW field.

Specialization invariably lead to to product stagnation. The observational bias keeps pulling solutions from a familiar tool box. It builds a pressure for change and rejuvenation. However few are keen to retire after a decade, power point architecture or management offers some an alternative escape.

Evaluating individuals competence towards the current job market has many positive trade offs. Jumping on to a new technology while current skills are in demand is much easier on the ego. Agile developers value mobility and should align their skills to market. Multi-skilled engineers can easily migrate between teams.

This new breed of agile SW engineers are skeptical and multi-skilled professionals. There is none or little common background knowledge level in this group. These engineers oscillates from beginners to experts depending on the subject. Their insights also makes them challenge what is presented, and make a good case of it.

Training junior developers to get up to speed is simple in comparison. Beginners have a similar background knowledge, as in none, and they are generally open vessels. The senior developers need a different type of curriculum and much tougher teachers.

Not only is it difficult to find challenging courses or seminars that fits. Professionals need it to discuss problems from their specific circumstances and the problems they face.