:::: MENU ::::

Complexity Smells

I propose that one of the principal things that gets projects into trouble is too much complexity.  My theory is that there are a number of “complexity smells” that if identified and addressed early on can radically improve a projects chances of success.

To explore this theory, I recently ran a workshop where we brainstormed complexity smells and possible preventative actions.

We selected and ranked to product the following list:

(1) Over engineered code/applications – 46% of votes
Do you really need all those features? Should you really be introducing this code abstraction or design pattern; or are you just speculating that it will be required in the future? Will a simpler solution work for now?
Prevention strategies
a) Do you really need that functionality / code. No really.
b) Refactor mercilessly (at all levels, functionality, architecture, classes, methods, algorithms)
c) Ensure your team has good coding standards

(2) Lack of TDD & Acceptance test automation – 26% of votes
Is your unit test coverage above 80%? Can you click one button and have all your acceptance tests run automatically? Have you considered that any change made after version 1 is released (aka, in 90% of the lifecycle of the application!) is the equivalent of someone opening a novel they have never read, changing what happens to a couple of characters, and then without re-reading the novel; hoping it all still makes sense.
Prevention strategies
(a) Set up automation in sprint 0
(b) Project manager or tech lead needs to drive automation
(c) Ensure the team has testing experience (or at least a resource to guide & educate them)
(d) Initially test automation just seems to slow down progress; be ready to explain how automated tests are the gift that keeps on giving

(3) Poor time / priority management – 20% of votes
Does your project have a clearly prioritised backlog? When new features are introduced, is it easy to see which features should be moved down the priority list. How frequent are your feedback loops – between deciding on a requirement, designing a feature and getting feedback on whether that implemented feature fulfils the requirements?
Prevention strategies
(a) Break your project up into 3 month releases
(b) Appoint a strong product backlog owner.

(4) Ownership – 5% of votes
Who owns the projects feature set? Who owns the code past release 1? Is there someone who can made decisions quickly and decisively?
Prevention strategies
(a) Customer should decide what is produced, and what acceptance tests validate that it works.
(b) Place emphasis on collaboration, knowledge sharing and transparent communication
(c) Ensure rapid feedback cycles built in
(d) Keep same team on project through who product lifecycle

Some other complexity smells identified

 

  • External dependencies – consider building “anti-corruption layers” between your application & 3rd parties. Prefer talking to humans rather than documents (re: 3rd party APIs)
  • Poor communication – collocation of team; prefer face to face rather than email conversations; keep teams < 10 ppl
  • Standards – too many or too few; standards = guidelines rather than rules

 

If your project is exhibiting some of these smells; perhaps its time to have a complexity retrospective with your team and nip them in the bud before they spiral out of control and kill your project.


So, what do you think ?