Add a comment

 

Re: Modularity and testability

Thx for the hint to "Software Architecture in Practice". I checked out the first chapter: You´re right, they provide some pretty clear definitions of Module and Component. And I also like their "Architectural Structures".

However...

Even their approach stands on its head, so to speak. It starts with structural elements, not with requirements. My experience is, if you put an analysis of requirement categories first (even though that sounds theoretical to most devs ;-) it´s much easier to get devs (and managers) to jump onto the "design bandwaggon". Because suddenly they can feel why it´s so important to look beyond technological challenges like scalability or deployment. Without tying evolvability to money and making crystal clear how different software is from hardware (in the most general sense), nobody will really feel an urge to invest into design.

How to fix all of this? I´d say we need at least to be equally specific. We should not perpetuate the vagueness of terms. So if you have clear definitions for "component", "module", "service" and maybe some categories etc. don´t get tired to repeat them over and over again. And maybe map them to/contrast them with definitions of others.

And then simplification is needed. In the end "architecture" is a huge topic. No, not "architecture", because it also is just a means to an end, which is "health". Yes, we´re talking about "software health", which to me means "capability to perform as required - now and in the future". The most important part of this definition being "and in the future".

Most managers/devs focus on the "here and now" of "capability to perform as required". They bang out behavior: functionality plus quality (e.g. performance, security). They are addicted, they are seeking the next kick. It´s like working in an ER: someone gets rolled in, work on the person for an hour or three, another life saved. Great!

To fix a bug, to quickly implement some feature is so much more rewarding in several ways than doing design and think about evolvability. Nobody will pad you on the back for so quickly getting the evolvability right.

Plus, how do you do that thing with the evolvability anyway? How to do design "correctly" or at least straightforwardly? How to move systematically from requirements to classes, components, modules, services, layers and the like?

That´s nowhere taught. But we are in terrible need for a simple method for everyday work, for average programmers.

We need to work on that. We need to provide guidance. It´s a blank spot on the map of software development. OOP has not delivered on that, nor UML. Agility is oblivious of this. SOLID is not of much help. Layered architecture, Onion Architecture, Hexagonal or Clean Architecture: that´s all nice and well - but still too simple. They are leaving too many dots unconnected - and also don´t solve fundamental problems. (Which then technology providers are trying to connect, which is bad. Technology is a tool, not a value, principle, or end.)

Maybe we find some time at Software Architect 2014 to talk about this.

Re: Modularity and testability


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).