“Did you understand?” We all know that we can never trust the answer “yes” to this question, yet we fall into this trap unavoidably. Most often due to lack of time or patience.
Ideally, we should get a summary from the listener of his understanding in his own words, much like a checksum, so you are sure the message gets across. Or when we are listening, we should summarize what we just heard and aim to get an acknowledge to that. This is called active listening (or reflective listening on Wikipedia).
Yet sometimes the time is tight, we just feel lazy to execute this method, or our communication partner is not willing to prolong the conversation. In this case, I find an easy solution is to ask if it’s a good or bad thing. An example:
Continue reading Poor man’s active listening: is it good or bad?
Lehman’s Laws on software evolution demonstrate the complexity of software-intensive systems and the organization and process for developing them. I find the last law central to the whole theory: “E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.”
We can demonstrate this with a little help from system dynamics theory. System dynamics tries to breakdown the complexity into variables and looks then at their interactions, and especially loops of interactions.
Continue reading Understanding software dynamics with Lehman’s Laws
Those who don’t understand Unix are condemned to reinvent it, poorly.
— Henry Spencer
UNIX never experienced the DLL hell, with a brilliant simple trick in library naming convention. This idea was so good, that it later got also formulated more articulately as semantic versioning, and huge ecosystems such as npm are built around that.
Continue reading Semantic versioning is brilliant, but it won’t scale
A non-functional requirement (NFR) is realized by the architecture and the implementation. The balance can vary. Sometimes the architecture does the most part, e.g. by providing a real-time OS and fixed priorities for critical threads; sometimes the implementation, e.g. by following coding conventions scrupulously to ensure code maintainability. And sometimes the balance is off.
Continue reading When architecture should help
When designing an architecture, one should respect Conway’s law. Respecting it does not mean reversing the BAPO model, and deriving the architecture from the organization. Rather it means taking the organization and its adaptability into account when designing. Even if the architecture is perfectly aligned with business, but the architect doesn’t have the means to influence the process and the organization accordingly, there will be architectural drift caused by the mismatch with the organization.
And when we can, we try to define teams according to the architecture. Often with the premise of reducing the communication overhead in the organization, we try to break down the system into cohesive subsystems and corresponding, ideally two-pizza-sized teams. The math behind is explained simply in The Mythical Man-Month that the number of necessary communication channels grows quadratically in relation to the team size.
But, communication is essential in software development. Why do we want to reduce it?
Continue reading Conway’s Law, communication & architecture
For more than a year now, I’m working as a system designer, which roughly means being responsible not for a product or product line, but for a system to which different products are integrated. So I’d like to share my first reflections. Continue reading System vs. software architecture
All design is tradeoff. Any relevant system will ask for a balancing of forces while making design decisions. Therefore formulation of alternative designs and evaluation based on concrete criteria helps tremendously in laying out the tradeoff in front of the stakeholders and reaching a good decision in a transparent way.
This all works well except for simple designs. Continue reading No hard argument for simplicity
Architecture is about refining the understanding. Concepts become clearer over time, which means they are reworked, redefined as the understanding progresses. In this direction, it is beneficial to distinguish between constraints and other non-functional requirements. Continue reading NFRs and constraints
I find Eric Evans’ book on Domain-driven Design quite brilliant. It preceded the idea of microservices by ~8 years, which is alone incredible. Especially the chapter on strategic design, and the patterns explained there were very interesting to me. So I searched for a visual overview of them. When I found none, I drew this: Continue reading Domain-driven Design quick reference
For a while now I’ve been intending to add https support to the blog. Although it would have required a switch from the current hosting provider.
Now I’ve gladly realized that my hosting provider has done the switch to https for me, just at the time Google is enforcing it more vigorously. So I don’t have to bother. Many thanks HelpingHost!