Quality is Dead?
A provocation, I know. But there is actually truth in that. It’s true that software is seen by the large public as an unstable artifact, prone to unexpected behavior, difficult to fix and unreliable. This is the point of the most interesting post I found the last week Quality is Dead: The Hypothesis by James Bacha. We lowered the bar of software quality to such an extent that software users believe that grotesque user experiences and crashes are normal. Fatalism that we (software people) created. Marketing efforts are all focused to produce easily measurable metrics for the customer satisfaction like for example a convincing help line or distracting useless services. What software people can do is actually very simple: rising the bar starting from everyday development activities.
Other worth noticing this week and my opinion below:
Ward Cunningham - Debt Metaphor… Amazing how many good things can be said in less than 5 minutes. When technical debt accumulates it’s usually too late to fix it mainly because the code was not written to be easy to clean-up an debt accumulation is exponential. Especially when instead of fixing the broken design all dependencies to that part are fixed creating duplication. Ward remembers us that technical debt is about writing bad code with the idea of fixing it later, not writing good code with the understanding of the moment designing it so that can be easily changed. That is exactly what evolutionary design is about, not to be confused with technical debt.
TDD: The Art of Fearless Programming… In this article Ron Jeffries and Grigori Melnik discuss advantages of TDD adoption. The article is a basic introduction to TDD, but it publishes a couple of tables of research studies in the industry and academic about results of agile adoption. The study shows an average increment in the effort which is usually low and a substantial quality increase percentage. The article confirms that with agile adoption a low increase in the effort produces a substantial quality increase. The results aren’t extraordinary but positive, just to stress once again that there is no silver bullet.
Jay Fields: Successfully Adopting Pair Programming… Here’s another nice write-up by Jay. This article is good to remember because it clearly describe usual pair programming stories and their challenges. Is good to remember that pair programming should never be imposed. There are people who obviously aren’t interested in pairing if they never tried or if they fear their freedom is in danger. Jay suggestion to start from who is more willing to pair to first create a working team and then convince the others is great. The mentor/learner distinction is very important too especially talking of the mentor role. In my experience often the mentor doesn’t switch to teaching mode (driving the learner to the correct solution instead of dictate literally the solution). I also tried pairing sessions myself and I am very happy about the results.
BDD with Cucumber - Ben Mabey: MountainWest RubyConf 2009… This is a well crafted Cucumber presentation, with funny examples and a great selection of pictures. I already know what cucumber can do and I know is a wonderful acceptance framework. My take-aways are a concise formulation of the 5 whys rule and a clear statement that there is no fixed way to say what to use between views specs, controllers spec, models spec, Cucumber-webrat or Cucumber-Selenium. Based on the project, you can use all of the possible level of testing or just part of them.
Smalltalk to Ruby: MountainWest RubyConf 2009… Maybe this presentation is too simple as the author said at the end. It presents the Implementation Patterns book Smalltalk version by Kent Beck with a few examples from the everyday Ruby and Rails development. But it helped me out to clarify the meaning of esthetic in code. Esthetic is about visualization: symmetry for example is a visual effect. How then software relates to esthetic? Because there is a visualization aspect of code which is actually very important. It is through visualization for example that is possible to say if some code is good or bad, because of the “impression” of length of methods or the symmetry of a class where there is the same amount of code averaged in every method. The first metric we often use to judge clean code is the visual aspect. At least this is what I do. It would be interesting to analyze these visual aspects in a formal way. Mmmh.
Neal Ford DSLs RubyConf 2008… The de-facto DSL in Ruby presentation these days. Neal Ford’s talk are usually well crafted and this is no exception. I especially liked the constant factory trick to avoid double quotes on names, bubble words and instance_eval to expand contexts. Slides available here http://www.nealford.com/downloads/conferences/canonical/Neal_Ford-Advanced_DSLs_in_Ruby-slides.pdf
2 years ago