Over a million developers have joined DZone.

Fractured Skill: Compartmentalizing Software Development

DZone's Guide to

Fractured Skill: Compartmentalizing Software Development

Sometimes, development companies resemble assembly lines: you do this, over and over, and we'll get a product. But it should look more like an artisan's shop.

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

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 industrialization has caused practical skill to be compartmentalized 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 materialize in the real world—the hand and the eye are 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 his 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 Organizing to Making. Organizing 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 Organizing and Making are many and we cannot simply expect everyone to excel at everything. This has led to compartmentalization. In Organizing, we have roles such as Managers who coordinate/direct the team, Product Owners who usually act as a 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 represents fiefdoms where we grudgingly suffer intrusion from others.

It is not always that bad! We do sometimes 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 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 Organizing 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 compartmentalize the software craft. Of course, we cannot specialize in everything but we also cannot close ourselves to only our specializations.

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 organizational skill further widens this divide, causing the Organization 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 organizational side, often regarding them as the "necessary evil."

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

Agile Coaches 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 Organizational and Making divide? My view is that we can never expect to specialize in everything but we can ensure that we have a working understanding of the different aspects of software development. The Organizational and Making are not sides, but two extremes on the same spectrum. The idea of the "T" shape describes the skill spectrum of individual team members who have a broad understanding of the skills across the Organizational and Making spectrum and deep knowledge of their specializations. 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 developer's 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, 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 these myriad concerns but the alternative is that you are not fully performing your role. The alternative is "Fractured Skill."

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  

software craftsmanship ,agile ,agile teams

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}