Refactoring is not a dirty word.  Time will always apply pressure on a project.  When this occurs, there is a tendency to want to cut corners.  If you are a “doer” coder, then I would expect the first working version of your source code is not particularly neat.  Your task is not over yet!  Make the effort to refine variable, function and class names.  Make sure you identify what is wrong with your code and fix it there and then. 

Unit tests are your friends here.  Well constructed unit tests help you to re-factor fearlessly. You will know if you break your code when you re-factor, as your unit tests will fail.  It is important that you have sufficient coverage with these tests.  If you miss boundary cases, or not test each code-path, you are leaving yourself exposed to introducing bugs.  Sometimes a few unit tests are worse than having no unit tests as they can lead to a false sense of security.

Having unit tests can also help you to produce less tightly coupled code.  It is generally code that is better abstracted and hence more compliant for code reuse.  In fact, the code you write is already used in two places: firstly in your application, and secondly in your unit tests.

Test-driven development is the technique of writing test-cases and then writing the code that passes them.  (There is more to it than that – but the fact that people write whole books on the subject probably tipped you off to that)  There is the concept that you write just enough code to pass the unit tests and no more.  It is a great way of ensuring code brevity.  Less code means less chance for bugs to exist.  It also helps to remind you of what you are trying to achieve in the code that you are writing.

Unlike some cases I have seen, refactoring is not “throwing away” a code base and starting again.  That is rewriting!  I have not seen much public endorsement of the rewriting technique for improving a code base.  Refactoring is merely the art of neatening the code.  A compiler will “understand” what it has to do, no matter how nasty (and bug ridden) the code may be.  The purpose of refactoring is to allow another human to understand what the code does.  As humans are (relatively) good at pattern matching, looking for repeated code blocks is a good first step when refactoring.  This code is not necessarily going to be multiple statements, or indeed even one complete statement.  Sometimes this repeated block is worthy of its own function, sometimes it may just be good to assign the result of the code block to a local variable.

It is worth spending some time on tidying the code.  I have yet to come across any firm metric to help you determine how much time this will be.  You don’t want to be accused of “playing” with the code, the way a child “plays” with food they don’t want to eat!  When refactoring existing code, it can be worth multiple check-ins.  If your project uses a continuous integration product and sufficient test case coverage, then this helps prevent you breaking code.  If you don’t use these tools, it still helps provide a level of transparency to your work.  It will be easier for someone to understand how the code evolved into the state it is.  This may be important in case bugs are introduced.

Remember that the result of this work is not to produce bug-free code, but code where bugs cannot hide!  You are aiming to make it readable for the next person by making the learning curve as gentle as possible.  Why bother making it easy for the next person?  Well, it may just be you!

There is a saying that motorsports promote innovation and development of motor vehicles.  Ideas and inventions that work in racing vehicles will eventually filter through to the mass market.  Often these inventions have practical implications for road vehicles; improving safety, reducing fuel consumption and so on. 

Sometimes, racing is more akin to straight advertising.  There is a cliché, “What wins on Sunday, sells on Monday”.  As an example, a few years ago radial mounted disc brake callipers  started appearing on race bikes.  These brakes offered fewer mechanical losses than traditionally mounted brake callipers.  This was due to the mounting points being at right angle to the braking force applied.  Traditional callipers would flex a small amount due to the fact they were mounted in a manner parallel to the braking force applied.  Soon after, radial mounted callipers appeared on mass-market motorcycles.  At the time of their introduction, a sizeable section of the bike press decided they were along the lines of a “cool toy” but complete overkill for road application.  That did not stop the idea from catching on. 

The Isle of Man is home to one of the toughest motorcycling races still run. The Isle of Man TT is run each year in the last week of May and first week of June on public roads.  The circuit is 37.75 miles (60.7 km) in length, running through villages and open countryside. There is little margin for error in such an unforgiving environment.  Deaths of riders are unfortunately common with over 200 deaths in its hundred-year history. Any event that runs for that length of time is going to attract a degree of prestige and these days, even competing there is a notable feat.

Next year another event will also be staged on the Isle of Man’s Snaefell Mountain Course.  The promoters are billing their event as “The world’s first clean emission and carbon free Grand Prix”.  It will feature electric powered and non-fossil fuel powered motorcycles, running in a one timed lap format.  Now that will be motorsport promoting innovation and development!

It is possible to divide groups of people in a great number of ways.  Left-handers and Right-handers, women and men, so forth and so on.  Sometimes two groups are mutually exclusive and adequate to cover all of a population base, sometimes (even in the above categories) they are not.  I am about to discuss two groups of programmers – but I would fully expect that there are programmers out there who don’t fit either category as precisely as I will describe them.

Category 1, which I shall call “the doers”, includes the majority of programmers I have seen and have read about.  Their personal coding style can be bluntly referred to as a “trial-and-error style approach”.  That actually sounds far too much like a harsh criticism.  The majority of these programmers are not clueless monkeys prodding away at a keyboard.  They have a reasonable degree of knowing what to do, but the detail is lacking.  As they code, details come into focus, nuances are dealt with and problems are overcome.  The beauty of this style of coding is that it is easier to deal with when writing.  There is no need for a detailed analysis of all aspects of the code, which in turn makes it easier to concentrate on a specific part of the code.

Category 2 I shall call “the thinkers”.  They represent a much smaller group of programmers.  Their approach is more of intense thought followed by intense typing – with rarely a backspace key pressed.  I would suspect that this group would have a far better ratio of keys-pressed to source-code output.  These are the true geniuses in the field, but based on my experience, they make up no more than one or two percent. 

In reality, even the “doers” utilise and require a high degree of concentration to perform their task.  The biggest difference tends to be that the first version of working code the “thinkers” write will be neat and orderly, whereas some degree of refactoring will be required for the “doers” to turn in work of a similar quality.

As mentioned in my opening paragraph, I do believe that there are times when you will not neatly pigeonhole developers into only one of the two categories.  Depending on the task at hand a thinker may act as a doer or vice-a-versa.

Personally, I place myself in the “doers” group.  I used to feel convinced that the “thinkers” was where I wanted to be as a programmer.  Indeed, I recommend thinking about problems as opposed to blindly trying anything that springs to mind.  These days however, I am more forgiving of my own ability or lack thereof.

The computing industry seems to be coming aware that most programmers are not “thinker” programmers.  Many agile and XP style approaches to programming rely on this.  Concepts such as pair-programming and test-driven-development tend to favour “doers”.  For example, the fact that a “thinker” will visualise the code in their head for a long time prior to writing it down, makes it hard for them to participate in pair-programming environments.

The real danger is that thinkers will not be given a working environment that suits their needs.  One size does not fit all.  As the majority of the industry is made up of “doers”, it is important that methodologies are followed that allows them to produce output that a “thinker” would be proud of.  Essentially, that boils down to allowing time for refactoring.  The code is not done the moment it “works”.  Newer methodologies accept this and build it into the process of writing software.  But that is a story for another time.

One way to avoid riding with wobblers and idiots is to ride by yourself.  Sitting in a pub talking to yourself about how good the ride has been so far is not as advisable.  There is a solution to this dilemma: Carry a pillion-passenger. 

Some riders tend to react rather strangely at the concept of carrying a passenger.  It is as though carrying someone means they are no longer allowed to enjoy the experience of riding.  If you truly ride like an idiot, with not an ounce of self-preservation, then maybe you should feel this way.  Most riders are not as fast or as dangerous as they may like to think.

For me, carrying a passenger serves another purpose.  I like to introduce people to motorcycling.  I do not do this with an expectation of “converting” first time pillion passengers into becoming motorcyclists themselves.  (Although this has been known to happen!)  It is more an opportunity to help people understand why I ride.  Hopefully, this helps remove the look of fear and abject horror some people get when they discover you ride a motorbike.  It seems everyone knows someone, who knows someone else, who had a “bad” motorcycle accident.  Is there such a thing as a “good” accident?

If you have never carried a pillion before, where do you start? 

Hopefully, you will be a competent and confident rider before you consider carrying a passenger.  Remember that a pillion passenger can influence the direction the bike is travelling in.  If you can, find an experienced pillion passenger to take first.  They may be able to offer tips as to what you should be doing or asking your passengers to do. 

Trust is an important part of carrying passengers and if you can help set your passenger’s mind at ease before taking them, then that is going to be a good thing.  Three things I recommend for helping achieve this are:

Have the proper riding gear for your pillion.  I am of the school of ATGATT. Essentially, dress your passenger to the level that you are wearing.  If they see you in full Dainese racing suit and you offer them a barely-legal helmet without gloves or jacket, then they may get a little fearful.

Give them some comforting words.  An instruction such as “If you want me to slow down or stop, pat me on the back”.  They should feel as though they have an element of control in the riding experience.

Give them some simple instructions on what to do.  This can be a gradual thing.  First time pillion passengers will be overwhelmed if you rattle off an instruction list that takes five minutes to get through!  So, the solution here is to start simple and build upon the steps.

The first time someone goes pillion passenger, limit the instructions to something like:

“Ask me before you get on and off the bike”.  This gives you a chance to brace yourself for the weight change the motorcycle will undergo once the pillion passenger climbs onboard.  (Make sure both your feet have good grip on the ground, you are holding on with both hands and you have applied the front brakes to hold the motorcycle still.)  If the pillion is heavier than I am, I normally spell out to them to not get on, as they would when mounting a horse.  In other words, leave the first foot on the ground and swing the other leg over, rather than climb on the foot-peg and then swing their leg over.  The “horse” method puts their entire bodyweight onto one side of the bike, which when combined with the weight of the bike can be a good way to topple over.

“Act like a sack of potatoes”.  Explain to them that if the bike leans, then they should lean with it.  –not more than the bike does and not less.  This can later be refined to looking over the “inside shoulder” of the rider in a corner, but at the moment, we are trying to keep things as simple as possible for them.

Work out “slow down” signals and also a signal you give them if you want them to hang on.

Smoothness of riding is the last piece of advice to give.  Gentle acceleration and braking and gear changes makes for a more enjoyable riding experience.  It also helps the passenger to relax and trust the rider.

With practise and familiarity, a competent rider and pillion passenger will be capable of riding at a decent pace.  Then, you won’t have to be mumbling to yourself in the pub at lunchtime.

There are a number of head-nodding moments in Clean Code.  The book mentions many coding guidelines and good-code principles that aim to simplify code that is written.  Software development is definitely a career where you must continuously learn.  Even so, I’m somewhat disappointed to be this far along in my career before learning the names of certain concepts that until now I have only known as “common sense”. 

There have been times when I have identified “bad code”, but pressed to state what was so bad about it left me speechless…  This does not make the task of improving the code impossible, but can leave you with an inability to justify and/or quantify the changes you make. 

Here are some of the more common rules:

One level of abstraction per function.

This rule is not given a “trendy term”. Unlike the other rules I’ll introduce it is dealing with functions, rather than classes.  But it is still important.  This rule possibly came from “days of old” when top-down procedural programming was all the rage.  It’s still important and sans lengthy example is best summarised as:  Do not mix details with abstract concepts in the one function.  If you stick to the idea that each function should only do one thing, then you will be going a long way towards avoiding mixing abstract concepts and technical detail.

Single Responsibility Principle

The Single Responsibility Principle (SRP) states: There should never be more than one reason for a class to change.  The object mentors web-site has a series of PDFs discussing various aspects of Clean code, and has this (in part) to say of SRP:

“If a class has more than one responsibility, then the responsibilities become coupled.  Changes to one responsibility may impair or inhibit the class’ ability to meet the others.  This kind of coupling leads to fragile designs that break in unexpected ways when changed.”

In a rather circular fashion, the definition of a responsibility in SRP is “a reason for change”.  In other words, a class written to obey the SRP only has one responsibility.  If we were to develop an Object-Oriented “Space Invaders” game, we may end up with a class for the aliens, that looked like:

 public class Alien
{   
    public void Move()
    {
        …
    }
    public void Render()
    {
        …
    }
}  

However, this is a violation of SRP.  We now have two reasons for changing this class.  If the AI model changed, the calculation of the Move method may require changes – likewise if there were changes to the Graphics subsystem, the Render method would alter.

Law of Demeter

This is also known as the Principle of Least Knowledge.

“The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).”

Object Oriented notation assists here, by having different scopes for the methods and member variables defined in a class. Clean Code points out that often you will see private member variables (good so far) exposed through public getters and setters methods (not so good).  This exposes the implementation details of a class allowing for other classes to violate the Law of Demeter.  Better (so the book argues) to expose the data through abstract concepts

“A class does not simple push its variables out through getters and setters.  Rather it exposes abstract interfaces that allow its users to manipulate the essence of the data, without having to know its implementation.”

The example given talks about a vehicle class that exposes the “percentage of fuel remaining” as opposed to “fuel tank capacity” and “gallons remaining”. 

This is by no means a definitive list of ideas presented in the book.  From my experience, violations of these principles represent the vast majority of “ugly code” that I have seen.  Once these coding techniques have been highlighted, it is possible to see where improvements can be made in existing code.  By refactoring code to utilise these principles, you can identify that tangible improvements have been made.

Recently, I found myself talking to a scooter salesman.  I don’t begrudge anyone their choice in transport – be it a Hummer or a skateboard, or anything in between - but scooters aren’t really my thing.  I was interested in the technology of this particular scooter.  It was a Vectrix scooter and for those of you who don’t know: they are driven by an electric motor.  

It’s very clichéd, but the stone-age didn’t end because the world ran out of rocks.  There are several well-known competing technologies vying to replace the internal combustion engine run on fossil fuels.  The least removed from the current technology are traditional engines run on ethanol (plant based) fuels.  Rubber hoses and seals quickly perish from contact with pure ethanol and as such some degree of new components are required to make the technology possible.  This technology is not without its downside:  There are concerns over the ability to produce enough ethanol as well as food crops to sustain the Western world’s way of life.  Also, engines run on ethanol still emit carbon-dioxide – thus contributing to greenhouse gasses. 

The second technology uses Hydrogen fuel cells.  This offers a huge potential energy source and is clean burning (the exhaust is water).  Hydrogen however, is reasonably hard to contain, has the notorious reputation of being highly explosive and would require a huge infrastructure overhaul to support its widespread use.  Ten years ago, those predicting widespread adoption of the technology thought it would require around ten years to mature.  These days, those candidates are predicting the technology will take around ten years to mature… 

 The third technology uses electric motors.  These vehicles may have once had a stigma of being slow and boring, but they’re doing their level best to throw off that persona.  The biggest problem the vehicles currently face are slow recharging times (compared with the time it takes to fuel a car/bike) and the range obtainable between recharges.  The price of the batteries is still quite high and this is probably the area where the vehicles are most “immature” but scooters such as the Vectrix are a viable proposition as a commuter vehicle.   Whether electric powered vehicles “mature” enough to be the successor to the internal combustion engine remains to be seen, but so far, it seems to be the most likely to.

For me, commuting is not why I ride a motorcycle and so scooters such as the Vectrix will be little more than a curiosity to me.  I wish the company well on their endeavours and look forward to seeing what progress they make.

About a year ago I wrote an article on comments.  That article left me feeling uncomfortable.  In it I made a point that people may think that their code is too simple to need comments.  Indeed, it is not beyond the realms of possibility that this is in fact the case.

I’ve been reading a book called “Clean Code - A Handbook of Agile Software Craftsmanship” by Robert C “Uncle Bob” Martin.  He devotes a whole chapter to comments – which is highly commendable.  His thoughts on comments can roughly be surmised by the following extract:

The proper use of comments is to compensate for our failure to express our-self in code. … We must have them because we cannot always figure out how to express ourselves without them. …  Every time you express yourself in code, you should pat yourself on the back. Every time you write a comment, you should grimace and feel the failure of your ability of expression.

Despite my earlier post, I have reached the conclusion that I agree with him!  Indeed, the argument “My code is too simple to need comments” should describe the code you are aiming to write.  Being objective in your analysis of your code is the hard part.  Martin’s main objection to comments is what I was alluding to in my earlier post:  they tend to “rot” by becoming less reflective of reality over time if not maintained along with the rest of the code base.

A lot of the early chapters of Clean Code revolve around the “common-sense” aspects of coding. 

• Variables should be descriptively named (as should functions and classes)

• Functions should do one thing and one thing only.

• Functions should be short. (In fact, as Uncle Bob puts it: “Make a function short, then make it shorter”)

The second strategy I recommended for writing comments was to “pretend you were explaining the block of [complex] code to someone else”.  As Martin states, this is a failing of the code.  You would be better off refactoring the code so that it wasn’t so complex.  If you apply the “common-sense” aspects of coding, you will probably find that your complex code violates at least one of the rules.

I was pleased to see that Martin suggested that comments were okay when written to convey the intent of the author.   This is still my number one use for comments. 

It’s been an interesting read so far and I am sure there will be other topics that I wish to reflect on in blog form.  Expect to see more in the coming weeks!

I saw it again this morning…  A motorcyclist blissfully unaware of an indicator left on.  I wouldn’t know how many accidents this action causes.  Maybe not many – but any number greater than zero is too many.

Most modern motorcycles have standardised on indicator switch configuration*.  Operated by the left thumb, a self-centring switch can be pushed left or right to activate the turn indicator and pressed in (into the switch-block) to cancel the indicator.  For many years, BMW have done things their own way, in an effort to confuse motorcyclist journalists and test-riders alike.  For their new models appearing next year, it looks like they have finally relented.  Huzzah!

Indicators on motorcycles don’t self-cancel.  Like so many aspects of riding a motorcycle, the onus of responsibility is on the rider.  If your indicator is signalling your intention to leave a road, it is reasonable to presume that some drivers will actually expect you to do just that.  The possibility of a driver (or rider) pulling out in front of you has just increased.  Most drivers paying sufficient attention would probably detect that you are not likely to be taking the corner due to your speed, body language or lane positioning; but do you really want to rely on them paying attention?

When I learnt to ride, one lesson was passed on to me by a qualified instructor that I feel is justified in mentioning here.  Make a habit of pressing the cancel button on your indicator every now and then.  If you’re not indicating, it does nothing – but if you are, of course, it stops!  There is a tactile difference when pressing the indicator cancel button when the indicator is actually going.  From time to time, I’m surprised to find that I’ve left my indicator going longer than intended.

* As a funny “aside”, I once rode a friend’s Aprilia Tuono.  On my Honda, the horn button was directly below the indicator button, whereas on the Aprilia, it was directly above.  The end result was after every corner we went around, we ended up blasting the horn! (And yes, I blasted it a couple of times when performing my “redundant cancel” habit too!  To cover for excess horn usage, just wave at somebody as if you know them!

The framework on which I predominately work on has used a “nightly build” script for longer than I care to recall.  While the new cool kids on the block have turned to techniques such as continuous integration, we still rely on the build “once-a-day” technique, or manually kick off the process when required.

Way back when we established our build script, one of the developers created a testing framework with which we could perform unit testing.  It was no jUnit, but it performed a similar role.  Our team wrote some unit tests in a slightly less than committed manner and we felt good about the whole process…

That trusty in-house utility has served us well over the years and we still add unit tests to it, but the whole concept of unit-testing has matured a vast amount from where it was when we originally set off along that path.  Realistically, some of our unit-tests would more accurately be described of as integration tests – that is, they are testing the interaction of two real classes.  This isn’t a problem in itself, but it is not an area that unit testing is meant to be testing… 

My current “side project” (read “train-time project”) has therefore been to change our unit-testing application over to an xUnit framework.  I could have left the legacy framework as part of the build script and built a second testing framework for all new test-cases, but fortunately the underlying interfaces that drive the xUnit implementation are similar enough to allow relatively painless migration of our existing tests into the new framework.

With the existing test-cases migrated, I turned my attention to the development of new test-cases.  Not wishing to repeat the mistakes of yester-year, I did a little research on “mock objects”.    As one presentation suggested, I googled “mocks aren’t stubs”.  At this point in time, it is safe to say I am not an expert in writing unit-tests.  I have done them, I can see their worth and I’ve no doubt it doesn’t take a lot to get competent at writing them, but I’m still learning. 

So as a really rough approximation of what the mock objects can do for you:  They allow you to exactly define what things you are expecting the mock object to be used for in your unit-test.  How many times a function of the mock object is used, what parameters it will be called with and what return values it should give.  This helps give you an extra set of conditions by which you can verify that your code is correct. 

One thing that strikes me as “odd” about this level of checking is how you are ever meant to change your code again without needing to modify the unit test.  As the verification of running your unit test includes specifying exactly how your code interacts with other objects, it would seem to limit the changes you can make.  Maybe that’s the point!  I’ll tell you more, when I work it out!

When you look at the regular riders of the MotoGP this year, you find what can only be described as a “class act”.  Of the regular eighteen riders, eight have won world championships in the various classes, and that’s not counting the rival World Superbike Champions currently riding in the  MotoGP series.

From the earliest races, it was apparent that there was an upper echelon of riders this year.  Four riders looked like they would fight for the championship all year: Jorge Lorenzo, Daniel Pedrosa, Casey Stoner and Valentino Rossi.  These riders didn’t have top billing rites to themselves this year.  There were standout performances from other riders as well.  As the season progressed, the challengers started to fade away, leaving the two protagonists from last year (Rossi and Stoner) to resume their on track rivalry.

It is typical of top-level sports performers, that injury plays a major part in the “luck” department.  The risk of injuries in motorcycle racing is far more apparent than some other sports, but from a spectator’s viewpoint, the result is the same:  An injured sports-star cannot perform at their best. 

The first of the four contenders to “fall” was Jorge Lorenzo, with not one, but two spectacular (and painful) “high-sides”.  High-sides* are (thankfully ) rare these days.  The smoother power delivery of four-stroke engines and the advent of traction control systems reduce the times you will see a rider “sail” through the air.  Regardless of rarity, Lorenzo managed two of these accidents, sustaining injuries  and clearly denting his confidence in the races that followed.  

Pedrosa “faltered” next, his championship aspirations being dealt a fatal blow when he fell whilst leading the rain sodden MotoGP in Germany.  In the second half of the season, the other two riders (Rossi and Stoner) were simply a class above the rest of the field.

Casey Stoner looks to be a rider with sufficient talent to see him become one of the true greats of the sport.  At numerous times in the last two seasons he has simply been the fastest rider out there – by a long way.  At quite a few races he has dominated every practice session, every qualifying session and every lap of the race.  That the Ducati he rides is fast, is beyond question – but you need only look at how incompetent the other three Ducati riders have looked this year to realise it’s not just the bike! 

This year’s champion elect is none other than Valentino Rossi.  As in all sports, comparisons against competitors from previous years can be nothing more than speculation.  Statistically, he is already second in terms of “premier” class world-championships and first in “premier” race victories.

Whether or not he is the greatest racer ever will be the subject of much pub-debate for years to come.  In my mind, he is the ultimate racer, for the following reasons:

• He is a fierce competitor.  Even where a podium would suffice to seal a world championship, I can’t think of one instance where he has settled for a place rather than push for a win.

• He appears to be instrumental in improving the performance of the bikes he has ridden.  Developmental riding of a racing motorcycle is an undefined and rare skill.  Not many riders do it well, but the success of the bike manufacturers seems to follow Rossi.

• He is a sponsor’s delight.  He is thoroughly charismatic and consistently “clowns around” for the amusement of others.

• He is driven by the challenge.  He swapped teams when winning on a Honda became “too easy”.

One point which is often overlooked about Rossi’s most recent World Championship, but is telling about his competitive nature:

There aren’t many riders who win a world championship, then lose it, who come back to win again in later years.  I think the last rider who did this was Giacomo Agostini … 

* Most single bike racing accidents fall into two categories:  A “low-side” is where (normally) the front end of the motorcycle “washes out” from the bike.  The bike and rider fall down – on the side that the bike was leaning.  This is roughly the equivalent to a car “under-steering”.  A “high-side” typically occurs when the rear-end of the motorcycle runs-wide.  This tends to happen when the rear-wheel spins faster than the front.  (Roughly the equivalent to a car “over-steering”).  The immediate human reaction to the rear wheel “stepping out” is to back off the throttle.  The problem with this is the rear tyre can suddenly start to grip again and the bike is thrown violently upwards as it does so.  Where this happens the rider is thrown over the “high-side of the bike”.

Photo courtesy of: Kyn Chung,  released under a Creative Commons licence.