Master the art of software engineering

With the growing reliance on software in an increasingly high-tech world, it’s more important than ever to master the art of software engineering as software architects. Trainers Robert Deckers and Bart Vanderbeke have taken it upon themselves to turn developers into craftsmen.

“A colleague once told me about one of his former project managers, who, upon realizing that the estimates didn’t align with his timeline, just cut them in half to make them fit. I find it unheard of, not only that you’d do such a thing as a project manager but also that people stand for that kind of behavior. You don’t have to scold him, but you can open your mouth. Instead, at the end of the project, when everything has gone haywire, everyone complains about how this has happened to them.”

Inspired by Google executive Fred Kofman and his book “Conscious business,” Bart Vanderbeke calls on software architects to stop playing the victim. “It’s unacceptable and unhealthy,” he claims. “You’re the craftsman. When someone tells you that you need to do something in half the time, or skip the design, or refrain from reviews, you say no – constructively. Software architects are scarce, so you’re in a comfortable position, certainly no position to self-victimize. Don’t hide behind ‘management.’ As a software craftsman, using a term coined by Kofman, you’re ‘unconditionally responsible’ for everything you do or don’t do.”

“You need to take unconditional responsibility, which literally means that you need to have the ability to respond – in a meaningful way,” says Bart Vanderbeke. Credit: Bart Vanderbeke

At NXP in Leuven, Vanderbeke leads a team of fifteen software architects, working on 2.4 GHz radio applications for personal health – think hearing aids, headphones and earplugs. “Tiny systems containing tiny software stacks,” he notes. “But even if you have a codebase of 100k or 200k, like us, software craftsmanship is of paramount importance. Building the hardware takes about a year, followed by maybe five years of software enhancement. I’ve developed a series of lectures to help my colleagues bring out their inner craftsman.”

The non-functional

A kindred spirit, Robert Deckers, too, aims to increase software craftsmanship, but with a focus on software architecture – “the most difficult trick of the trade,” as he calls it. “It already starts with the question: what is software architecture? You can find hundreds of books that try to give an answer. While some are bad, terrible even, most of them are meaningful, but they all tell a different story.” This was one of two triggers that led him to dive into the subject, develop his own view, write his own book and bestow his insights upon others.

The second trigger was the realization that in traditional methodologies, there’s too much focus on the functional requirements, whereas the non-functionals are the hardest to get to grips with and therefore take up the most time. “Way back when I was an OOTI trainee at Eindhoven University of Technology, I was the software architect for a copier,” reminisces Deckers. “After two months of design, the anomalous system behavior started to rear its ugly head and I realized that we had to do error handling as well – while obvious to someone with 20 years of experience, it hadn’t crossed my newbie mind. When we were finished, to my big surprise, no less than 85 percent of all our code turned out to be for error handling, so only 15 percent of our efforts had been focused on the functionality. That’s when I first experienced that the real challenge, the real complexity, is in the non-functional.”

After the OOTI traineeship – the PDEng Software Technology, as it’s known today – Deckers sharpened his views at several companies, including Philips Research and Sogeti. Since 2013, he’s running Atom Free IT, coaching organizations and their architects, helping them create architectures, set up the architecture process and embed it. The last five years, he’s combining this with a PhD project at the Vrije Universiteit Amsterdam, researching the cognitive aspects of systems engineering.

Come prepared

Vanderbeke and Deckers are the newest additions to the software and systems portfolio of High Tech Institute. Both want to help software architects be better at their work – become real craftsmen. “As a software craftsman, you know how to organize your work and you have the assertiveness not to accept compromises on the way of working. Instead, you go for the optimum, taking into account the influencing variables and conditions. You don’t do things because someone tells you to, but as you understand the need, you autonomously decide to do so,” summarizes Vanderbeke the values he intends to convey in his workshops.

Robert Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes.

Learning to say no in a constructive way is a key topic in Vanderbeke’s teachings. “That requires you to come prepared. When you’re asked to plot a course in a project, you need to have a couple of options readily available, not down to the minute detail but to such an extent that you can weigh them and make an informed choice. When someone steps up to you and says something can be done in half the time you estimated and you don’t have your facts straight, he may well be right – you have no way of telling. If you know what you’re talking about, that will not happen. You can have a constructive conversation and you might be challenged, persuaded even, but you won’t let yourself be blown away by unsubstantiated claims. Someone once asked me if we could speed things up by taking shortcuts, upon which I replied: ‘The only shortcut you can take is skimp on the specs’ – and that was the end of the discussion.”

“You need to take unconditional responsibility, which means that you need to have the ability to respond – in a meaningful way,” continues Vanderbeke. “In my workshops, I use several small examples, taken from my everyday work, to get my point across. For instance, someone escaping responsibility would say: ‘I cut my estimation in half because my project manager told me to,’ as opposed to someone keeping ownership, a ‘player’ in Fred Kofman’s terms, who would say: ‘I wanted to avoid a fight with my project manager, so I gave in.’ Likewise, a victim would say: ‘I make estimations because our process demands it,’ whereas a player would say: ‘I want to stay with the company, so I use the established process.’ By making them aware of these little things, people are more inclined to correct their behavior.”

A good architecture is correct, consistent and communicated. Credit: Robert Deckers

Fish nor fowl

In his training courses, Deckers relays his ideas about good architectures. “The role of architecture is to offer a solution approach for the key system properties that are the hardest to realize. As a system architect, you always have to make sure you’re working towards a solution, providing guidance and serving your stakeholders’ needs, while also keeping an eye out for things that could go wrong if not addressed in the architecture. If you’re not doing this, you’re probably not architecting. Also, I want software architects to understand that an architecture needs to offer business value and that it’s feasible to build the system within the organization at hand. You can only be an effective architect when you’re prepared to step out of your technology comfort zone.”

According to Deckers, a good architecture is correct, consistent and communicated. “A system has to be correct in that it has to adhere to the stakeholder concerns and the technical environment. The development process has to be consistent. At Philips in Bruges, I once witnessed a software architect testing all preconditions of all the functions he programmed because he wanted his code to be robust. Meanwhile, in the cubicle right next to his, a colleague was using pointers without testing anything because he wanted his code to be fast. Combined in one system, that gives you neither fish nor fowl. You need to be clear on the key properties – my advice: hang the top five on the wall. Finally, an architecture should be described in such a way that you can discuss it with the different stakeholders, which means using different views for different aspects.”

Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes. He acknowledges that this seems to be at odds with the popular Agile principle of delivering working software as quickly as possible. “People often ask me: how do you match Agile and architecture? My answer to them: you don’t. They’re two different mindsets. Architecture is about looking before you leap, whereas with Agile, you just go and adjust based on the feedback you get. That’s perfectly fine for some businesses, but not for a copier or a medical scanner, where aspects like reliability and safety are known beforehand. The closest way to match Agile and architecture is to bend the rules and dedicate the first few sprints to the key concerns.”

Descending down the management funnel, the focus narrows and the risk for conflict grows.

Better decisions

With collaboration, there’s bound to be friction. A software craftsman, therefore, also needs tools for conflict resolution. In his workshops, Vanderbeke presents a management funnel doubling as an inverse conflict pyramid. It goes from wide to narrow in three levels: strategic, tactical and operational – from the what to the how. Descending down the funnel, the focus narrows and the risk for conflict grows. When a conflict actually arises, going back up the funnel to try and find a shared goal or principle helps to smooth things over.

“Software architects who are in disagreement about the way to tackle a problem often are at the bottom, stuck in their own solution. Taking them up and discussing the problem criteria usually ends the stalemate as they establish common ground,” illustrates Vanderbeke. “It’s a very useful instrument in process management as well. When you’re in a meeting that’s going nowhere, revisit the reasons why it was set up in the first place and a way out will present itself almost automatically.”

Stocked toolbox in hand, software engineers are well equipped for craftsmanship. With Deckers, Vanderbeke concludes: “It would be great to see them make better decisions. To see them operate more autonomously. And, at the same time, to see them have more fun in what they do.”

This article is written by Nieke Roos, tech editor of Bits&Chips.