I have been talking about integrity management, but the word integrity actually comes from the technical condition of being whole. That is why in star trak we hear that the Enterprise’s hull integrity is failing. The ship is not complete. When a car leaves the manufacturing company, it gets stamped 100% integrity, meaning that it is complete.
So what is your code integrity?
Your code is whole if it does what it supposed to do. It doesn’t mean that the client finds it useful or that it is easy to use, but it does mean that if the developer meant for the code to do something, that it actually does it.
Probably the best way to insure code integrity is to have a set of tests that the developer can run to make sure that his code has integrity.
So how would we measure code integrity?
I think that the number of test, test density and code coverage are not sufficient. They don’t really tell us of the effectiveness of the tests, so we don’t know the level of our code integrity. I am debating this, I am not so sure.
How would you measure your code integrity?
I have been talking about team work with my team lately. It seems that a common issue that comes up, is specialization.
Everyone has a place, everyone is a piece of the machine, each piece should know what to do, and they should all work in perfect synchronization.
I know that this is the common belief, it just doesn’t feel right to me.
As I always give examples from sports teams, the team keeps on giving me the example of football (soccer) in which each player has his place.
Then I saw the amazing game between Barcelona and Real, and I noticed that what makes the former the best team in the world is that every player can do all the different jobs.
The defender Gerard Piqué run from his defense position to help the wingers then continue running to help the strikers and score a goal. Amazing.
This is what an exceptional team looks like, there is no specialization, to be the best team, everyone must know and be able to do all jobs. This will allow them to understand and learn a new point of view and be able to fill in.
A developers must be able to do other jobs to become exceptional.
I had a casual talk with a developer. He said that he would never do a QA’s job, it boring, below his honor, he would do all he can not to do it. In his company they sometimes had to do a week in QA, but he would not do it, he would just sit around and not do it. No wonder developers are becoming sloppy and allowing bugs to flow to the QA team.
To become an exceptional, you have to understand the other parts of the system, and to do that you have to do it yourself.
I think that alertness come before an event happens to you. We are alert and watching out for something to happen. We can be alert of the difficulties of riding a bike. In software development, in the coding stage, we know that the design is important so we are on alert. When we create an API we are on alert for ease of use issues.
Awareness comes after the event, there is knowledge there, after the event we know. After we tried riding the bike we know that we are safe (or if we fell down how not to ride). In development this is after we tried coding, and are now aware of the design issues (which we can fix via refactoring). Or after we tried several api’s on the computer (in our tests) and we know which one is easier.
I found that I get stuck on the alertness stage too often, I am aware of a problem and I am thinking of several solutions but I am basically before the event. When I try, I cross to awareness, I understand what I did and how to do it better.
So to gain knowledge I find that I have to try,try and try again (yes, this does entitle leaving your comfort zone). I spend too much time thinking and talking about the problems.
It is a great post, short and to the point. I talked about this in the past.
Basically, you don’t need more time to make a decision, once you have collected a reasonable amount of information, just make the decision, take a choice and do it. As Led Zeppelin sang
Yes, there are two paths you can go by, but in the long run
There’s still time to change the road you’re on.
This tip alone made me so much more effective, and even better – less anxious.
- 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