QualityDev.net

I’m at the Better Software Conference in Las Vegas this week, where one of the key focal points has been managing people and the culture of the organization rather than just the software itself.

Jeffery Payne (CEO, Citigal Inc.) discussed, in his keynote, how the ‘Measurement Crisis’ is hurting business executives as their decisions are based on measurements from all parts of the company (NPV, ROI, Marketing, etc.) but this is still lacking for software development measurements.

Payne believes this is in part due to many software engineers being mathematicians and feeling uncomfortable reporting low numbers (for justification reasons), or metrics that do not compare or correlate easily. Personally, I recall a few years ago being in a meeting where the marketing manager reported our Web site’s click-through rate was 3.1%. I thought this was an amazingly low number and wondered what would happen if I reported that the unit test coverage rate was 3.1%… I did not know that the industry average click through rate at the time was 2.7% so the number was actually very good.

This has been a familiar theme in all of the measurement/metrics sessions I’ve attended this week – read behind the numbers! Understanding the metrics reported is vital to success if you are going to use them to good effect.

This is a cultural issue, and Payne recommends that managers should start by getting teams measuring something to get them interested and comfortable with the process.
This is something we advocate strongly. Starting to measure something, even if the numbers are initially low, and tracking them to see the metrics increase for the better is not only the beginning of a better quality process, but is motivational and encourages people to extend the measurement process into other areas. For example, start by tracking unit test pass rates, and once you are comfortable with the process, move on to coverage.

Alan Shalloway, CEO of NetObjectives, discussed how ‘Sustaining the code is different from sustaining the team.’ In the midst of much discussion about tools and results, this excellent point is often missed by organizations looking to implement quality processes. Sometimes, focusing on all the tools available can blind you to the most important part of the organization – the people. Shalloway went on to explain how Lean, Agile and Scrum processes can facilitate motivation and getting the best out of the team.

The agile sessions attracted most people and the low number of attendees at some of the great metric/measurement sessions was disappointing. On the basis of the many questions asked at these sessions though, metrics seems to be an area of discovery for many organizations, so I expect these numbers to be on the increase in the future.

As the conference is in Las Vegas, there were numerous gambling-related anecdotes and quotes, the best of which included:

“The similarity between software development and poker is that they are both very expensive when done poorly.”

and

“The difference between software development and poker is that bluffing [lying] is an acceptable strategy in both.”

And my personal favorite from Payson Hall (Catalysis Group) in his keynote on risk management:

“You all know how [brittle] software is. Do you know how many lines of code there are in a Boeing 747? And yet you all chose to fly here…”

When the 107th US Open Golf Championship started last week, quality would have been at the forefront of every player’s mind. Hours of work, practicing different techniques and consulting with people who know the environment can either lead to glorious victory frustration at having a bad day by finding the numerous hurdles, both expected and unexpected, in their path – sound familiar?

Over the last few weeks I have had my first set of golf lessons in 15 years. Afterwards, I realized that many of the techniques I was learning, tweaking, trying out etc. follow the experiences I had in developing software. Over the years I had slipped into a couple of bad habits and could not realize that I was doing this as you do not watch yourself when playing. One of the issues I needed to resolve was poor posture at set up. This is a fundamental part of the whole golf swing, if you set up badly then it is very difficult to get things right! – Again, sound familiar?

This all relates to why we have code reviews and mentors (as well as training courses). These are the controls that stop the rot setting into our code and frequent tweaks and technique improvements can ensure that not only does the current code get reviewed from a quality perspective, but we learn for the next piece of code we write.

There were many areas that were comparable: preparation, environment, technique, execution and rhythm. I had to think about this last point, but having a constant release rhythm allows customers to be prepared for what is coming and, internally, sets a schedule for other people not directly involved in the day to day development – marketing, document authors, training etc.

Probably the most important thing I realized was that learning a new technique often has a negative impact on productivity before you start getting good at what you’ve learnt. This was very noticeable on the golf course, but made me think about unit testing. To start with, we learn simple tests using basic assertions and think ‘well, OK but how can I test this in my real-world, more complex situation?”. As time goes by, we learn to move onto these more complex areas of code and after a few months writing tests becomes an automatic part of the process. Thus, the quality of our work improves and, due to the many well known benefits of unit testing, so does productivity, over time.

So, like the players at the Open, the next time I am out on the golf course, I’ll be hoping that the exceptions will be few and far between, and when they do occur, they will be handled gracefully.

After our recent discussions on ‘Keeping Your Estimates Honest’ and ‘No Silver Bullets’, I decided to blow the dust off my copy of The Mythical Man-Month, (Frederick P. Brooks, JR, 20th Anniversary Ed. Addison Wesley, 1995) and reread it.

What amazes me about this book is that it is over 30 years old, and yet it is still very relevant today. Am I amazed that people haven’t learned from these well-documented problems and solutions? No. It reconfirms that software development is not an easy task, and managing these projects from estimation through conclusion is more stressful now (with greater business demands and competition) than it was 30 years ago.

The book covers many topics, but a recurring point Brooks makes is that Conceptual Integrity is central to product quality. If there is not purity of design that is applied to the whole application, this lack of integrity will cause problems down the road. Brooks discusses the art of growing software rather than building it at length, and suggests using ‘Surgical Teams’ and division of responsibilities (similar to that seen in Scrum practices today), which leads to a better-integrated team and a higher quality result.

All of this reminds me that the various manufacturing metaphors that are often applied to the software development process are unhelpful at best. While it is important to ensure consistency of behavior of the finished application, you can’t get away from the fact that the software development process is, by its nature, a creative activity and demands freedom of creative thought.

It also raises questions in my mind about the viability of outsourcing: we have several clients who outsource the development of various parts of their applications to different groups, often at different external vendors in different countries. (I wonder what impact that approach has on Conceptual Integrity.)

Another area Brooks comments on is “adding manpower to a late project makes it later” (Brooks’ Law). This is one lesson that I believe the industry has learnt over the past 30 years. Brooks’ observation “The bearing of a child takes nine months no matter how many women are assigned” is one I have heard many times in my own career.

Brooks wrote The Mythical Man-Month largely from the experience he gained when managing the IBM System 360 project back in the 1960’s. But most of the concepts of the book are still relevant today; fundamentally, this book is about managing and organizing teams to become more productive. Brooks expands on this subject in the last chapter of the 20th Anniversary Edition - The Mythical Man-Month after 20 years – and many of his conclusions are proven with references to numerous projects and studies. In my opinion this will still be staple reading for any project manager or development manager for many years to come.