Make the Invisible More Visible

From WikiContent

Revision as of 18:40, 7 July 2009 by JonJagger (Talk | contribs)
Jump to: navigation, search

Many aspects of invisibility are rightly lauded as software principles to uphold. Our terminology is rich in invisibility metaphors; mechanism transparency and information hiding to name but two. Software and the process of developing it is, to paraphrase Douglas Adams, "mostly invisible".

  • Source code has no innate presence and doesn't obey the laws of physics. It's visible when loaded into an editor, but close the editor and it's gone. Think about it too long and like the tree falling down with no one to hear it you start to wonder if it exists at all.
  • Lack of visibility is often synonymous with lack of management. Everything is apparantly on track and then one week later it's 6 months late! That's impressive when you think about it. Of course it was 6 months late last week too, but the granularity of invisibility kept the secret supressed.
  • By itself, source code has no behaviour. The application it specifies has behaviour when it runs, but former reveals very little of the later. The goings on at Google are surely substantial but probably not in proportion to the pleasingly minimal number of pixels its home page lights up.

Invisibility is dangerous. We find it easier to manage things when we can see them and see them changing. We generally think better when we have something concrete to hang our thoughts on. All useful practices have a core technical purpose, but the really useful ones also help to make the invisible more visible. They give confidence that progress is genuine and not an illusion, deliberate and not unintentional, repeatable and not accidental.

  • Writing unit tests provides evidence about how easy the code unit is to unit test. It helps to reveal the absence of developmental qualities we'd like the code to exhibit; qualities such as low coupling and high cohesion.
  • Running unit tests provides evidence about the code's behaviour. It helps to reveal the absence of runtime qualities we'd like the application to exhibit; qualities such as robustness and correctness.
  • Automated build
  • Lean-Agile
  • Iterative-Incremental

Faith is belief without evidence. I don't recommend faith based development. It's better to develop software with plenty of regular visible evidence.

By Jon Jagger

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools