Search This Blog

Loading...

30 November 2009

Brittle code and brittle organisations.

Brittle code
The idea of brittle code is that as compromises are made due to competence or deadlines shortcuts and workarounds gradually build up. This leaves you with code debt, which is a sort of maintenance debt.

You’ll have to deal with the cost of fixing these shortcomings one day, but because the project’s delivery date is important, or because the skills of the team are what they are, the issue can’t be dealt with perfectly today.

When you think about it – no enterprise system should go live without some tech debt. In the commercial world there should always be some compromise between time, scope and quality. That’s planned or thought through and accepted technical debt. And it should be known and it’s potential cost understood.

Brittleness is not the same a technical debt. Brittleness is the cost of change, and is a subset of technical debt. It’s a result of poor planning or lack of skill.

Brittleness is manifested in the scenario where each time you fix something, something else breaks. The programmer refrain is ‘cohesion and coupling’ which is a nice jargony way of saying you want to make the parts as independent as possible without spending too much time building them. It manifests as cost today versus cost tomorrow.

Brittle organisations
Organisations are also complex entities. Again, compromises are made to deal with today’s local issues over a holistic approach to organisational design. Projects teams deal with organisational complexity as much as, and in many similar ways to the way software teams deal with code complexity.

The CMMi model is one way to tackle this problem. There are other ways also, including implementing agile project practices. An agile implementation appears to have a ripple effect much like the scenario where you clean a patch on a dirty floor.

“Oh no, the rest of the floor looks dirty, we’ll have to clean the whole thing.”

Agile practices and CMMi are not the only ways to address these issues. Common sense and pragmatism go a long way also.

The point I am trying to get to is that you, as a project leader, need to understand these dynamics. Are you implementing a solution with hidden organisational debt? Are you aware of the longer term consequences of your decisions? Have your optimisations been local or holistic? Are you conscious of the costs and benefits of the changes you are implementing beyond your project’s stated goals?

And are you sharing that knowledge with your customers?