Saturday, January 07, 2006

Values in Design: Reduce Complexity

Why is software development so difficult? 

Why does software tend to become complex?  Seemingly clever humans revel in complexity.

How do you reduce complexity?

You need to measure the complexity and then make appropriate changes that will reduce the complexity.
Then you measure again to verify the results.

 Do we need measurements that are seemingly artificial and contrived?

Yes we need all the metrics we can get as long as we understand the meaning and application of the metric. Most software developed today has requirements to solve problems created by humans. The problems are already artificial and contrived. The problem space does not contain a set of coherent natural forces. Some developers are lucky enough to be working with a problem space that is to some extent more natural.

What do I mean by natural? 

Natural problems come from nature and where around before humans appeared on the scene. A natural problem space is a lot more testable than a human-made problem. It is simpler if mathematical models exist that can be simulated or used to measure outcomes. It is more complex if we need to discover those mathematical models. Not all aspects of software development have a neat underlying mathematical model. Thus we need to come up with mathematics and metrics to help measure the impact of various forces. We need to reduce complexity and so improve the design.

Measure, refine, refactor and verify.

Thursday, January 05, 2006

Values in Design: Flexible Service not Flexible Interface

What values are important to you when designing a Service and an Interface? 

A lot has been written about the design of services. I would like to touch on why you design an interface and the values that I feel is important.

What am I talking about when I refer to an interface?

I am referring mostly to an interface that may be exposed by a service. I will use a web-service as an example.
When you design a web-service you are trying to produce an artefact that someone else will be using to communicate with the specific service. Chances are, the interface specification or WSDL will be all they have to describe the service.
This leads to the requirement that the interface specification be as simple and unambiguous as possible.

Why simple? 

We should be striving for simplicity in everything we do. Einstein said: Everything should be made as simple as possible, but not simpler.

Why unambiguous? 

Ambiguity is not required in an environment where people like to assume. Ambiguity is worse than complexity because complexity can be reverse-engineered.

So, where are the problems?

Consider that we want to communicate a model to someone who will be interacting with the model and providing it with content. We use a meta-model to do the communication. The WSDL specification is the meta-model. A WSDL file describing our interface is the model. The actual SOAP messages is the content.
Why then do so many interface try to describe a meta-model and not a model? This would not be too bad if it had some mechanism for discovery or the model. The problem lies in the fact that you need to understand the meta-model and model in order to interact with the interface. If the meta-model used is a standard specification you have removed a lot of ambiguity. If you build your own meta-model you have to provide a lot of extra information so that the consumer can understand your meta-model and then model.
The reason so many interfaces try to describe a meta-model is because the designer believes the interface needs to be flexible and may be expensive to change. It may be true that flexibility is required. However it will have to be flexibility that is required by the end-user of the system and will become a core asset of the system. The consumer of the service will have to be design so that it can adapt to the changes in model that is possible through this kind of flexibility. The flexibility argument does apply if you can envision the need but are only going build a specific case.

A flexible interface is a misnomer. 

It leads to ambiguity and the perceived simplicity is only a lie. The actual model still have to be communicated and understood unless the consumer is designed to extract the model and be flexible according to the model. This second option is not a flexible interface but a flexible service.
This potential impedance mismatch between an interface and the actual model is a challenge we face daily.
We will be rewarded if we get the design right!