Sometimes someone I meet will have a great idea and I will say so. "Good idea, I’ll write it down". I always add “It was (Albert) Einstein who said: The opposite of forgetting is writing”
One of our shareholders asked me once – what happens to all the notes that you write down?
Well sometimes I do them and sometimes, the idea turns out to be not very hot – but hey, at least I wrote them down. I am in integrity, I said that I will write it down and I did.
But all said, I have to find a better way to handle all these stuff. Writing it down doesn’t really help, it just makes a large list of stuff to do.
Here is how I do it now (bluntly stolen from kanban):
I still write the ideas on a Post-It. But now there is a place on my desk where I can put up to 4 Post-Its. Once there are 4 Post-Its, I cannot add another one. I will have to do one of the ideas to be able to put that new Post-It down. This way I must decide either to do one of the ideas or to discard one. (I can tell the person with the idea, that we won’t be doing it now)
This way leads to action and pushes me to get things done.
I have been picky on wording lately. I know that I am picky, but words do have a profound effect on how we act.
I have talked in the past about Victim Talk vs Responsible talk, and we have fallen back to talking in Victim language.
- We must …
- What we need …
- We should …
Although these word seem positive they are what I call vibrationally negative. They don’t lead to action or to controllable actions:
When we say: “We must write a walk-though document”
What we mean: “Someone else should write it, I won’t”
When we say: “I really need to loose weight”
What we mean: “I need to, but I love eating”
When we say: “We should start working out”
What we mean: “You should, because I won’t”
Lets see what happens when we use vibrationally positive words.
- I intend to write a walk-through document
- I intend to loose weight
- I intend to start working out
These are words that lead to action, they are actions that we have control over and that we can have integrity to complete. So watch out when using vibrationally negative words, I will hear the negativity and ask “what do you, intend to do with it? “
p.s. and please stop using “We”.
For the first time in our management integrity meeting – clearing, one of Typemock’s managers said: “Nothing is Broken”. The manager moved around in his chair feeling uncomfortable, and tried searching his mind for something that is not working, but couldn’t find anything.
I think that this is a great success, and it points to the next stage of the clearing, where we clear and solve the broken bits before the meeting. There is no need to wait for the meeting to do some clearing.
So although I will mark this week and make sure that nothing was broken, I know that we are getting better at being in integrity.
I have been pondering this for quite some time now. How do we measure the code integrity. Code Coverage doesn’t really do it, and the number of test or test density also doesn’t.
I proposed to go back to the commercial essence of unit testing and bug slaying. In a team that doesn’t unit test, we have seen that 87% of the bugs found in the QA, are the result of sloppiness, a unit test would have found that bug, as the developer was aware of that case scenario, but just didn’t test it. Only 13% of the bugs found, where bugs in the design and scenarios that were not considered.
The thing is that a bug found in the QA must go back to the developers who must track it down and fix it, just to send it back to the QA (and hope that he didn’t add any other bugs). According to IEEE, this process cost $1000 per bug. While a bug found in development cost only $25-$100. That is 10-40 time less!
When checking this out, the direct benefit of coding with integrity is that the bugs don’t even reach the QA. If we could measure the bugs that are found in the development, we could know how effective our unit tests really are.
So if we measure the time it takes to fix a bug (Bug-Fix-Time) we should see that developers writing good unit tests will fix the bugs in less time then developers who don’t. We know that the industry standard is 6 days to fix a QA bug and minutes to hours to fix a failed unit test. That is a huge difference.
Lets measure the amount of unit test that failed on the developers desk/build server and the time it takes to fix them and know our BFT.
We should strive to get this down to a minimum to have a better code integrity.
Although “what if” questions might work, I have found that they support innovation more than they create innovation. What I mean by this, is that you must already have the innovative idea in mind, to ask the “what if” question. “What if, we try this new way”, we already know the new way.
“What if” is not a question that creates innovation. Asking “how can” is a question that does lead to innovation. “How can we unit test this code?”, ”In what condition, can we unit test this code”. Now we can think of ideas and start asking “what if’s”
Although “what if” is not a question that creates innovation, it is very powerful at allowing other ideas to exists. It comes down to two basic paradigms
The Either/Or Paradigm
The Either-Or paradigm is something that most of us have been brought up with, it starts with our parents: “Either you clean up your room Or you won’t be allow to watch TV”. This is not an allowing paradigm, it is a paradigm that says, you have to do it my way or the highway. Most of our training uses the Either/Or paradigm as it is a strong logical paradigm. “Either you pass the test or you won’t succeed in life…”, “Either you go to university, or you will not find a good job”
The Both/And Paradigm
The Both-And Paradigm can allow several ways to co-exist. It is possible to Both clean up your room and watch TV. It is possible to unit test this code by rewriting the production code or by using great tools. It is possible to have a great life without going to university. “what if” questions are a great way to open the opportunities and to move from an Either/Or paradigm to a Both/And one.
So ask “how can we do this” to get ideas and “what if” to allow them to co-exist.
- Product Status Peek – 2011
- Thanks Roy
- Typemock starts 2011 in a new location
- Agile Demos Smells
- I want loud disputes in our meetings
- .NET Tests
- Code Integrity
- Management for Geeks
- Time Management
- Unit Tests
- January 2011
- December 2010
- October 2010
- August 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006