act:ualise | technology

BoingBoing just posted about an analysis of the breathalyzer system written by AlcoTest where the following *stunning* failures were revealed in a report assessing the fitness of the code for a court case:

• Readings are Not Averaged Correctly: When the software takes a series of readings, it first averages the first two readings. Then, it averages the third reading with theaverage just computed. Then the fourth reading is averaged with the new average, and so on. There is no comment or note detailing a reason for this calculation, which would cause the first reading to have more weight than successive readings. Nonetheless, the comments say that the values should be averaged, and they are not.
• Catastrophic Error Detection Is Disabled: An interrupt that detects that the microprocessor is trying to execute an illegal instruction is disabled, meaning that the Alcotest software could appear to run correctly while executing wild branches or invalid code for a period of time. Other interrupts ignored are the Computer Operating Property (a watchdog timer), and the Software Interrupt.
• Code Does Not Detect Data Variations.
• Error Detection Logic: The software design detects measurement errors, but ignores these errors unless they occur a consecutive total number of times. For example, in the airflow measuring logic, if a flow measurement is above the prescribed maximum value, it is called an error, but this error must occur 32 consecutive times for the error to be handled and displayed. This means that the error could occur 31 times, then appear within range once, then appear 31 times, etc., and never be reported. The software uses different criteria values (e.g. 10 instead of 32) for the measurements of the various Alcotest components, but the error detection logic is the same as described.
• Defects In Three Out Of Five Lines Of Code: A universal tool in the open-source community, called Lint, was used to analyze the source code written in C. This program uncovers a range of problems from minor to serious problems that can halt or cripple the program operation. This Lint program has been used for many years. It uncovered that there are 3 error lines for every 5 lines of source code in C.

Reading the full report is a damning indictment on a piece of software which has failings in so many ways, it’s hard to believe it even actually got to production. As BoingBoing pointed out the software companies who develop these kinds of systems  (voting machines & breathalyzers) cry foul of ‘trade secrets’ at the mention of a review of the source.  This tactic is to software what Monsanto flexes in genetic engineering (interesting that open-source GM has been mooted).

This rare insight reminded me again why Agile methods, openness and transparency and holding oneself and one another to a high standard of quality are central to knowing you are delivering software which is fit for purpose (at the very least), and which ideally is well made, thoroughly tested and makes both the customer and the developers happy.

A fun post by our friend Ivanka who recently joined Canonical to head up the User Experience side, a role which will no doubt prove challenging but has huge potential. Those who’ve already used Ubuntu, myself included, have something of a love/hate relationship with it; likely this is because we hardcore techies are no longer their target market.

In the spirit of eating dogfood Ivanka steeled herself and installed it as her mother’s primary OS FTW!

Spring has sprung and with that hails the first Vancouver Groovy and Grails meet of the year.

Time:

Monday 30th March, 18:00

Place:

WorkSpace @ 21 Water Street in Gastown, #400

Topics under the spotlight this time round are twofold:

• EasyB: BDD For Groovy & Grails (Jerome Pimmel)

EasyB leverages the Groovy language with a simple readable DSL for writing BDD style tests. But why BDD over TDD? Come and find out…

• Grails 1.1 Testing Lightning Talk (Geoff Webb)

Compared to 1.0.X versions (and compared to many languages too), Grails beds in an impressive amount of testing support to aid TDD . Testing integration pieces like controllers, taglibs or domain classes is now faster and less cumbersome; importantly they no longer require a Spring container and can often be run as simpler unit tests.

Hopefully this can be made into a more regular event with a variety of speakers who are interested in discussing other Groovy and Grails problem-solving-fu. If you have a topic you would like to share at a future event, please feel free to get in touch.

If you like statistics and Grails you will be pleased to know that Grails is trending higher in searches than Spring Framework since mid-2008.

Check out this Google Trends graph. (thanks @schmichri)

Eric Ries, formerly the co-founder CTO of  IMVU, is running a special Agile Vancouver workshop on the Lean Startup which he promises will involve more than just the usual slideshow and Q & A.

Whats makes Eric and the IMVU story so interesting (certainly to me) is that they are unique in having developed their business and taken some highly recognisable Agile practices and pushed those to new extremes, the like of which most would dare not emulate. They have courted many a raised eyebrow given their strategy of deploying every nine minutes, they aren’t afraid to throw away working code, the minimum viable product is a concept which companies could do well to observe and they’re even so brazenly open and honest they open board meetings to the entire company.

Additional speakers include Corey Ladas and Katherine Radeka who are speaking on Kanban and Lean respectively.

Numbers are limited and the $25 registration fee sounds like a steal to me!

Alistair Cockburn (@TheOtherAlistai) has posted a humorous yet incisive article reminding us that what absolutely certainly matters in software development is:

• Coding
• Testing
• Listening
• Designing

..  ergo, “That’s all there is to software. Anyone who tells you different is selling something.”

His compulsion to remind us of this core essence comes from the emergence of all kinds of newfangled buzzwords.. “Recently we’ve been hearing of “Agile 2.0” and “Beyond Agile”. The ad copy for these scary buzzwords includes initial architectural modeling, MSF Agile, AUP (Agile Unified Process), and Agile Model Driven Development (I note even the acronyms are getting longer), distributed teams, modeling tools, progress tracking tools.”

Certainly myself and the teams within which I have worked who had achieved success through our agility kept things lean and simple.

• No bug databases
• No electronic story card tracking
• No silos/departments
• No cubicles

Instead (and assuming you are a small, collocated team with access to usage/domain experts), try some naked agile.

“Drop the fancy tools. Drop the fancy rules. Get together. Talk, understand each other, trade ideas. Invent, code and deliver. Check in with the sponsors and users. Reflect on what you’re doing and see if you can get better.”

Read Alistair’s article in full

I happened upon the Clean Code Cheat Sheet and thought it worthwhile to share. It draws together a number of principles which help you achieve cleaner and more habitable code.

It includes:

• The Get It Done Adagio
  • Make it Work
  • Make it Right
  • Make it Fast

• The Three Rules of TDD
• SOLID Principles
  • SRP
  • OCP
  • LSP
  • ISP
  • DIP

• Law of Demeter
  • Bad smell
  • Local methods
  • Local fields
  • Local params
  • Local objects

• Connascences
• Coupling
• Cohesion
• Common Metrics

A must read if you program and you’re not already familiar with them.

@graemerocher just tweeted about the Nuts Grails plugin which provides web based IDE from within your Grails application. Talk about eating your own dogfood!

Here’s some of the key features as listed on the project homepage:

• Currently code completion is available only for groovy files
• When user pressed ctrl+space completion suggestions will be shown
• Variables and methods available to current scope, classes and their methods and properties will be shown in completion dialog
• User can navigate with arrow keys
• Users can select any of the suggestions by pressing enter key
• Suggestions will be sent from server side. After suggestions are received by client they will be filtered further while user continues to edit.

For those using Grails 1.1 already there’s a new command line argument for testing which re-runs only tests which previously failed.

grails test-app -rerun

Thanks to @wangjammer5

My friend and associate Chris Pitts, an Agile Coach in London, has weighed in on the ongoing debate about software craftsmanship.

Chris is focused on trying to move the debate from just being open to interpretation toward specific codes – as drawn from other present day crafts such as carpentry, surgery, architecture/building and so on. 

He proposes that Software Craftsmanship:

• Needs a set of ethics
• Needs a set of tools and techniques that are the generally accepted best way of doing something
• Needs continuous learning
• Needs apprenticeship

Read the full article.

For the benefit of those who don’t already know, a call to raise the bar for Software Development has spawned: Manifesto for Software Craftsmanship. Originally inspired by Uncle Bob Martin, this call to arms for quality has quite a few thought leaders getting vocal.