“If it works, managers think it’s pretty much done.”

Software development often focuses entirely on filling in functionality; there is no time for issues such as maintainability, architecture and performance. While it doesn’t need to be difficult, says software trainer Onno van Roosmalen, 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  a pretext 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 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 managers, customers and users think that it is pretty much done. It becomes  very difficult to argue why you have to do something extra. Developers get a clear return on that in practice, however.”

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 completely focuses on functionality. Aspects that are typically linked to architecture, such as performance, reusability, extensibility and software evolution, are very difficult to test. Just like race conditions and 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 truly come?”

In addition, the underlying theory dusts over time. He notices this well, for example, in his basic training on object-oriented analysis and design (OOAD). He comes across participants with an electrical engineering background, for example, but also people who earned   an IT degree. “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, while, really, you 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 this opportunity; his work in the field of computational physics had aroused his interest in software and computers.

Moreover, Van Roosmalen noticed that he enjoyed teaching. Before his return to the Netherlands, he had already 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 reduce his employment at the TUE  to, ultimately, fully focus on training. He still works for the Eindhoven University, which hires him for the PDEng course in Software Technology.

So, moreover, Van Roosmalen  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 manner and I think you can see things more in context. It sticks a little bit better.”

“In most object-oriented programming languages, objects of the same class can, for example, directly access 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.  They often say something like: ‘But it’s not like that in C#.’ And then again 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 that again. Most training courses are about the process and all that, and not about the technical stuff.”

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 are automatically confronted with important software properties such as information hiding and encapsulation, i.e. the idea that you localize information and not throw it through the entire system. In practice, you  regularly see that a team provides one component with extra functionality and then the entire system starts to  topple like dominoes. That makes it problematic to add something. In many web applications you see that that idea is slightly broken,” says Van Roosmalen.

And then, thinking about hiding information goes hand in hand with the means by which components communicate with each other: the interface or API. “ It enables you to hide the detailed shape of your objects and ensure that no implementation details leak out. You  thus take care that the client code 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 safely use the new version without being afraid that something will fall over in the process. When encapsulation and interfaces are in order, a maintainable, scalable architecture is created almost automatically that can grow with the application.

This requires, however, that teams adopt a defensive stance when designing their interfaces. “You shouldn’t just offer everything that other teams demand. The more you offer, the more unintended usages 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. After that,  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 such tests are made in no time.

Box of tricks

Developers don’t have to reinvent 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  structure those layers, you use  various 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 concurrent tasks  subjected to timing requirements. Nowadays, most modern programming languages allow you to program concurrency , and that gives rise to very  special problems such as race conditions and deadlocks.

Here, too, things  already go wrong in the basics, notes Van Roosmalen: “A lot of people who have real-time problems use an operating system like Microsoft Windows. Well, that’s not a real-time operating system. It does contain a lot of things  like real-time priorities and so on. But many 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  do not deliver standardized models. That is not what  tool vendors want  at all anyway, because they might lose business. They play on vendor lock-in.”

But with SysML you can  yet integrate these models with each other and make an overarching model of your system. The OMG, the standardization group behind SysML, has tried to combine these modeling techniques in such a way that the whole  covers everything and at the same time  Is methodologically sound. “That worked out pretty well, but  it makes the modeling languages awfully big.”

As far as Van Roosmalen is concerned, software developers should likewise 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.

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

But that again is a symptom of the fact that quality in software is hard to see and only makes itself felt in the long run, whereas that’s naturally different  with systems engineering. “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. It states very sensible things about that, however you have to practice what is preached there.”

This article is written by Pieter Edelman, tech editor of Bits&Chips.