Fractured Skill: Compartmentalising Software Development

An assembly line is where the machine or a process directs the person to perform a well-defined task. Here, the person is little more than a piece of the machinery to churn out the same product over and over again. There is no room for imagination and innovation. The human is reduced to a drudge. The pursuit of mastery is not relevant.

In his book “The Craftsman” Richard Sennett coined the term “Fractured Skill”. He laments that industrialisation has caused practical skill to be compartmentalised so that craftspeople no longer have the full experience in making.   The CAD (Computer Aided Design) package is another example of Fractured Skill. Here the engineer is working within the bounds of the CAD tool. The frequent contact with real materials is lost. The engineer may have extensive theoretical knowledge of their domain, however, they rarely go out and experience it, they have limited appreciation for how their designs materialise in the real world—the hand and the eye is divided. For this engineer, Innovation is stifled, limited by the quality of feedback that the CAD package can provide. Of course, they occasionally see their work in progress and the finished product, but he regular feedback is diminished.

“You start by sketching, then you do a drawing, then you make a model, and then you go to reality– you go to the site– and then you go back to drawing. You build up a kind of circularity between drawing and making and then back again.” -- The architect Renzo Piano quoted in The Craftsman

Fractured Skill is relevant to our craft as well, it is "fractured" at many levels. At its highest level the spectrum of skills required in our work range from Organising to Making. Organising ensures, that we are building the right thing, that we cooperate to work in the most productive way with our team our business and our end users. Making is the act of producing, verifying, and operating the software. Making includes development, testing, site automation, and operation.

The skills involved in Organising and Making are many and we cannot simply expect everyone to excel at everything. This has led to compartmentalisation. In Organising we have roles such as: Managers who coordinate/direct the team, Product Owners who usually act as proxy to users, subject matter experts (SMEs), people who represent the business, Scrum Masters who try to coordinate and remove impediments, Architects who coordinate the systems and technologies. In Making we have roles like; Front-end and Backend Developers, Automation Engineers, and Testers. Often each one of these roles represent fiefdoms where we grudgingly suffer intrusion from others.

It is not always that bad! We do sometime cooperate. For example, every time we recommend that the Tester or QA needs to be an integral part of the development team, we see agreement, although in practice they often revert back to their fiefdoms where the QA is automating tests without much knowledge of the rest of the team and where the developer is happy to know that some QA is testing their code without understanding what is being tested and how that impacts them.

The problem is much worst across the Organising and Making divide. For example, usually, the developer has very little interaction with the end user or the business. You hear sentences like: "the business sponsor is very busy and they don't have time to be talking to the development team," "we will be wasting time getting everyone to speak to the users," "I am not interested in the politics, I just want to code". This kind of attitude only serves to compartmentalise the software craft. Of course we cannot specialise in everything but also we cannot close ourselves to only our specialisations.

There is a political element to this as well. Managers, Scrum Masters, Product Owners, Agile Coaches, are in a good position to consolidate control. They also suffer from Fractured Skill because they usually do not understand the technical aspects of the software craft, even when they do they have a technical background, they suffer from imposter syndrome for not being up-to-date with the current paradigms, tools, languages, and technologies. The Making side's lack of organisational skill further widens this divide, causing the Organisation side to consolidate control through positional authority. They impose explicit or implicit hierarchy to make sure that they're adding the "right amount of pressure". They're then forced to defend this position by maintaining their fiefdoms. The Making side also resents the organisational side, often regarding them as the "necessary evil".

Architects overlap the Organisational and the Making side. Those who do not actively work in a development teams, and the business, also suffer from Fractured Skill. They loose sight of the real word on the Organising and Making spectrum. They are akin to the engineers working with CAD but with little feedback from the physical world.

Agile Coach or any other coaching role is different. Such a role is not necessarily part of the team but an external role to support the development of a specific set of skills within the team.

Are we doomed then? Will we ever bridge the Organisational and Making divide? My view is that we can never expect to specialise in everything but we can ensure that we have a working understanding of the different aspects of software development. The Organisational and Making are not sides, but two extreme of the same spectrum. The idea of the "T" shape describes the skill spectrum of individual team members who have, broad understanding of the skills across the Organisational and Making spectrum, and deep knowledge of their specialisations. For example a developer fully understands the business domain but their knowledge may not go as deep as the Business Analyst. Similarly the Business Analyst may not understand how to develop a feature on their own but they regularly pair with the developers to explore a new feature. The developers must share a good understanding of the product and the product owner must understand the technical considerations from the developers perspective. The Product Owner must understand how the Testers Verify the system and similarly the Testers must understand the product roadmap and the feedback from the customer.

The skill of an individual team member is fractured when they have little or no knowledge of another role within the team, or worst yet, when a role, that is part of the software development skill, exists outside the team. You can have someone located within the team and still not behave as a part of that team. Being part of the team means that members are in constant cooperation with each other to achieve a common goal. They are making sure, that all their work is understood and visible to the rest of the team, that the rest of the team has an active participation in their day-to-day work.

All roles within a software development team must understand that all aspects of software development concern them, albeit at different levels. These include: coordinating the project, managing risks and dependencies, understanding the customer, supporting the production system, deploying a release, and managing business and technical risk, developing and testing the features, managing the time and the budget, and more. It is difficult to be mindful of the these myriad concerns but the alternative is that you are not fully performing your role. The alternative is "Fractured Skill".

References

• The Craftsman by Richard Sennett
• Generalizing Specialists