Experimentation vs optimisation

Anne Nygård

As with every part of software development, fashion drives how teams organise themselves. Splitting teams into front-end and back-end sub-teams, for example, became fashionable more than ten years ago. I’d like to see something new.

Front-end vs back-end developers

When web application development teams split into front-end and back-end sub-teams, each one uses a different set of skills and technologies. They target different runtime environments, such as web browsers or application servers.

This specialisation increases the team’s expertise in each area, and with it, the range of what they can build. This introduces the cost of needing two developers – one front-end and one back-end – to implement a typical product change, and two more to review their work.
Meanwhile, some developers or even whole teams reject this sub-specialisation, and identify as full-stack developers.

Full-stack developers typically don’t maintain the whole software stack, from compiler to HTML renderer, or from database management system to web browser. But they do cover both the front-end and back-end architecture layers. By avoiding the usual sub-specialisation, they have the opportunity to choose a different one.

Stop starting and start finishing

This reminds me of a development team whose tech lead became increasingly frustrated with what felt like a lack of discipline among the developers. Every day, they started work on new development tasks, but never seemed to pay attention to finishing them. Code reviews piled up in their ‘Kanban’ board column, while every developer seemed to have two or three tasks in progress. The tech lead would tell them to ‘stop starting and start finishing’.

A process-centric view of this situation leads to the theory of constraints and Kanban work-in-progress limits. To the agile software development methodologist, it seems obvious that work will flow better if you start each morning and afternoon with a task as far to the right on the board as possible. But when this doesn’t work, and people persist in starting new tasks, perhaps a people-centric perspective would help.

Experimentation vs optimisation

Each development team has a different collective character. Some teams come up with great ideas, prototypes and demos, but struggle to really finish features, or deliver a high-quality user experience. Other teams make software really good, but never seem to invent great new product capabilities.

Some people lean towards new ideas and experimentation, while others find satisfaction in incremental improvement and optimisation. Depending on the kind of software a team builds, and its lifecycle phase, they may struggle if they don’t balance these two aptitudes. Teams need both starters and finishers, and enough of each.

Personality types

Personality type models, such as the infamous Myers–Briggs Type Indicator and Which cartoon character are you? quizzes, deserve their bad reputation. But despite their occasional cult-like following and subsequent backlash against them, people who work in tech often find value in discussing wrong models, even if only ironically.

An explicit policy to form teams of both experimenting and optimising developers would end badly, no doubt. But taken less literally, the idea that members of a team might prefer one kind of work shows more empathy than assuming that team members lack discipline. Perhaps they do, of course, but you probably shouldn’t start there.