Communication is crucial to architecture

There is a famous anecdote about Sinan, the architect: when he was building the Selimiye Mosque, a child pointed at the minarets and claimed one of them was leaning. Sinan reacted immediately, instructing the workers to attach ropes to the minaret and pull until the child confirmed the minaret was now straight. The minaret wasn’t actually leaning, and the workers didn’t change anything by pulling. The perception of the minarets was at risk, and Sinan addressed that.

Continue reading Communication is crucial to architecture

The power of verticality in SW (and manufacturing)

I learned about cellular manufacturing when I was majoring in industrial engineering. In this post I’d like to show the game-changer nature of vertical organization by drawing some parallels between this idea and the organization of software work.

In a functionally organized plant, the shop floor is structured according to functionality: lathes are organized together, as well as mills, painting and polishing stations and various other functionalities. This brings efficiency in terms of keeping tool magazines, needed chemicals etc. together, centralizing the maintenance, optimizing utilization of the machines, sharing knowhow among the people operating the machines and so on.

Continue reading The power of verticality in SW (and manufacturing)

Poor man’s active listening: is it good or bad?

“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?

Understanding software dynamics with Lehman’s Laws

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

Semantic versioning is brilliant, but it won’t scale

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

When architecture should help

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

Conway’s Law, communication & architecture

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

No hard argument for simplicity

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