Modifiability

From Martin Fowler - post on Modifiability: Or is there Design in Agility?

David Farley mentions designing a Model, and maintaining Models. I like that. Even though I had never seen him, or heard the name before, I found myself agreeing with him the most.
My thoughts after watching it.

Modifiability
I think a Framework is key here. It establishes the Model, the principles, the architecture. It creates the mindset, the foundation of Patterns.

Agile Methodologies must include design. There is always design. That does not mean all upfront. That does not mean complex documents or maintaining documents throughout. It just means decisions are made, perhaps on the fly, perhaps in a brain storming session and so on.
It is the 'Mindset' and unified approach that is important.

Better/easier/quicker modifiable systems have common themes and structure, it is COMMON, UNIFIED, PATTERNED and PREDICTABLE.

KEY IDEAS for a improving modifiability in an Application

1. You must abstract various ideas. The most important "idea abstractions" are
    a) Separate Storage from Domain Data
    b) Separate Presentation from Domain Data
    c) Separate Infrastructure from the Domain
    d) Separate the CENTRAL Domain Problem from related Domain Models
2. Use Low Coupling Design Patterns
3. Use Framework principles to implement Concrete Ideas.
4. Instil an agile "mindset", training developers to be better at pre-empting change

Lifecycle Issues


Design

One aspect that really comes to mind in the design phases, is compromise. I think design compromise is an anti-patterm that leads to agility and modifiability issues. Too many cooks spoil the broth. Too many designers, mix and match, cant agree, so we do it this way then compromise it that way. Stop. There must be a lead, a design dictator. One who will take the fall if its wrong. I have seen far too many development teams compromise themselves to a worse design. There are many different ways of doing things, nothing is truly bad for every scenario, or good in every scenario. But what is bad, is a conflict of mindset, a conflict of patterns, a conflict of foundations.

Development

Keeping Secrets, Encapsulation is very important. Teaching developers pre-empting, code for change mindset.

Tests

I find that building unitTests definitely helps with change. It makes it much easier (but only if design principles where in place to begin with). Unit Tests do not make the process of change easier, it helps in spotting errors when changing. However Unit Tests add a lot of time onto a project, so it must be done in a proper way. Full code coverage is not neccesary if the correct areas are tested.

Databases

I tend to build databases much later than you would expect. I think databases should be designed JIT (Just in Time).
A database can force a very strict design on object models and agility, reuse can be compromised. It is a very restrictive and rigid.
Let your database form from the code, not the other way around. I understand existing systems, and integration issues which makes database design much more important - but ultimately if you are started a new system, you have no excuse.


Gotta go. might add something to this later.