My opinion on the troubling trend to de-specialise Software Engineers

To apply a “Chinese-army” is nowadays an outmoded term for bringing to bear additional human resources to a problem. Far from being derogatory, it reflects the strength to be found in having a large group of people that share a common skill set.

This approach is worth considering if the task at hand is very well defined, has a low learning curve, or is consistent with the additional skills available. The term “Chinese-army” also infers that each and every member is equally capable and can be tasked with any aspect of the problem.

When the problem demands a wide variety of skills, is insufficiently defined, or complicated, a more diverse group of skilled and experienced personnel is usually required. We have a name for such a group, a team.

The drivers

Several factors are driving the “cookie-cutter developer” fixation.

The notional “Full-Stack” developer

There is another, more modern, term in common parlance “full-stack developer” that describes a software developer skilled in both the frontend (user interface) and backend (business logic and storage) layers of the technology stack. This description is in common use with recruiters trying to maximise a candidate’s earning potential. However, the reality is software developers often focus on a specific technology stack be it Java/JVM-based, Microsoft .Net or Web Technologies, etc. So when someone is described as being a “full-stack developer” the first question should be, which stack?

Even within a specific stack, most developers have a specific preference and proficiency in either frontend or backend and are seldom highly skilled with both (top to bottom). The majority of “full-stack” developers I encounter are, in reality, backend specialists with some interest in the frontend.

Homogeneous developers do not a team make

Competition between teams can be fun and productive but competition between team members usually has the opposite effect.

Over the past few years, software development using an agile methodology has proven, on the whole, to be a very effective strategy. However, within some agile approaches, there is an assumption (or a drive) that all developers are autonomous code monkeys. Converting skilled engineers with unique strengths and experiences into generic development resources. The primary thinking behind this is to establish an environment where any member of the "team" can be assigned any Story, Kanban card, or whatever is used to define a feature, to be delivered end-to-end.

If everyone on a team has equivalent skills and abilities and they are being assigned standalone tasks indiscriminately, just how coherent a team is it?

The gradual simplification of technology

Ever since the first commercial developers, over fifty years ago, there has been a determined effort to make the process of software engineering as simple as possible. The objectives being to make computer code more difficult to get wrong, easier to maintain and more scalable and adaptable to changing business requirements. The objectives have resulted in robust industrial practices and methodologies, innovative software concepts and paradigms, and a gradual lowering of any barrier to entry.

A recurrent question in the industry media is “Do you need a Computer Science (or any) degree to become a software developer?” That indicates, to me, we are reaching a critical point in the industry’s maturity. However, I think the question we should be asking is “How simple do we want/need to make software development?” Also, as we head (reportedly) towards “low-code” and “no-code” development systems, who is going to develop and nurture the next generation, and from where is the next innovation going to come? Possible Quantum Computers.

There is also a potentially hazardous combination emerging. We have a continual lowering of the barrier to entry to the point that we no longer demand having truly qualified developers. Our society is gaining a dependency on software systems in all aspects of our lives.

In conclusion

I think that attempting to populate “teams” with experienced software developers - with a common and broad set of skills - is ill-considered, unachievable, and devalues every software engineer and the profession as a whole. At the same time we appear to be engaging underqualified developers when our reliance on robust software systems is growing.

If organisations become interested only in engaging developers with a broad and in-depth knowledge, how are young developers expected to acquire the necessary skills and experience to enter the workplace? That sounds like a dead-end strategy to me.