Lazy Initialization

I have read a great many things questioning the value of the measurement of test coverage.  I believe that there is a common misconception about test coverage and what our coverage numbers can tell us about our code.

The common criticisms are that while the coverage report can tell us how much of the code has been exercised it does not tell us how well.  This is absolutely true.  High coverage numbers are no substitute for reading the code (and the tests) and understanding what it supposed to do.  What the coverage numbers can give us is a measure of testability.

If you need to make changes to a piece of code that has very high test coverage you can plan that work with the confidence that the code is designed in a way that will not make it incredibly difficult to change.  This typically means that it adheres good design principles like Single Responsibility and Inversion of Control.  Furthermore it means you will have some tests to look at along with the code you are trying to understand before you change it.  Even if the quality of those tests is not enough to give you the confidence you need to change the code, you will already have the starting point you need to add better tests.  It’s much easier to change incomplete tests into good tests than it is to change no tests into good tests.

Perhaps instead of test coverage we should call it testability coverage.

Jason Yip - % test coverage doesn’t provide useful information

Patrick Kua has a post about a topic I’ve thought about a lot recently: the power of a true team vs. a loosely organized group of people working together.  I believe he is spot on about there being significant benefits to building a tightly integrated team.  He even offers some suggestions for how you can form such teams in your own organiation.

There is a simple test that I often use to gauge how well the teams that I am a part of are composed.  During your daily stand-up or scrum (or better yet scrum of scrums) take the time to very careful go around the room and look at the face of each individual.  What do you see?  Are the team members engaged and interested?  Do they ask focused and pertinent questions?  If so, it’s a good bet that you have a team that is well invested in accomplishing the team’s common goals.  On the other hand if the majority of people look distant, bored, and anxious for the stand-up to end, it’s likely that you have a group of individuals that are more focused on their individual priorities.

Give it a shot at your next stand-up.

Patrick Kua - What do you have more of?

Sometime is the last year I had a conversation with a colleague who was not yet convinced about the value of agile development processes.  This particular individual was a good engineer who had made it his practice to write top quality code when provided with a detailed specification.  He just couldn’t imagine that we could write good software without such a specification.  As is often the case when talking about software we eventually worked our way around to a construction analogy when he asked if I could imagine building a bridge with less than a detailed spec.  I responded at the time that the analogy doesn’t really hold up.  In software we have the option to build a less than complete product and test it’s acceptability as we progress toward completeness.  This is mostly made possible by the fact that the most expensive resources in software engineering are time and knowledge.  Spending those resources to develop a product that is not yet complete but is usable enough to evaluate our approach is not likely to be a big risk.  In real world construction the cost of real materials as well as the safety risks force us to do everything we can to build the bridge completely and correctly the first time.

Paulo Caroli at Agile Tips does my response one better though and turns the analogy around showing just how bridges can be and likely actually are built using agile processes.  He also throws in a few bridges that failed to get built with more traditional processes.

Agile Tips - Agile Bridge Analogy

My name is Bradley Harris.  My passion is creating great software.

I value:

• Honesty
• Courage
• Quality and Consistency
• Teamwork and Trust
• Continuous Improvement
• Shared Ownership
• Clean and Simple Code
• Fun

Early in my career I learned that not all software developers hold the same values.  Later I came to the realization that not even all good developers have the same values.  Finally some time later it finally dawned on me that a complete match of values is not even necessary for a team to succeed.

For a team to create great software together what is important is that they all understand each others values.  From that basic understanding of values a team can work together, grow, and learn how their differing values complement each other.  Over time many team members may even find that their personal values have evolved through this interaction.

Now that I’ve got my colors run up the mast lets talk about great software and how it is created…

• Ben Rady - Statement of Values
• A Day In The Lyf - Coding Values