You Want IT When?

When I was a child, I had a strong aversion to pineapples.  Just the look of them made me ill.  It didn’t matter whether it was cut or uncut; there was just something about the look that made me believe I would not like the taste.  Maybe it was the color yellow, but there was something terribly unappealing about the fruit, and no matter how much my mom would entice me with declarations of how sweet it taste, I would not try it.

I felt the same way about cranberry sauce too.  It was an emotional aversion; there was nothing logical about it even though I was convinced my reasons were all logical.  Cranberry sauce looks slimy; slimy is disgusting; therefore, it must taste like it looks: disgusting.  It’s a logical inference; though, it has little relevance to how cranberry sauce actually tastes.

As I got older, I became more open to giving foods a try (and other things, of course) that were unappealing to me.  When I finally gave pineapples and cranberry sauce a try, I discovered how I’d been missing out for so long on enjoying a food that was so pleasurable to me.

Much of the software community has a similar aversion to LOC. Many of their arguments against LOC are logical, but they aren’t relevant to the science and practice of LOC as advocated by its adherents.  Sure one can write a line of code with more defects than ten lines of code, but the Law of Big Numbers says the density observed in practice will be the expected value.

(more…)

Early in my career I had the good fortune to work under a management team that valued producing high quality applications - ones that rarely, if ever, crash under continual load.   The director of the department believed, not only in words but in action, that a defect discovered in the field is significantly more costly to fix than one discovered in development.  We lived by that rule, and we all believed in it.  

For this product, we did not have a sustaining engineering team to fix and deliver patches to the field because it was simply not needed. Over the course of the seven years of working on this team through multiple product deliveries, I recall only two or three issues from the field that required an engineering fix.   Now think of all the features you could deliver by investing the money saved in a sustaining engineering team into new feature development. That’s what we did.

I’d like to describe the six practices required to produce and release stable applications.  The level of stability that you achieve in your products will correlate to the degree to which you commit to these practices.  The strategy by itself isn’t enough to achieve great results.  Great results require discipline, persistence, and a strong will, and most importantly, it requires a leader and a team that values quality above all other criteria.

(more…)

During a presentation on software metrics, I asked the audience to estimate the distance from New York, NY to Sante Fe, New Mexico in Kilometers (they were asked not to participate if they already knew the answer), and I asked them not to do any conversions in their head before giving their answer.  For those of you reading in other countries, we use miles to measure long distances in the USA, so kilometers is a unit that we don’t have much experience using.   The answers to the question were all over the place with most of them being overestimates of signification magnitude, double or more.  Then I asked the audience to estimate the distance again, but this time, they were to estimate the distance in miles - a unit they were all very familiar with.  These estimates were much better with all being less than 20% away from the actual distance.   Some were so close to the actual distance that they were essentially accurate.

(more…)

In February many of the older articles continued to have heavy readership.  I find it interesting to see how the articles of interest evolve over time.  Some of the older articles are the most popular articles for the month when not too long ago it was always the latest articles published that would have the largest readership for the month.  The top 10 articles for the month of February are as follows:

1. “Reflection Unrealistic Schedules“
2. “No Pain, No Gain“
3. “Refactoring Isn’t A Design Methodology“
4. “Danger Agile Practices at Work“
5. “Agile Isn’t a Process“
6. “An Objective Method for Navigating Your Project“
7. “Part 1: How to Manage an Unrealistic Schedule“
8. “Outsourcing Debate - Two Guys Talk it Out“
9. “Monthly Wrap-up - January“
10. “Certifications, Who Needs Them?“

The top 10 countries visiting “You Want It When?” for the month of February are as follows:

1. United States
2. Canada
3. Australia
4. Great Britain
5. Netherlands
6. Japan
7. Germany
8. China
9. Thailand
10. Hong Kong

In February the focus was on critiquing the Agile Methodologies.  I believe the Agile proponents have been correct in attacking some of the traditional software development practices.  I’m sure we share a common disdain for many of the process-for-process sake requirements of traditional practitioners. I think in many cases the engineers working in traditional shops find the practices stifling as well, but they are often powerless to change it, so everyone goes along to get along; apathy essentially sets in.   The Agile proponents need to be concerned about similar behaviors on their projects.  When dogma sets in, momentum often prevents the practices that require change from changing.   A good process is one that changes.  For process to endure in corporate settings, it must change - even Agile.

It’s interesting to read some of the articles from Agile practitioners.  They’ve invented a lot of good jargon to describe what traditional practitioners have been doing for many years.  Refactoring is one of them.  There’s little new here except that the Agile practitioners have given it a name.  Traditional practitioners have always redesigned and recoded their applications where and when appropriate, but there is one distinction between the traditional camp and the Agile camp: the Agile methodologies make refactoring inevitable, while the traditional practices attempted to avoid this with more investment in up front analysis and design.  There should be goals when deciding to refactor.  The goals that I target are to deliver faster and/or to improve the quality (less defects).  It’s always to serve the business needs, never elegance–for–elegance sake. 

In May, I will be presenting at the PSQT Conference in Las Vegas.  The topic of my presentation is “Test Driven Quality.”   If any of you happen to be attending the conference, please find a way to say hi.  I’d value the opportunity to meet some of my readers.

Please keep reading, tell your friends about “You Want it When?”, and Email me if would at “bill(at)yuwantitwhen(dot)com”  to share your thoughts, critical or positive commentary or even topics that you would like me to cover in future articles.