Using the Wii in Rehabilitation?

It's just in the research stage at the moment, but there's an underground movement to use the Wii for health purposes, rather than gaming. In fact this type of research stretches back to the EyeToy ([1],[2] and a few more besides) proving that playing a physically immersive game offers a significant improvement in motor function in recovery from stroke.

Now, we're seeing the emergence of surgical training tools, following work that showed a warm-up on the Wii improved surgical performance. So, what else do we have to build on with the Wii?

Well, there's the WiiFit board (essentially a low-cost, low-fidelity force platform) for starters: could we see balance based rehab "games" improve recovery from stroke or help knee osteoarthritis patients? The hand held controllers provides a very obvious interaction tool, but they could be (and are being!) strapped to other limbs for feedback of full body motion.

One of our goals at the EMHD is to encourage the application of lower cost technologies suited to a specific purpose so they can be successfully deployed to more centres and more patients at a fraction of the cost of fewer high cost systems that are available to a select few. (You may think this is at odds with my job at Vicon but it isn't: we could be selling products in the future to fit these requirements and making a happy income form it).

Who knows, maybe you'll be stepping on the WiiFit in a few years if you have a physio following a knee injury...

5S Kaizen in Software Engineering: Part V Shitsuke

And finally we come to the end: Shitsuke, or usually in English, Sustain.

This is the process by which Seiri, Seiton, Seiso and Seiketsu are maintained and - as for Seiketsu - is not so different from the way Kaizen should be applied to more traditional engineering fields. Indeed, this S is very aligned with the core idea of Kaizen, as it is to do with continuous improvement of the first four Ss. To apply Shitsuke, we must initiate the review process and plan a schedule for the maintenance of all of the ideas and infrastructure we put i place previously. The process for reviewing and assigning responsibilities for the maintenance of the whole and the sub-parts of the systems are dependent mainly on human factors.

To apply Seiketsu to our software development practices, we could:

• Undertake active project review.
• Practice project retrospectives.
• Timetable periodic reviews of the software development infrastructure.
• Assign people (quality engineers, domain experts, administrators, rule enforcers, coaches etc.) to all of the aspects of the practices and infrastructure.
• Facilitate the means for suggested changes to be trialled and rolled out.
• Undertake individual and group level continued professional development (CPD).
• Create opportunities for individuals to promote their personal practices and expertise to the team.

So, that's me done, for a little while at least. These thoughts are doubtless naive in some ways, but I hope I've managed to elucidate some useful ideas, for my own retrospective benefit at the very least. I'm sure this wont be the last I write on this topic, as two of my recent book purchases are 5S Kaizen in 90 Minutes and The Toyota Way...

Kaizen and Software Engineering: Other Resources

After claiming that there isn't much writtern on Kaizen and its constituents applied to software engineering, I found a few more pages today.

• Ballot Debris looks to be a good blog mainly on Agile with quite a bit writ tern about Kaizen.
• I found this post by Kenji Hiranabi on InfoQ about applying "Kanban" (another concept from the Toyota Production System).
• Finally (for today at least), this post on LifeHacker has some nice things to say about applying Kaizen to your personal work.
• I'm realising from a lot of the posts I've read today that leaving Tom and Mary Poppendieck's #1 and #2 Lean books in my To-Read list is pretty criminal: they need to be expedited to the top!

5S Kaizen in Software Engineering: Part IV Seiketsu

The fourth of the 5 Ss is Seiketsu, or to Standardise. This is essentially the way in which Seiri, Seiton and Seiso are rolled out across a workplace. With Seiketsu and tomorrow's topic, Shitsuke (or Sustain), the major differences between traditional engineering practices and software engineering begin to fade, as the nature of the processes are not the focus of attention here, rather how those processes are maintained and improved.

Standardisation in software engineering is a common concept, but it must embody all aspects of the practice (physical and software resources, personal and shared) as I have been suggesting over the last three days:

1. Standardise the physical workplace where possible: maybe promote a standard cube layout; provide the same set of texts at multiple sites; develop an equipment standard for PCs; create minimum test equipment requirements for new hardware integration projects.
2. Standardise software development where possible: most importantly, coding standards and best practices; create commenting/documentation standards and automated tools; create source code organisation and dependency management policies; provide a patterns policy guidance (perhaps big posters, coaching); suggest a standardised set of developer resources such as code editors.
3. Standardise our project management methods where possible: suggest a range standardised methods for costing and tracking projects; educate engineers in the proposed techniques; create template project documents (perhaps a “skeleton project”).

Tomorrow's topic, as mentioned above is Shitsuke, or Sustain. Once we've looked at that, I'll try and sum up and pick out some areas that are the most ripe for learning from Kaizen 5S.

5S Kaizen in Software Engineering: Part III Seiso

It looks like I'm first up again today, so while Rory's strapped in his high chair shovelling his breakfast in, I'll get on with the 5 Ss.

Today's S is the third - Seiso - which is normally translated to Shine. No matter what your field, we can sum this up with the idea:

"Clean desk at the end of every day"

In a more general sense, this means making everything clean, presentable and ready for immediate use and involves taking shared ownership of and pride in the workspace and assigning duties to maintain this.

In software, we have the concepts of both shared ownership and individual ownership (areas of expertise and responsibility). As with Seiri and Seiton, we must address physical and software resources in the same way:

1. Return the physical workspace to its rightful state: have some shared ownership of the open areas, but individual ownership of some resources (e.g. library, journals); track the location of all test equipment.
2. Keep personal software and hardware resources clean and performing optimally: most importantly practice continuous integration; build all configurations regularly (possibly automate); regularly shut-down PCs; regularly cleanup and de-fragment disks; delete test code; delete unused icons and software; possibly re-install OS and software periodically.
3. Keep the shared software resources clean and tidy: most importantly, continuously re-factor; re-factor and re-organise to break dependencies; remove experimental code; create and enforce a coding standard; fill in time sheets where provided; record project changes and set-backs; maintain project documentation automatically where possible (e.g. from tags in source code, commit messages etc.)

In order to effectively maintain the “cleanliness” of a code base, there needs to be some measures of “dirtiness” that keeps the exercise from being subjective and easy to subvert:

• Review code (largely subjective, but this is the point where coding standards and best practices are enforced).
• Measure dependency metrics (see Uncle Bob's excellent Agile Software Development book for an introduction to the sorts of metrics that are useful).
• Measure unit test code coverage.
• Automate some standards checking (e.g. copyright statements, line endings, interface comments, spell checking).
• Static profiling.
• Dynamic profiling.

Despite what seems to be an industry-wide aversion to maintaining a clean desk, it turns out that we are extremely keen on cleanliness in our shared software workspace and have been developing techniques to maintain this for some time!

Right, we're just over the halfway point. Tomorrow is Seiketsu, or to Standardise.

5S Kaizen in Software Engineering: Part II Seiton

Today's entry is Seiton (usual English translation to Straighten) and it can be summed up neatly as:

“A place for everything and everything in its place”

Remembering the three resources categories from yesterday, we can apply Seiton in three main areas:

1. Organise the physical workplace: organise bookshelves for quick reference and a library for less frequently used texts; provide a whiteboard/flip-chart per area; make up test equipment trolleys that can be move wholesale between workstations; make sure everyone has a patched Ethernet connection for remote test equipment; make sure everyone has a phone; ring-fence critical testing equipment.
2. Organise software resources: re-organise source code where necessary; create a repository for pooled test data and automated methods for using it; create automatic installation of developer resources (debugger, scripting languages etc. and standard environment settings); provide getting started guides for everything; create and enforce coding standards and best practices.
3. Organise our project management resources: pool and organise pre-existing and ongoing process documentation; provide centralised resources for tracking effort and cost (e.g. time sheets); visibly display up-to-date project management data for all interested parties to see (physically and electronically).

This is probably on of the easiest aspects of 5S to understand: the basic mantra is to be in control of your working environment and know where everything is and how to use it effectively at all times.

The next topic is Seiso, or Shine. Same place, same time tomorrow (unless I get a lie in).

5S Kaizen in Software Engineering: Part I Seiri

I made a note a while back about my thoughts on if, why and how the 5S ideas from Kaizen could be applied to software engineering. I made quite a few notes about this and thought I'd put them on here in an episodic manner, so we start with the first S: Seiri (the english translation is usually Sort).

In Kaizen, this is the act of removing things that are not used from the workspace; bringing things close that are frequently used. Essentially, the objective is to trim time wasted finding, calibrating and utilising resources.

In software, our software building and debugging resources are:

• The source code
• 3rd party libraries
• Code management tools
• The compiler and linker
• The debugger
• Other development resources used to build and deploy the working software on the target machine such that it can be run, debugged, profiled or built for test or release etc.
• Test data sets and data streaming services

We must also remember that we have physical resources needs too:

• PC, monitor, input devices, other output devices
• Test hardware
• Reference books (how many times do you need to pick up Effective STL or The Standard?)
• Programming buddy (if pairing)
• Access to the product team, stakeholders and (ideally) users
• Access to the test team

And finally, we have resources that aid in the design and development process (both physical and IT):

• Meeting rooms
• White boards, flip-charts, markers etc.
• Software resources for co-ordinating the design effort (Sharepoint, wiki, standard office software etc.)
• Project management tools (e.g. tracking software, time sheets etc.)

So, there are probably three categories in which we should apply Seiri:

1. Physically tidy up individual and shared workspaces: Get rid of stuff that’s in your way and make sure you have access to all of the physical resources you need, including the essential reference texts, whiteboards, markers, flip-charts, allocated test equipment or permanent Ethernet connection to it; move un-necessary and infrequently used resources away.
2. Tidy up individual “software workspaces”: clear off your desktop; make sure everything is installed and configured that you need; uninstall unused software; organise your PC and the data on it; create batch scripts to automate repeatable activities; create immediately accessible links to wiki pages and shared resources; organise personal test data.
3. Create an efficient “shared software workspace”: make getting, configuring and building the source code quick and easy; organise the source code and remove unused code; cut down dependencies to reduce solution sizes; provide easy access to shared design and documentation resources; trim down the design and documentation requirements to an acceptable minimum without duplication; throw out obsolete specifications; automate testing; automate documentation; pool test data, provide connections to test equipment; provide services to stream test data.

Next up tomorrow is Seiton (or to Straighten)...

Giving Dad a Boost

I sorted out one of my Dad's Birthday presents recently: some websites to publicise his work a bit more and hopefully reach a few more customers. This post is not going to spoil the surprise because my folks don't know about my blog. I'll tell them on Dad's Birthday...

So, if you like a glass of wine, visit www.northwestwineguild.co.uk or www.winedrinkersnorthwest.co.uk and contact my Old Man!

I reckon if we can get the Old Fella a bit more comfy on the internet, then maybe a blog's the way forward with him: he could post reviews about new wines, have ongoing reactions (now those are a COOL new addition, thank you Blogger once more!) about various wines and offers, polls for which wines people prefer and feeds/emails for followers to keep up to date with what's new.

One step at a time though, we've yet to persuade him to part with his box full of cards of customer records...

C++ Book Poll

I conducted a straw poll around our office today to isolate the C++ Books we dip into with regularity. I fancied creating a little bit of dedicated shelf space for the books that we regularly need to lay our hands on. (In doing this, I'm trying to apply the first two Ss of Kaizen 5S to our office: Seiri - to sort and Seiton - to straighten).

Want to know what came out on top? No? Tough.

Joint 1st: Effective C++ (Scott Meyers)

Joint 1st: More Effective C++ (Scott Meyers)

3rd: The C++ Programming Language (Bjarne Stroustrup)

4th: Effective STL (Scott Meyers)

Joint 5th: Exceptional C++ (Herb Sutter)

Joint 5th: More Exceptional C++ (Herb Sutter)

Joint 5th: The C++ Standard Library (Nicolai Josuttis)

8th: The C++ Standard (BSI)

Bumbling around with one and two votes were Modern C++ Design (Andrei Alexandrescu), Beyond the C++ Standard Template Library (Bjorne Karlsson) and Agile Software Development (Bob Martin).

The surprise loser with a score resembling last place on Qi was the "Gang of Four" patterns book!

So, what does this say about developer habits, at least at Vicon?

Firstly, it says we regularly turn to the books that tell us about the traps and pitfalls and essentially how to use C++ correctly and efficiently. Scott Meyers' books rightly deserve their place at the top of any poll about how to write (and how not to write) C++. Stroustrup's up there for most people too (naturally), with Herb Sutter's books being favoured only by those willing to open the closet on C++ and reveal the full horror of its intricacies! I reckon there's probarbly a correlation between the "exceptions, what are they?" crowd and a no-vote or negative vote for Sutter.

An interesting point raised about the Meyers books (and the Sutter books to some degree) was that we can never remember which important item is in which! Can you remember which books "catch exceptions by reference" or "make non-leaf classes abstract" are in? Me neither.

The surprising thing for me was that very few people reach for The Standard. Perhaps it's just easier to go straight to F1 for a given function or look up the standard function on the internet.

The books with just a few votes do show that us Viconites are at least moving forward: Alexandrescu's book may be a few years old now, but it's still very relevant if you want to learn about how to write powerful generic code, the Boost Book shows how much boost is used and Uncle Bob's Agile Book illustrates a desire to move practices on, together with a healthy attitude towards patterns.

Or does it?! Design Patterns received only negative votes! Perhaps the patterns in GoF are just looking a bit old now. The book is definitely not complete any more, nor is any. In fact the best reference source for patterns is probably the Wikipedia page: it has all of the GoF patterns in, additional ones from Code Complete (Steve McConnell) and a few more besides, not to mention the slew of concurrency patterns referred to in neither text. There is a decent text out there for concurrency patterns (apparently) called Pattern Oriented Software Architecture vol 2 (Douglas Schmidt et al.), but the Wikipedia page still outstrips it by a factor of well over 2!

A Sad Career Day

Today was a sad day for me because it was the first time in my career that I've had to tell someone that their application for a post was unsuccessful. I realise that this is a monthly occurrence for some people, but there's a first time for all of us.

It didn't seem to matter how I phrased the rejection, it always sounded trite and every attempt seemed vaguely familiar and evoked a feeling of distant dejection. In the end I settled for:

"I'm sorry to say that your application has been unsuccessful on this occasion"

I hope this is the norm and that our unsuccessful candidate is not too upset (who was incidentally excellent, just pipped at the post by others with that extra bit of lucky experience in the exact areas we were looking for).

Nice One Blogger :)

Considering my post yesterday, it is a little ironic that the simple instructions on Blogger and my domain registrar to direct www.codeforlife.org to my blog went smoothly and without a hitch :)

Well done Blogger for making it easy to do this and thank you 123reg for a relatively simple DNS dashboarb too!

Non-Techy-Techy-Stuff

Is this the stuff dreams are made of? Information technology stuff for the masses that doesn't require ringing your most techy mate to help you get up and running?! Probably.

Far too many times lately, I've had to help people get things done that could be so much easier if it wasn't written by geeks like me! Try explaining to your wife:

"...the reason you couldn't attach to the college VPN is because the router didn't allow IP-Sec or NAT pass-through: I've opened the relevant UDP ports on the router and the firewall and added the domain to our firewall trusted list and it's now working."

And breathe. It would obviously be foolish to start asking if she can check if college offer SSH, SSL or maybe even L2TP access cos these can be better for some tasks... Setting up her email from home was just as bad with questions about IMAP servers and what not.

The problem is that some this stuff could be so much easier if the geeks didn't build their little ivory tower of three and four letter acronyms. It's just as easy to say "virtual private network" as it is VPN. Maybe even just "Virtual Network" would suffice and be a lot clearer. A greater problem is that this vast array of technology is so close to the surface of what's going on when we use modern PC and web technology and it's really hard to insulate the user from it in a robust manner.

Is there a solution? Yes, but it will take time. There is already a thicker layer of non-techy people interfacing between the people writing the stuff we use in IT (sorry, information technology) and the users than there used to be and I think this needs to become more pronounced. We know about this problem in the software industry (and books like The Inmates Are Running The Asylum try to address it), but it's maybe not heeded in the sector where the technologies are created. Was there anyone around to stop whoever coined the acronyms NAT, PAT or L2TP from doing it and instead suggesting some more descriptive titles?

Responsibility for addressing these problems belongs to many, but mainly the software engineers who create operating systems, software for interfacing with devices and networks. Mac fans will doubtless wave their flags insisting it's all easier on their side of the fence (but some of the same problems still exist) and that's because Apple just seem plain better at engineering than most other software houses. Lets follow their lead and hide all of the crap from the users and dumb it down. Just as the premiere motoring experience was once the Model T Ford and is now a car that will almost drive itself, so (hopefully) using computers and the internet shall also be thus transformed.

Taking Exception To Exceptions (Groan)

I've been reading Herb Sutter's More Exceptional C++ lately and it is - like #1 in the series - a long, hard read that leaves you even more worried about the code you write (and you should be: C++ will cut your throat in your sleep if you don't hold it arms length). I've just finished another section on exception safety (unsurprising given the title) and it answered a few questions that I've held on to from discussion with people who don't care about exception safety.

So, the main point made by those who don't believe in exception safety is:

"What's the point? Once the exceptions thrown, you're buggered anyway right?"

Wrong, the program is attempting to exit in a predicatable manner, carrying useful information away from the site of the exception to whatever might be waiting to catch it. Worse still, if you really don't care and you break the cardinal rule and allow an exception to subsequently leak from a destructor, then you cause the program to terminate. Not crash, terminate, meaning the run time just ends, the stack isn't unwound, resources aren't released (although the memory is passed back to the OS) and you run the serious risk of leaving anything you were interfacing with outside your own runtime in a seriously bad state.

Maybe the died-in-the-wool oponent of exceptions can still argue that the cost of writing exception safety into programs (and even worse, retro-fitting exception safety) is just not worth it to make a crash go more smoothly. If you absolutely don't care what your clients will experience when your app crashes, have no wish to gather error reports from the field, don't mind contributing to the odd blue-screen-of-death and don't care how much you compromise any future client code by undermining the fundamentals, then by all means continue.

However, exceptions are here to stay and there are some extremely simple practices we can adopt to protect the code we write and subsequent client code: learn about David Abraham's basic, strong and no-throw guarantees and especially, never allow an exception to escape from a destructor. Use the canonical form of assigment as much as you can (not just in assignment operators): Create a temporary, copy everything into that, then call a no-throw "swap" operation with this. Finally, use RAII everywhere. I can (looseley) quote Stroustrup to justify this one:

"The only code guaranteed to be called after an exception is thrown is the destructor of objects on the stack"

Basically, RAII is the only thing at your disposal to clean up if exceptions are thrown (apart from try-catch blocks obviously).

So, what am I rambling on about? Essentially it's that exceptions happen and if we want our programs to behave as intended in these circumstances - and maybe even do something sensible with the valuable information available - there are some rules we need to follow. These rules are simple and need considering up-front, not retrospectively, and are basically very good C++ programming patterns anyway.

Why We Should Kill Prototype Code At Birth: It Bites Back

I realised with some embarrassment today that one of the aspects of our biomechanical modelling software I'm largely responsible for - a file format for skeletons - is a mess. I didn't try to defend it, because I already felt a twit.

What went wrong? As far as I can tell, we (not just me, but mostly!) did a few things wrong.

First off, I didn't separate prototype algorithms, application business logic and file formats from the trunk of our codebase. Because of this, I was carrying legacy problems before anything even got out of the door!

The second failing happened longer ago: I didn't clearly set out a clear enough design of what I was starting to do. I remember *trying*, but the scope of the problem remained unbounded and I failed to specify the limitations of what I was building.

The last thing we (and I really mean WE) failed to do was lay out a plan to take this work through to its natural conclusion. It was very much a case of just a little, just enough here and there when we genuinely KNEW we were leaving it incomplete. Worst of all, we knew we were neglecting a hugely important aspect of the whole picture that would leave the design fatally flawed, but an open admission to this problem would have have been laughed (nervously, knowingly) off the face of the planet. I didn't have the balls to stick my neck out.

So, what can I do? I know that the "fundamental flaw" I speak of still needs to be addressed and I have to make sure I state the case effectively and back it up with clear estimates of effort to allow our product managers to make an effective decision about the future of this area. I can also learn from this mistake and realise when I'm going down this path again and put a stop to it. A realy simple thing I'll be pushing for in the future is to do my prototyping in a completely different environment to the body of our trunk code: I'm thinking more Matlab, less C++. This also gets around file format problems also, as everything can be serialised natively in the Matlab environment, without having to do half-arsed file format designs that end up out the door in a released product. Which brings me right back to where I started...

Medical Extraveganza

Yesterday was our annual "Medical Extraveganza" day at the IMechE. This is always a tough day, but once again, I'm very proud to have been a part of it. The quality of some of the undergrads competing for the prizes is quite startling! I remember there being little in the way of teaching presentation skills while I was an undergraduate, and my experiences today suggest that either the kids are just naturally better at it, or that they are being well taught. I was also struck by the excellence of the postgrad competition entrants: I don't remember being as confident, thorough and well rehearsed at that stage in my career!

One talk from a postgrad called Mike Strickland stood out particularly and he (rightly in my opinion) won the prize for best presentation. So what did he do right that made him such a clear winner?

The first thing he did, we can all achieve with effort: he knew what he was talking about. Maybe not so surprising considering he's been living and breathing his thesis for 3 years, but the lesson is that we can never expect to make an effective presentation without knowing what we're presenting in detail. If we're not confident that we know more than our audience on our chosen subject, then this can show as an absence of complete confidence in our material, paving the way for the subsequent beating we'll receive during questions.

The second lesson is again within our control: he set out clearly what his work was about, where the assumptions lay, the questions it might answer and, most importantly, the questions it dit not answer. If you lay these caveats out openly, then you've already answered half of the questions that the audience may have. This kind of honest appraisal of your work wins respect from academics and engineers more than people may realise: pretending you have every base covered and the perfect solution invites a critical eye. If you play your own "Devil's Advocate", the no-one else can!

The last thing that Mike had we can't all learn quite so easily: charisma. He's simply a good talker; someone you enjoy listening to. The criticism was made that he maybe spoke a little too fast for an international audience - and I would agree - but this is easily remedied.

So what can I say? I was mildly jealous of these young men and women, so confident and on top of their game so early in their lives! I've grown old enough now to realise that I can learn from people significantly my juniors, and today, I hopefully did. I wish them all the best in their future endeavours and hope to see more of the same excellent quelity at next year's competition :)