Simpler code.

Don't we all wish the code we deal with could be simple?

Simple is hard.
Simple is challenging.
Simple is complex.

A short letter is much harder to write than a long one. Why do you think my blog posts are so damn wordy? I don't put in the effort to shrink them down! :)

Right - Simple. How can we get simple code?

S.O.L.I.D

OK, not really - Just S.
Single Responsibility. When something has a single responsibility, then it's likely to be pretty simple.

What is a "Single Responsibility"?

Oh, I'll wait - Feel free to try and give an wide ranging answer.

.
.
.

OK, I'm bored waiting - Does your definition work for a Module? For a class? For a method?

I don't have a definition that works for them all.

Personally, I toss out SOLID when I'm writing code. It is VASTLY important to understand. The underlying ideas to these five points are the only way to write sustainable code. But SOLID does nothing to help me when the boots hit the ground. I know it's not supposed to - it's our guiding Principles. What we strive to do, what we have lofty ideals about, but it's to abstract to help us code.

Right - sidetracked again.

Simpler code... single responsibility... MicroObjects!

I've given a number of talks around how to do single responsibility in code. That's just 3 of the 12 MicroObjects technical practices. There's 9 more to get even more simplicity into your code.

Simplicity comes from constraints. The technical practices provide constraints that force the code to evolve in specific ways - ways that produce simpler code.

The resulting code style has been dubbed "MicroObjects" because the objects are small. It is essentially an object per behavior in the system.
Each object is very easy to understand.

The cognitive load to understand any single piece, very low.

The objects interact in very simple ways. An object asks another object to do something for it.
There's two ways I look at this.
One - I don't care about the implementation details of what I'm asking to be done - because it doesn't matter.
Two - I need to understand the whole module, in which case there's a higher cognative load to understand the depth hidden behind the narrow interface.

We either don't care about the how; or all we care about is the how. There's no need for a middle ground. We either need to know the details, or we can leave them encapsulated and focus on 'our' functionality.

A lot of code requires you to somwhat understand how the other objects behave. What are valid arguments, what exceptions might it throw, what might it actually give back?
Following the microobjects style; these stop being important questions. No, they stop being important questions.
That's right - You don't care about what exceptions it might throw. It shouldn't let you have the exception. If an exception bubbles outside the module's functionality - then something catastrophic should be happening, which your code won't know how, or be able, to fix.

Metrics

The first project I did microobjects on had:

• An average file size of 10LoC.
• An average method length of 1.3 lines.
• An average method Cyclomatic complexity of 1.2

The HIGHEST cyclomatic complexity in the code was 5. These were the biggest methods as well - shockingly.
The few of these that existed were catching specific HRESULTs. They looked something like

public void Foo(){
  try{
    _something.Do();
  } catch (COMException ex){
    if(ex.HResult == SPECIFIC_VALUE){
      _otherThing.Do();
    }
  }
}

If that's the biggest method we wrote; how complex can a method be? They are all pretty simple.

Oh yes - there are a lot of methods. The simple methods interact in simple ways building up complex behavior. We don't need complex methods to have complex behaviors. Objects and methods can be simple and we can achieve the same functionality.

The simplicity that the microobject technical pracitce drive into the code cause development to go faster. This is my big claim of Feature Parity in 25% of the developer hours.

Simplicity enables Low cognative load enables speed.

MicroObjects enable speed of development.

The simplicity of the classes and methods make testing easier. This is an earlier blog post.

This is another quick post about being able the benifit the microobjects technical practices can bring into your development.