Software development often focuses entirely on filling in functionality; there is no time for issues such as maintainability, architecture and performance. According to software trainer Onno van Roosmalen, it doesn’t have to be difficult, but there are misunderstandings about Agile, architecture, UML, object-oriented programming and test-driven development.

Modeling? We don’t do that. Design-patterns? Let’s skip it. Because we work agile. Onno van Roosmalen hears it regularly: Agile as an excuse, or even an excuse not to take software architecture seriously. As a trainer in the field of software development, he sees that there are many misunderstandings around the issues related to non-functional requirements: architecture, interfaces, performance, modeling, maintainability, you name it.

Misunderstandings that can be easily explained, by the way, because they have to do with the elusive concept of ‘software quality’. “Quality is not visible to many people,” says Van Roosmalen. “If it works, then it works and then managers, clients and users think that it is ready. Then it becomes difficult to reason why you have to do something extra. But developers get that back very clearly in practice.”

Many of these misunderstandings about software quality also live among the developers themselves. Popular software techniques, like test-driven development, do not contribute to this, he thinks: “Test-driven development is all about functionality. Aspects that are typically linked to architecture, such as performance, reusability, extensibility and software evolution, are very difficult to test. Just like deadlocks.”

“There is also the idea that architecture is something abstract that has to be thought up in advance, which then forces the direction of the project into a straitjacket – a big bang architecture that has to be right the first time. But you can’t do that; often you don’t know what’s coming next,” explains Van Roosmalen. “Of course, it’s good to have an idea of how you want to arrange it. But you sometimes see that projects are already preparing themselves for certain additions. Then I often think: Yes, and will they come?”

'You really can make remarkably better software if you apply the guidelines properly.'

In addition, the underlying theory becomes dusty over time. He notices this well, for example, in his basic training on object-oriented analysis & design (OOAD). Course participants with an electrical engineering background, for example, but also with an IT degree in their pocket. “Yet, you see that many of them dissect problems procedurally instead of object-oriented,” says Van Roosmalen. “That’s what creeps in when people make software under pressure, but at the same time, you really can make remarkably better software if you apply the guidelines properly.”

‘It’s not like that In C#’

Van Roosmalen himself has an entirely different background: he studied physics in Nijmegen and obtained his PhD at the Kernfysische Versneller Instituut in Groningen. He then made the jump to America for a postdoc position at the California Institute of Technology.

The turning point came in 1987. Van Roosmalen and his wife actually wanted to return to the Netherlands, but jobs in physics were not up for grabs. When a position in technical computer science became available at Eindhoven University of Technology, Van Roosmalen decided to take advantage of it; his work in the field of computational physics had aroused his interest in software and computers.

Van Roosmalen also noticed that he enjoyed teaching. Before his return to the Netherlands, he had been teaching at Yale for three years, and when object-oriented techniques emerged in the early nineties, he started training for companies. After the turn of the millennium, he decided to drop his appointment at the TUE and to fully focus on training. He still works for the Eindhoven University, which hires him for the PDEng course in Software Technology.

'The longer developers have spent behind the keyboard, the more receptive they generally become to advanced software engineering concepts.'

But Van Roosmalen also provides training for developers who have been employed by a company for a couple of years. A big difference with starters, he notices: the longer developers have spent behind the keyboard, the more receptive they generally become to advanced software engineering concepts. “You start looking at things in a different way and I think you can see them a bit more in a row. It sticks a little bit better.”

In the most object-oriented programming languages, objects of the same class, for example, can simply match each other’s private attributes. “People often don’t know that at all. Then they give it a try, and it turns out to be true. And then they often say something like: ‘But it’s not like that in C#.’ And then it turns out to be exactly the same there,” Van Roosmalen gives as an example. “It seems elementary, but there are important ideas behind it, and most developers like to talk about it again. Most training courses are about the process and all that, and not about the technique.”

Defensive

”It is precisely this knowledge of object orientation that forms the basis for much of the architecture in a typical application. This means that you automatically have to deal with important software properties such as information hiding and encapsulation, i.e. the idea that you localize information and not throw the entire system through. In practice, you often see that a team provides a component with extra functionality and then the entire system starts to fall like dominoes. That makes it problematic to add something. In many web applications you see that that idea is slightly broken,” says Van Roosmalen.

Thinking about hiding information goes hand in hand with the way components appeal to each other: the interface or api. “This allows you to hide the detailed shape of your objects and ensure that no implementation details leak out. You then make sure that the user can only do what is currently requested, no more and no less,” explains Van Roosmalen.

The idea behind this is that the evolution of components can be decoupled in this way. If a new version of a component continues to do what it used to do via an interface, the software built on it does not have to be modified immediately. A development team that programs against the component can quietly use the new version without being afraid that something will fall over in the meantime. When encapsulation and interfaces are in order, a maintainable, scalable architecture is created almost automatically that can grow with the application.

'The more you offer, the more unintended uses there are.'

The condition, however, is that teams adopt a defensive stance when designing their interfaces. “You shouldn’t just offer everything that other teams require. The more you offer, the more unintended uses there are. This increases the chance that things will fall over with a new version. You can always expand an interface later on, but downsizing is a lot more difficult,” says Van Roosmalen.

“I have a very nice workshop for that, which I do with the TUE trainees. Several teams are given the task of developing a component with an interface, and then they have to make a functional extension to it – unexpectedly of course; I keep that secret. Then they have to try to make test cases for each other’s components that work against the first variant, but no longer against the second. These are real eye-openers, because often this is how the test case is made.”

Box of tricks

Developers don’t have to invent the wheel every time. For many problems, best practices have been established over the years, in the form of patterns. “For example, you can lay out your architecture in layers: that’s an architecture pattern. To arrange the layers yourself, you use all kinds of design-patterns.”

Van Roosmalen provides a training course entirely dedicated to this subject: Design patterns and emergent architecture. That’s very broad of course, but the idea behind it is mainly to show that you have that box of tricks. “Actually, that’s one of my favorite training courses, because you really talk about software design and because you can use it to tackle all kinds of practical problems. There are also very different technical aspects involved, such as state machines with possible deadlocks.”

Van Roosmalen, together with a former TUE colleague, also provides a follow-up course on a different architecture theme: real-time behavior. Typically, you’re talking about problems with systems that have to perform several time-consuming tasks at the same time. Nowadays, most modern programming languages allow you to program competitor systems, and that gives rise to very specific problems such as race conditions and deadlocks.

Here, too, things often go wrong in the basics, notes Van Roosmalen: “A lot of people who have real-time problems when using an operating system like Microsoft Windows. Well, that’s not a real-time operating system. It does contain a lot of things as a real-time priority and so on. But a lot of other things are missing that are also necessary for real-time behavior. Then you have to stand on your head a bit to get it right.”

In real-time systems, for example, you have the problem of priority inversion, where a low-priority task claims a resource so that higher-priority tasks cannot make use of it. There are mechanisms to keep this to a minimum, and they must be in the operating system.

Vendor lock-in

Van Roosmalen also provides a basic training around Sysml, a variant of UML for systems engineering. System engineers model a lot, yet Sysml is only used sparsely in practice. There’s a reason for this: “A lot of commercially available tools, such as Matlab and Simulink, are used for systems engineering. These are not standardized models. Nor do tool suppliers want that at all, because then they might lose business. They play on vendor lock-in.”

But with Sysml you can still integrate these models with each other and make an overarching model of your system. The OMG, the standardization group behind Sysml, has tried to set up these modeling techniques in such a way that they cover everything and at the same time and fit together methodologically. “That worked out pretty well, but that makes those modeling languages awfully big.”

As far as Van Roosmalen is concerned, software developers should also take modeling a bit more seriously. During his courses, he relies heavily on UML himself – partly because a training course is too short to go into extensive programming, although programs are provided as proof of concept. But also, because it offers good starting points to reason about the class structure and to think about the architecture.

“For UML, most software developers have seen it once, but the threshold to really get started with it is quite high. Making a good model really does require an investment before it pays for itself,” Van Roosmalen agrees. In addition, software developers also lack a bit of the discipline that system developers do have, he observes.

'The Agile Manifesto simply states that you need to pay attention to software quality.'

But that’s another symptom of the fact that quality in software is hard to see and only makes itself felt in the long run, whereas that’s not the case with systems engineering, of course. “For programmers it is therefore important to put quality on the map. And contrary to what is sometimes thought, Agile can help with that,” says Van Roosmalen: “The Agile Manifesto simply states that you need to pay attention to software quality. There are very sensible things about that, but you have to hold on to that doctrine.”