Behavior and structure

There are two values that each system provides: behavior and structure. Programmer's job is to make machines behave in a way that saves or produces money. If the machine violates given requirements, programmer fixes the problem. Many of them believe that it's the entirety of their job. Here comes the second value - structure. Even the word software is composed of two words: soft and ware. Ware means product and soft indicates, that it should be easy to change. Easy does not necessarily mean trivial, but the difficulty should be proportional to and only to the scope of the change. But which one of this values is more valuable? If you'll ask the business managers, they'll probably say that the correct behavior of the system is more important. Developers will often go along with this.

There's very good example as an argument why this attitude is wrong:

• If you give me a program that works perfectly, but is impossible to change, then it won't work when the requirements change, and I won't be able to make it work.
• If you give me a program that does not work but is easy to change, then I can make it work, and keep it working as requirements change.

However these are examples of two extremes, that are rarely, if ever seen in real life projects. Impossible to change does mean that cost of change exceeds its benefit.

A great analogy to the relation between behavior and architecture is the Eisenhower’s matrix.

Things that are urgent are rarely important and important ones are rarely urgent. The first type resembles behavior and the second one architecture.

Unfortunately, the business managers can't evaluate importance of architecture. It's responsibility of software developers to prioritize the importance before the urgency.