Make the Invisible More Visible

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
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.
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".
+
Software and the process of developing it can be, 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.
+
* Source code has no innate presence, no innate behaviour, 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.
-
* By itself, source code has no behaviour. The application it specifies has behaviour, but when the application runs it reveals nothing of the source code it came from. The goings on at Google are surely substantial and not in proportion to the pleasingly minimal number of pixels its home page lights up.
+
* A running application has presence and behaviour, but it reveals nothing of the source code it was built from. The number of pixels Google's home page lights up is pleasingly minimal; the goings on behind the pixels are surely substantial.
-
* Lack of visibility is often synonymous with lack of management. Everything is apparantly on track and one week later it's 6 months late! That would be impressive if it was true but of course it never is. It was 6 months late last week too but last week the invisibility field was still holding on.
+
* Lack of visible management is synonymous with lack of management. If your project is apparantly on track and one week later it's six months late you have problems, the biggest of which is probably ''not'' that it's six months late, but the invisibility force fields capable of hiding six months of lateness.
 +
 
 +
* Lack of visible progress is synonymous with lack of progress. If you're 90% done and endlessly stuck trying to debug your way through the last 10% you have problems. Fixing bugs is not making progress. If that were true we could easily introduce more opportunity for progress simply by introducing more bugs. You aren't paid to debug. Debugging is waste.
Invisibility is dangerous.
Invisibility is dangerous.
-
We manage things better when we can see them and see them changing.
+
We manage things better when we can see them and see them constantly changing.
Our thoughts are clearer when we have something concrete to tie our thinking to.
Our thoughts are clearer when we have something concrete to tie our thinking to.
-
All useful practices have a core technical purpose, but the really useful ones also make the invisible more visible. They give confidence that progress is genuine and not an illusion, deliberate and not unintentional, repeatable and not accidental.
+
You should take the time and effort to introduce more visiblity.
 +
Visibility gives 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.
+
* Writing unit tests provides evidence about how easy the code unit is to unit test. It helps to reveal the presence (or 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.
+
* Running unit tests provides evidence about the code's behaviour. It helps to reveal the presence (or absence) runtime qualities we'd like the application to exhibit; qualities such as robustness and correctness.
-
* Automated build
+
* Doing iterative development increases the visibility of development progress (or lack of it) by increasing the frequency of development progress evidence.
-
* Lean-Agile
+
* Doing incremental development increases the visibility of project progress (or lack of it) by increasing the frequency of project progress evidence.
-
 
+
-
* 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.
Faith is belief without evidence. I don't recommend faith based development. It's better to develop software with plenty of regular visible evidence.
-
---------------------------
 
- 
- 
- 
- 
-
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.
 
- 
-
* By itself, source code has no behaviour. The application it specifies has behaviour, but when the application runs it reveals nothing of the source code it came from. The goings on at Google are surely substantial and not in proportion to the pleasingly minimal number of pixels its home page lights up.
 
- 
-
* Lack of visibility is often synonymous with lack of management. Everything is apparantly on track and one week later it's 6 months late! That would be impressive if it was true but of course it never is. It was 6 months late last week too but last week the invisibility field was still holding on.
 
- 
-
Invisibility is dangerous.
 
-
We manage things better when we can see them and see them changing.
 
-
Our thoughts are clearer when we have something concrete to tie our thinking to.
 
-
All useful practices have a core technical purpose, but the really useful ones also 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.
 

Revision as of 10:59, 9 July 2009

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 can be, to paraphrase Douglas Adams, "mostly invisible".

  • Source code has no innate presence, no innate behaviour, 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.
  • A running application has presence and behaviour, but it reveals nothing of the source code it was built from. The number of pixels Google's home page lights up is pleasingly minimal; the goings on behind the pixels are surely substantial.
  • Lack of visible management is synonymous with lack of management. If your project is apparantly on track and one week later it's six months late you have problems, the biggest of which is probably not that it's six months late, but the invisibility force fields capable of hiding six months of lateness.
  • Lack of visible progress is synonymous with lack of progress. If you're 90% done and endlessly stuck trying to debug your way through the last 10% you have problems. Fixing bugs is not making progress. If that were true we could easily introduce more opportunity for progress simply by introducing more bugs. You aren't paid to debug. Debugging is waste.

Invisibility is dangerous. We manage things better when we can see them and see them constantly changing. Our thoughts are clearer when we have something concrete to tie our thinking to. You should take the time and effort to introduce more visiblity. Visibility gives 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 presence (or 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 presence (or absence) runtime qualities we'd like the application to exhibit; qualities such as robustness and correctness.
  • Doing iterative development increases the visibility of development progress (or lack of it) by increasing the frequency of development progress evidence.
  • Doing incremental development increases the visibility of project progress (or lack of it) by increasing the frequency of project progress evidence.

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