Extremely Pragmatic Software Architecture

Since the Measuring Software Architecture I have beeing digging through two systems written in not so mainstream technologies and some crazy idea occurred to me.

Do you know what is the biggest problem for a developer when one starts to develop a system? Lots of Mess (upper case on purpose). All that hundreds of hundreds interfaces with one, two or three methods. All that Abstract*, *Impl, Generic*, *Helper, *Support classes, which implement all mentioned interfaces make a developer really confused.

Are the patterns or DDD or something else the remedy for that? I am not sure.

First. You may think that applying quasi-remedies above reduces cost of introducing a newbie to the project. I disagree. A developer learns the technical meaning of the source code very quickly. Really big cost is acquiring in business domain.

However domain-agnostic developer writes poor code, but perfectly understanding how the domain works is not critical for one to understand what is technically going on in the code.

To be honest, I have met few software professionals who perfectly understand how the domain worked. Most of us knows just only enough (or little bit less) to make the feature working (at the moment).

Second. You may think that applying quasi-remedies increases code-readability what improves communication, what improves quality, what improves velocity, what improves business value. Well, this is true, but..

I observed when a project breaks all code-readability techniques and crazy naming conventions and macro-design techniques are used CONSEQUENTLY by a team, then some phenomenon happens. People align their perception to consequently used (even crazy) conventions and techniques. And then they are becoming productive developers. It takes time, but this is the fact.

So, my idea is the crucial thing for working effectively with software architecture is...keeping order inside the project, packages, folders, classes, methods and so forth. Order means: not so much code in one place, not so much dependencies between items and avoid cyclic dependencies if possible.

Do you know what I mean? No methodologies, no *Driven* approaches, no patterns maybe, just ordinary old-fashioned order.

When you focus yourself on listed approaches first, you may forget what they were invented for. Being focused on keeping order doesn't make you most modern developer, but you will know what will be going on in the project, what to do and how to keep the code simple and clear at the moment. And I think this knowledge is enough. At the moment, of course.