Mmmm… floor pie….

I bought a Raspberry Pi. I know there are faster, more powerful “System on a chip” computers, but the wealth of knowledge and information on the pi made it an obvious choice. I bought the “Model-B”, that features an Ethernet network port and lashed out and got a clear plastic case for it. I like to think it gives it a mini-Orac look…

I’m planning on using it to write basic web services to suit my needs. The first one, is going to be as the “back-end” (or “cloud” if you will!) for an Android app I have been thinking of.

Any app-store with half a million apps or so in it, is bound to have already covered the ideas I am likely to come up with. So, it is strictly a case of “done for the fun” combined with “not-invented-here” syndrome. Ultimately, I am planning on learning something away from what I do and know from work.

Like all true home projects, it runs the risks of being abandoned half-way through. However it goes, I’ll endeavour to blog about it as I go…

Phillip Island MotoGP 2013 – as seen by a spectator

I have been lucky enough to be able to attend the last three MotoGP events at Phillip Island. This year, the added challenge was that I could claim to have started the journey to the track from New York – arriving home in Melbourne on Saturday afternoon, before completing the journey on the Sunday morning. Anyone who has been to the track spots the irony in the pit-straight banner proudly proclaiming “Melbourne!”. The track is nowhere near! It takes over an hour from my house travelling the flat plains and countryside to get to the Island, before a further fifteen minutes is spent crossing the island to reach the track.

To keep me company (and prevent serious jet lag overcoming me whilst the race went on) I went with a fellow motorcyclist and friend from work who had not been to the event. As a Formula 1 follower, it meant the spectacle of pit stops and their possibility of helping decide the race outcome was nothing new to him. To me, it seemed like the organisers had come up with the best compromise they could have. It gave us a race, reduced the danger to the competitors as much as they could and still fitted in with the global television time slots. Not ideal, but better than sending the 31,000 spectators home without seeing the main event.

One thing about the Phillip Island circuit is that it is vast! As a general admission spectator, only the outside of the 4.5km track is accessible. Devoid of grandstand, corporate or media passes means you are left walking to get from one spot to the other. On foot, it takes a huge amount of time to circumnavigate. As such, picking a spot and staying in that vicinity is realistically your best option. This year, the organisers felt it appropriate to drop the “cloak room” facilities, which meant we were left lugging our motorcycle gear around all day. For once, the weather was kind and it was warm enough to wear no more than T-shirt and shorts. So we had a lot of gear to lug around! Wasn’t happy about that…

So, limited by luggage, we went to Turn one, near the marshals’ bunker. This is an excellent spot to spectate from. You are close to the action and the bikes are very near full speed. If you pick wisely, you will also be able to see Turn 3, watch the bikes through Turn 4 and up to Siberia, meaning you will witness plenty of bravery and overtaking. It is also the position of one of the super-screens so you don’t miss the action when the bikes are travelling around the other postcode on the opposite side of the track. Have I mentioned how vast the circuit is? Sure, photography from here requires a fast auto-focus or a lot of luck, but I can go stand on any street corner and watch motorcycles go by at slow speeds… And after three weeks of holidays lugging my DSLR around, I didn’t even bother to take it this year.

Before giving my commentary on the race, I feel I should divulge my allegiances that normally only the television gets to hear. I have been a Marc Márquez fan since his days on the 125s battling with Pol Espargaró. It was obvious he is a new crowd favourite. Unlike many riders, Rossi still gets the cheers he deserves, but so does the new kid. It is funny that two years ago, Márquez was the villain to most of the crowd, after the appalling crash into Ratthapark Wilairot at the end of free practice. I witnessed that crash and have meant to blog about the circumstances leading up to it. Unfortunately, Marco Simoncelli’s fatal crash happened a week later and that reduced my enthusiasm for blogging about motorcycle racing and partial justification of accidents.

About that race…
Even in such short “sprints” the racing appears to settle down as a pattern is established. Initially, it appeared that Jorge Lorenzo was capable of holding the two Respol Honda riders at bay. The Hondas are stronger under brakes, and would close a little into Turn 4, but by the time they were next at that point on the track, Lorenzo would have clawed back the ground he lost. Just prior to the pit-window, it appeared that the titanic struggle was slowly tipping in Márquez’s favour. The crowd could sense he was closing. Whether the stop watches would agree with us, or whether it was just wishful thinking from the spectators, I do not know – but, that is how it appeared.

Then the pit-stops unfolded. First Dani Pedrosa came through. We watched the super-screen replay of Pedrosa demonstrating how quickly you could stop the Honda, unaware of any dramas surrounding the new point at which the speed-limit took effect. The next lap Lorenzo came in. Some – including myself, were slightly mystified that Márquez stayed out. Wasn’t there only a two lap window in which you could pit? There was a feeling of “they know what they are doing”. Mercifully, we could not hear the track-side announcers over the noise of the bikes. No matter what you think of Gavin Emmett and Nick Harris, they are infinitely better than guys who get to cover one race a year when the MotoGP circus comes to town. Spoken commentary is not a skill that I have, but neither do they…

As Márquez reappeared from the pits, down the infinitely long pit-exit lane we all held our breath in anticipation. We could see it would be close… Lorenzo and Pedrosa closing, Márquez anxiously looking over his shoulder… I was willing him not to turn off the speed limiter early… Don’t spoil what will be an exciting finish! And out he exited. Perfect timing, in what if it were scripted would appear corny, melodramatic and unrealistic. Except it wasn’t! The first corner clash between Lorenzo and Márquez happened less than 100 metres from our vantage point. The way I saw it, neither party was innocent. Lorenzo was clearly wider than normal and Márquez came across further than he needed to. They both looked like they were trying to jockey for position in a bluffing game – in a schoolboy-macho type of way. Neither party was particularly guilty either and that matter should be put to rest.

After the pit-stops, racing resumed with Lorenzo leading Pedrosa and Márquez coming up to speed in third. In this second part of the race, Márquez looked to be clearly faster. He passed Pedrosa under brakes into Turn 4. It did not appear that Pedrosa had conceded the position and we were unaware of any penalty Pedrosa was apparently serving by dropping the position. He pushed on and there was a genuine sense that we were going to watch a classic race unfold. He looked to be catching Lorenzo and we were going to witness an epic battle! And then we weren’t… Márquez was slowing, he was coasting into the pits. No hurry, no excitement. The crowd was notably quiet – voices speculating as to what had just happened. MotoGP went back to its recent worst… Just a high speed procession for a few laps until the end.

As I stated earlier, I am a Márquez fan. But for the record, I think:

  • Intentionally or otherwise – he broke the rules.
  • He was disqualified for doing so.
  • The punishment fit the crime.

Quite simply, the rule he broke was for the safety of everyone: riders, marshals and spectators. Considering the safety of others is a lesson Márquez has yet to learn. It has been two years since the incident with Wilairot, but I cannot see any signs of him maturing in that respect.

In the end I was left with a sense of being robbed of a great race. Had Márquez not got himself disqualified, I think we would have seen one of the races that would have been remembered as a classic to rival Laguna Seca, 2008. But, as a race fan, every dull race makes the next exciting one, one closer.

Casey Stoner

Casey StonerSince witnessing first hand Casey Stoner’s utter domination of the Australian MotoGP round last year, I have been meaning to write a post about him. Now, with the announcement of his retirement at the end of the season it seems even more timely. 

In 2008, I had described Stoner as one of the “upper echelon” of riders – a status that appeared to be too “high-brow” to catch on.  The four I named in that post (Lorenzo, Pedrosa, Rossi and Stoner) went on to earn the nick-name of “the Aliens“.  I wasn’t alone in recognising that they were a cut above the rest.  How good are they? Since the beginning of the 2008 season, “the aliens” have won 72 of the 74 races held. On their day, any one of those four riders would be untouchable.  Plagued by injuries and bad luck, Dani Pedrosa is the only one of them not to win a World Championship in MotoGP. (yet?)

There are a lot of fans in MotoGP who only begrudginly accept Sonter’s ability.  Ironically, it has been Rossi’s dismal performances on the Ducati that have served to highlight just how good Stoner is.  The problem that a lot of fans have with him appears to be that Stoner is “just a racer”.  He isn’t the showman and extrovert that Rossi is. Stoner’s detractors have nick-named him “moaner-Stoner” which personally, I feel is unwarranted.  The thing I have enjoyed about the “off-track” Casey Stoner is that he is always honest about things.  When he did not do well  he would answer the press questions as truthfully as he could.  Some fans saw this as “making excuses” and maybe it was, but the answers were never phrased as why he didn’t win, only why he didn’t do better.

Stoner attracts fans based on one thing only –   His raw talent and speed on the bike.  He has never been about beating the record books, nor winning admiration of fans through off-track theatrical performances.  As a marketable product, that puts him at a disadvantage, but marketing people are clever and the best work  with what they get. When I wrote about Valentino Rossi, I mentioned that not many former world champions re-win a championship after they lose a couple.  Rossi and Agostini were rarities.  Now, you can add Casey Stoner to that list.

If you are a fan of MotoGP and your home event has not happened yet this season, grab the chance to witness one of the fastest riders the sport has ever known.  Until you see him riding live, you can’t fully appreciate his extraordinary talent.

I swear it’s true!

Blogging is not journalism.  Sometimes blogs are well researched articles absolutely worthy of a status of journalism and sometimes news articles are not. Other times blogs are little more than opinion pieces, the author’s own soap-box on the web.  Either way, writing allows for some extra degree of thought and contemplation not necessarily afforded to verbal communication.

I swear when I talk.  Maybe not as often as some, but more often than I intend to.  I think of swearing as an admission of failure.  I have some emotional reaction to something that causes an outburst, and my lack of eloquence prevents me from expressing myself without resorting to being a potty-mouth.  The only effective means I have of curtailing swear words is to pretend there are children present.  Introducing children to the common use of bad language somehow seems quite unacceptable.  I put this down to both my parents being school teachers, from a generation where bad language would at least receive the threat of having one’s mouth washed out with soap, even if I never saw the punishment executed.

As writing affords the author some degree of contemplation prior to putting pen to paper (text to screen?) I simply find it unacceptable to see swear words in blog text. Adding swear words can absolutely ruin a good post. If this is the only way you know to get your point across, then yours is not a point I need to know!

Airhawk

I recently completed my latest motorcycle touring holiday. I travelled more than 4000 kilometres (2500 miles) over the course of two weeks and two days, to attend the Philip Island MotoGP. The VFR800 is definitely a more comfortable touring bike than the CBR929 Fireblade that I made the trip on last time, but it is some way short of a Goldwing in terms of touring comfort. Fortuitously, a friend of mine lent me his Airhawk seat for the journey.

I am always sceptical of miracle motorcycle products. I have seen instances where some one’s praise of a product is little more than them trying to justify the purchase price of whatever product they are expousing the virtues of. In the past I have purchased and used sheep-skin seat covers for some of my motorcycles. To claim they make no difference, would be doing them an injustice. But, when you are riding a motorcycle for long periods of time, multiple days in a row, their improved comfort is short lived.

My suspicions that the Airhawk would be no different were proven to be wrong. I was more than a little amazed by the improvement in comfort the seat provided. Small interlinked air-pockets help evenly distribute the pressure. Because the pockets are interlinked, air is free to move between the various pockets. An unexpected benefit is the extra shock-absorbtion the seat provides. Hit a big pothole and you don’t get the proverbial boot up the backside. On an extended ride, this fact alone makes for a more pleasant journey.

I did eventually feel discomfort on the bike, riding up the Hume Highway on my return home. I don’t know if it was due to the boredom of the ride, but (rather unscientifically) I feel that some of the discomfort was caused by a lack of movement needed to ride in a straight line. Riding the Hume, is largely about sitting still and holding on. Not needing to perform gear changes or large steering input meant I was stuck in the one position for long periods of time.

Like all good (and many not-so-good) web reviews, I should really summarise my experience with the Airhawk seat with a pros and cons list.

Pros

  • shock absorbtion
  • greatly improved comfort
  • adjustable inflation to allow for different rider weights
  • weatherproof and quick drying time when compared to sheepskins

Cons

  • reduces the rider's feel for grip levels in corners
  • over and under inflation limits the effectiveness and improved comfort

In an unusual "neutral" category:

  • it changes the rider geometry on the bike

For me, the change in geometry was not substantial enough to be problematic. I was concerned about the increased weight placed on my wrists made by effectively raising the seat height. It is only a small change in geometry, but even small changes alter how the bike feels. For vertically challenged riders, it may also make the reach to the ground just a little more unnerving. Of course, not being a journalist and trying a formal review, I missed the obvious action of measuring just how much height was gained by using the seat. At a guess, I would say between 15-25 mm of increased seat height can be expected.

Given that I lent the seat, I will not give a subjective value-for-money opinion on the product. However, if I don't find one in my Christmas stocking this year, it will go on the list of things to purchase for myself!

Revision Control System Ettiquette

Develop software for any length of time, and you will reach the conclusion that being able to track changes you make to source code is "a good thing". Put a show-stopping or embarrassing bug in the last round of code changes you made? Being able to revert to an older version of the source code, may be the fastest way out of your problem! If it isn't, it may at least help you to understand what you did wrong – by comparing different versions of the source. This isn't rocket science – software development teams have had Revision Control Systems (RCS) to help them do just this for a long time.

If you work as a programmer and you have never heard of RCS, then I suggest you see this thoroughly excellent visual explanation of what one is. Then explain to your boss, that you need one. Those of you who are more in the know, will realise that the introduction I linked to is a few years old, and doesn't attempt to explain what a Distributed Revision Control System is, but for the purpose of this article, it is satisfactory.

Working collaboratively on a project more-or-less makes using some sort of RCS mandatory. Sure – you can survive without it, but it simply makes no sense to do so. One of the highlights of using an RCS is the ability to show how source code evolves. Being able to diff the revisions of the code can be useful to help fellow team members understand how the code came to be the way that it is.

Just because you can see what differences there are in two versions of the file, doesn't mean you will understand what the differences are! It is easily possible to change code sufficiently to make following your changes close to impossible. Even if you are developing in isolation, you should be using an RCS and acting as though someone else will be the next person to work on your code. This is especially important, just in case you are the next person to work on your code! :)

Here are some simple guidelines to try and follow when checking in code changes:

  • Only attempt one change per check-in. If you have several bugs to fix that all relate to the one piece of code, it is tempting to fix them all at the same time. This is discourteous to anyone attempting to understand your changes at a later date.
  • Explain what you are doing. When committing a change to the RCS, you get the opportunity to submit a "check-in comment". In much the same manner as commenting code, these are best used to describe the intent of your revision. Normally, people use the comment field to provide a reference back to a bug-tracking number. This is worthwhile, but it falls short of being a great check-in comment. I am sure that the vast majority of coders can type quickly enough that expanding their check-in comments won't take them too long!
  • Code styling / formatting gets its own check-in. So, you didn't like the order someone put the class methods. Or, they didn't put spaces between function parameters the way it is meant to be. You feel moved enough to change it yourself. Well, just check it in separately. Again, this goes back to being courteous to someone who may be trying to follow your changes at a later date. Logic changes can easily be buried / hidden by moving the function they occur in. The diff output will show that a function was removed from a certain point in the file and inserted somewhere else. Subtle changes in the function can easily be lost

All of the above recommendations are aimed at improving the accountability of the code changes you are making. This becomes more apparent when you are working on a team that uses code reviews as part of their development methodology. The relative-worth of code reviews can receive fairly heated debate, but that is a story for another time.

When Worlds Collide

I watched in abject horror as Dani Pedrosa weaved violently from side to side of the track, at the rear of the field as the rest of the competitors disappeared from his view. Pedrosa was travelling dangerously fast for the next corner and way off the racing line. The bike slowed imperceptibly as though the brakes had air in the lines. In an act of pure desperation, he pitched the bike over on its right side in a vain attempt to make the corner. That the bike would run wide and off the track was a given. What wasn’t so expected was the fact that with in excess of fifty degrees of lean angle and still heavily on the front brakes the bike didn’t “wash-out”. Rather, it merely acted as though the grass was covered in sticky glue, retarding the bikes momentum far more effectively than the brakes had.

Of course, I was Dani Pedrosa and this was the demo version of the game “MotoGP 10/11”. I must admit I enjoy a good racing simulator and as a motorcyclist was desperate to like this game. You can’t expect an X-Box controller to map accurately to the controls of a motorbike, so “realism” in such a game is always going to be a subjective term. The demo version of the game starts with all the usual assists you can expect in a modern racing simulator, including a “racing line” indicator that both indicates where you should be and how fast you should be travelling by its colour.

If you were to paint a line on a racetrack and ask me to travel at whatever speed I felt was appropriate but to stay close to the line, I reckon I could do a reasonable job. Asking me to do so in the game proved close to impossible! I think the largest problem with motorcycle games and a controller is judging a lean angle via the thumb-stick. Maybe I am just a n00b, but it seems difficult to use the thumb-stick and push it to an exact angle that is not at its extremity. Minor corrections are an impossibility as the only steering mechanism you have acts as a giant inverted pendulum. Dani gradually leans from one side to the other, meaning all direction changes need to be planned well in advance.

If I was allowed to call the shots for future development of the game, I would love to have a custom controller that mimicked handlebars and utilise the Kinect sensor to allow for body positioning on the bike. That way, body movements could provide minor line corrections, similar to what happens in real life. A less ambitious idea would be to use the second thumb-stick to provide this line-correcting behaviour. This presumably would have the advantage of being easier to port to the other game platforms.

On the positive side, the game is gorgeous to look at. The visuals are stylised rather than attempting and failing at photo-realism. The result is stunning. Screen shots look like an oil painting. Playing it makes it look like err… a moving oil painting! I don’t think it’s a coincidence that the demo only allows access to what must be the most picturesque circuit on the current MotoGP circuit – Mugello. Although it is even more absurdly difficult to play in “first-person” view, this really does bring out an excellent feeling of realism as your view is buffeted about by the wind rushing past you.

Strangely enough, you don’t hear the wind though. Mind you, this is not a bad deviation from reality, as you are missing out on 90+ dB of white noise blaring out of your television… The noise the bikes make is probably a fair approximation of a MotoGP bike. It certainly is not awful enough to be detracting from the game.

As for an overall verdict based on the demo version, well the jury is still out. I enjoy a challenge in a game and if I had “won” the very first race I attempted, it would not have been a game that appealed to me. However, there comes a point where wobbling around behind the rest of the field loses its appeal. Do I have the persistence to keep playing until I reach the point where I can challenge Alvaro Bautista and Mika Kallio for fifteenth and sixteenth place? I can tell you that unless that happens soon, I might have to just consign this game to the “too-hard” basket and wait for a revolutionary Kinect enhanced version of a motorcycle racing simulation.

Making an exception

I don’t normally blog about code. I don’t often make my blog entries into the lists that are so popular on the Code Project. Plenty of people do plenty of that already. Today, I am making an exception to these rules, to talk about exceptions… Nothing I am going to present is rocket-science. This article, is closer to introductory reading for a junior programmer, or to assist someone mentoring one. Although my examples will be in C#, they should apply for any object-oriented language.

Tip 1: Only trap exceptions you are prepared to handle

Here is a bad example that doesn’t do this:

try
{
    DoSomeFunkyMaths();
    DisplayResultsOfFunkyMaths();
}
catch
{
    // We know we may get a div by 0, so ignore exceptions.
    DisplayOurFunkyMathsFailed();
}

Instead, you should write your code as if you are expecting a particular exception.

try
{
    DoSomeFunkyMaths();
    DisplayResultsOfFunkyMaths();
}
catch (DivideByZeroException)
{
    // We know we may get a div by 0, so ignore that exception.
    DisplayOurFunkyMathsFailed();
}

Essentially, this boils down to “Don’t provide a general exception trap because something *might* happen. Trap explicit exceptions that we know the program can handle.
If you are thinking: “But wait! Our program could still fail and we’re not doing anything about it!” you would be right. It is better to fail early and know why you failed, than to fail later without a clue. When you “bury” exceptions in a generalised exception trap, you leave yourself open to a “clueless failure”. Imagine that DoSomeFunkyMaths() includes some writing of data to file. Now it is possible for I/O exceptions to occur as well as the division by zero. With a general exception trap, you will not know that this has failed and when the code subsequently attempts to use the data from the file, you will get unexpected issues.

Tip 2: If you are going to raise your own exceptions, make your own exception type.

Again, here is not what to do:

if (ErrorHasOccurred())
    throw new Exception("Something has gone terribly wrong");

The only way to catch this exception, is to catch all exceptions. If you haven’t figured out what is wrong with this, reread Tip 1 until it sinks in… While I am at it, try and make your messages a little more helpful than “Something has gone terribly wrong”.
In C#, it isn’t hard to make your own exception class. If you cannot be bothered putting much effort in, here’s a simple example.

public class FunkyMathsException : Exception
{
    public FunkyMathsException(String Message)
        : base(String Message)
    { }
}

This is a perfectly acceptable start for your own exception class. Now, code you write that throws exceptions, will use this, instead of the base exception class.

if (ErrorHasOccurred())
    throw new FunkyMathsException("Something has gone terribly wrong");

I still haven’t learnt to put a more meaningful message in. But, at least I can now catch a FunkyMathsException, where I want to, and leave other exceptions well alone.

Tip 3: A generalised exception trap does have one perfectly acceptable use.

I am not an expert on all languages, but normally, an unhandled exception will cause a program to terminate. Depending on the circumstances, this may or may not be acceptable.
Acceptable: Your program is some sort of stateless service that will be restarted via a script or operating system should it stop.
Unacceptable: Your program is a word processor and the user has not saved their document for the last 30 minutes because they are too busy typing away furiously on their “best-seller”
If your program falls into the “unacceptable to unexpectedly stop” category, a global exception handler is the way to go. Save / report the error / do what you have to do… Just be careful to try and not raise an exception. This is serious “infinite loop” / “stack overflow” territory and your program is already on rocky ground.

Tip 4: Exceptions do not cross process boundaries.

I do not know how general this tip is. YMMV. From what I have seen, calling code in a separate library via COM, exceptions do not cross boundaries. The calling code will throw some sort of exception, but most of the specifics to the exception will be lost. It is just best to use other means to relay failure messages back from the library code.

Tip 5: Do not raise a new exception in response to an exception

There may be times when you wish to perform some operation when an exception occurs, but not actually deal with the exception. For instance, the calling code may be better placed to deal with a particular exception but you wish to perform some logging action at the time. If you raise a new exception, you will have lost potentially useful debugging information, such as the call-stack of where the original exception has occurred. Fortunately, most languages provide the ability to “re throw” the exception, simply by using the “throw” keyword by itself.

try
{
    PerformSomeFunkyMaths();
    DisplayResultsOfFunkyMaths();
}
catch (DivideByZeroException)
{
    LogDivByZeroError();
    throw;
}

Tip 6: Exceptions are for exceptions

There is a balancing act between raising / trapping exceptions, or testing conditions with an if statement and acting accordingly. Using if statements increases code complexity and will take some processing time, every time the statement is evaluated. Using / trapping exceptions may simplify the code, but where an exception is raised, they tend to be far more expensive (time-wise). Therefore, using exceptions should be something that is done for the odd occasion where things haven’t gone according to plan. This point is a rather grey area and open to interpretation.

Gee! Thanks for the compliments!

The complimentary spam-bots are winning. A university lecturer once described computers as being high-speed idiots. It is an accurate assessment: they are many orders of magnitude faster than humans and yet lack basic intelligence. As such, it should come as no surprise that spam generators are quite pervasive in pushing out their content. WordPress blogs seem to be a favourite target.

In terms of blog content and readership, I fully appreciate that I’m just a tiny drop in a large sea of opinionated writers. Some of my posts attract attention on forums, but seldom do people find the need to comment on the post itself. This is frustrating, as I want a blog post to promote discussion and attract opposing opinions. I write to stimulate a conversation that I hope to learn from. Still, I am happy that people have taken the time to read any post I have written.

I moderate the comments that appear on the posts I write. I will not filter any comment – as long as it adds something to the discussion. Being a “tiny-drop” blogger means I can afford the luxury of moderating comments – I don’t have 100,000 readers all vying to make their viewpoint known. Spam-bots are now taking a “complimentary” approach to getting their content published. I have lost track of the number of comments along the lines of “Nice post – I really enjoy your content”. Yeah – good try… If you have a WordPress blog and you get comments like this, I’ve got news for you, and I will tell you slowly: They… are… spam! Try a search for the exact comment and see how many hits you get.

So the signal to noise ratio is appallingly bad. Less than 1% of all the comments this blog has received are genuine and thought provoked. The only worthwhile function these spam comments serve is to alert me to articles that have been linked from external sites. There is a definite trend that externally linked articles attract more spam.

Now that I have finished whinging, I’ll get to the point of the article… If anyone knows of a good WordPress plug-in, or code that reduces the likelihood of spam comments, please feel free to leave me a comment!

Time to end the RGV restoration

I have recently come to the conclusion that it is time to put an end to the project of re-building / restoring the RGV.  Don’t worry, this story has a happy ending!  My decision is not to give up on the project, but to finish it.  Discuss Project management for long enough and eventually you will end up talking about the three competing factors on any project.  The saying goes “Features / Timeframe / Budget.  Choose two”.  Although most of my experience with project management has been with software, the same idea applies to any project. – The RGV restoration would be no different, except for the fact that I had allocated a monthly budget of what I was prepared to spend on it.  This makes the budget a function of how long the project runs for.  So, this unnaturally skews the balance of the three competing factors. Unfortunately, it also makes for a long project!  I could have spent more each month, but I have seen too many motorcycle restoration projects run out of enthusiasm due to the large money pit that they can become (and no doubt how quickly in debt their owners can become)

Speaking of large money pits…  I kept a spreadsheet to allow me to stick to my monthly budget.  This in itself seemed like a wise idea.  It does however put sharply into focus how much money I have poured into the project.  (Should that be “poor-ed”?)  Given the prices that RGVs demand these days, it is suffice to say that I would be making a loss if I sold the project at this point in time.

In terms of where the bike is “currently at”:

  • It is still two packing shelves full of pieces.
  • I have recently had the front forks and rear suspension rebuilt.  This was only the second time I have used a commercial business to do any serious work.
  • I have sourced all the parts and I am in the middle of rebuilding the brakes.  That process will hopefully be a story for another time.
  • About the only outstanding parts left to purchase are new chain and sprockets and new tyres.  (For some reason I just don’t trust twelve year old tyres…)

Things I have learnt along the way:

  • I should not have attempted to restore this bike.  Despite starting with a “free” motorcycle, this project has cost a fortune!  It would have been cheaper to buy a running and almost road-worthy RGV and start from there.
  • By doing the boring things first (such as frame straightening) rather than the fun things (such as painting fairings and buying bling parts) the restoration project didn’t start with a bang and run out of momentum.
  • Some planning would have avoided the need to do things multiple times.  – I had to completely strip the bike to get part of the frame repaired.  I subsequently put the swing-arm rear suspension back on, only to remove the rear-shock to get it serviced later.
  • Buy good tools.  They really do make the job easier.  On the other hand…  Some once-off style jobs are not worth spending a fortune on.  Sometimes it makes sense to take the part to a workshop where the job can be done for you.  Removing the bearings from the rear-suspension linkage was a good example.
  • I have become quite good at watching where things (such as nuts / bolts / washers etc) go when I drop them on the ground.  This is an under-rated skill in my opinion.

One thing which I don’t need to learn is that this isn’t the end of spending money on the bike.  A track-bike is never finished and rarely cost free. Until I get the chance to properly put the bike through its paces, I don’t know if the gearbox is mechanically fine, whether the clutch plates slip and whether the engine will perform properly under load.  All these things will reveal themselves in the fullness of time!