Should Details Matter to Software Engineering?

“It’s just a detail.” Have you ever said that or been told that? Whether it’s about software engineering or development, we often use the word “detail” to suggest that something is not important enough to worry about. Prior to his talk at Codemotion Online Tech Conference, I sat down and spoke with Kevlin Henney to find out what he’s preoccupied with the value of detail. 

Kevlin is an independent consultant and trainer based in the UK. His development interests are in patterns, programming, practice and process. He has been a columnist for various magazines and web sites, including Better Software and The Register. Kevlin is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know and co-editor of 97 Things Every Java Programmer Should Know.

What is the problem with detail in software engineering? 

Kevlin asserts: “I sometimes think the reason we downgrade the idea of detail is because people want to focus on the big picture. Typically, we develop software for a purpose. Therefore, that purpose becomes the big thing. It’s the vision, it’s the goal, and it defines where we want to go, and how we want to do something. And the rest is just details; it’s just working it out as if somehow that is automatic and not important to the software.

“But the problem is that when we actually code something, we’re coding in detail. It turns out those details are significant and dominant because when you come to write code, you have to commit to detail. The challenge here is one of precision. You need to be precise about everything.”

The value of detail in software engineering

According to Kevlin, the discovery of the value of work is in doing the work:

“It is not that we figure out what we’re going to do and then we do it. That’s a beautiful fantasy that people have maintained for decades. It sounds very tidy, which is why we’re attracted to it. But it turns out that in the detail is where we discover what the shape of the work is. And we also discover other work, things that we had not previously seen. We’re always surprised when a detail turns out to be way more important than we had anticipated, partly because we dismissed it and then rediscovered it.”

The impact of automation in software engineering

With the push to no-code will we in the future leave software automation to sort out the details while we focus on more interesting pursuits and challenges? 

According to Kevlin, “A programming language is not just an arrangement of syntax. When we hit the code, there is a commitment to detail. You have to say precisely what you mean. When you are programming, you are committing to a level of detail where you have understood and defined everything that should happen.”

He gives the example of developers creating accounting software:

 “Did you want it for a person or a whole company? How many people should it support? What should the security model be? These are not implementation details: they’re central to the viability of your product and how it will be used. And when you start talking about the accountancy, well, could you explain the rules to me? Suddenly, you have entered another world of detail there. The idea of an intuitive interface differs wildly as your intuition is not the same as mine. I need to understand your workflow. What about the currencies that should be supported? What about governance?”

Kevlin asserts that by the time we get code automation tools, they’re not going to make a major impact: “They’re not game changers because we’ll discover that people are left with the same problem. What are we trying to say? And how do we say it?”

How can we apply a detail-driven mentality to teams and how dev teams function?

Kevlin contends that one of the reasons people push back is in an effort to control the flow of information. 

“Many programming paradigms are inherently trying to reduce the amount of things I need to focus on at any one time. We have a lot of detail, which is why people push back on it: we can become overwhelmed. It turns out not everything is equally important at the same time.” 

People are not always working with complete knowledge and are likely to possess biases and blind spots. This is one of the main benefits of a team:

“Someone else might not have those same blind spots. Software developers are fairly smart, but you can actually get better intelligence across the group — distributed cognition. Thus, one of the purposes of a team is to think in ways that an individual can’t. It is, quite literally, to think bigger.”

To ensure a team that provides extended intelligence, Kevlin believes diversity in the team composition is essential. “Different people will see different details; they spot other people‘s gaps when they focus on different things from a different perspective. Software is about capturing the details, framing them, collating them. We must not think the same. A detailed-oriented view highlights both our strengths and weaknesses as individuals. We don’t actually develop software individually. That’s not what companies do. It is a collective activity. So let’s get good at that.”

Do you think the identity of developers is changing over time? 

Kevlin suggests that the software identity is changing in part due to changes in the nature of developer work, the world that software developers have created for themselves, and the systems they create:

“These days, the bulk of developers are working on systems that are in some sense about connecting users to one another or to companies. That was not the case 30 years ago, when there was no world wide web. So the nature of what people have worked on has shifted. And, therefore, the skills required have shifted.”

Kevlin admits a scepticism towards the term full-stack developer. “I find the full stack to be surprisingly small when people talk about it. My background is in middleware and systems development. So my stack starts where most people‘s full stack ends.” 

From shoegazing to active sharing

The changing nature of systems over time also impacts the work of developers and the detail they apply to their work: “Historically you were dealing with end-users, but it was a smaller set — it was not the world — or you were creating a product or application that would be installed somewhere else. Feedback cycles were relatively slow, so you could end up doing shoegazing-style software development, cutting yourself off from the world.”

Kevlin calls this isolated style of work “a terrible idea. By definition, developers are people; you have to actively pursue a much more outward-looking goal. We’ve also created a world of open source. It’s collective intelligence again: building on the work of other people. Somebody else knows this better than I do, so I’m not going to write this framework, somebody else has done that. I’m going to take advantage of that knowledge.

“The first people in the world to use email were developers. It was a developer that invented the World Wide Web — it was not a committee, it was not a product management team. So developers have created a world that we’re actually experiencing right now, during the pandemic. Those most comfortable working remotely are those who were already doing software development. We’re used to sharing code remotely. So the old stereotype of the developer being secluded and introverted is not entirely accurate.  

“Even introverted people are surprisingly connected. Whenever developers argue about coding standards and guidelines, what they’re actually doing is social negotiation. Coding guidelines are a social negotiation that you’re working out how to live together. It’s the real metaphor of architecture in software: how do we create a space for people to live and work in saving software?

“It’s a diverse rainbow of humanity that you want in your team because we don’t all want to think the same. A lot of talk about teams these days seems to suggest people are super extroverted, but not everybody’s like that. But we’re also not just a bunch of shoegazers. That’s not 100% software of developers. So the identity is mature. And it turns out that software developers kind of look like human beings.”

Want to launch a developer event despite the challenges of COVID-19?

If you want to know more about how modern technologies and tools can support you for – and during – the organisation of a virtual event, don’t miss this article showcasing the best tools we used to host our online conferences since the COVID-19 outbreak.