Put some effort in!

Lazy programming annoys me. I see it on web sites, desktop applications and embedded systems alike. It is a bit hard to qualify what I mean by “lazy programming” so allow me to indulge in an analogy:

Imagine the programmer as a rock salesman. The user in our analogy becomes someone who wishes to purchase a heavy rock from the salesman and transport it to their garden. Carrying the rock is hard work and so neither the salesman nor the customer wishes to carry the rock far. The rock salesman has an unfair advantage here. His rocks are the finest in all the land, capable of far more “rocky goodness” than the customer can find elsewhere (OK, so maybe it is not a fantastic analogy… bear with me!) Consequentially, he need not try too hard to win the sale. So, he doesn’t. He takes the money for his fine rock, carries the rock to the front gate of his rock-sale yard and dumps it on the ground. He dusts off his hands and leaves the customer with the effort of transporting it the rest of the way home – on foot – on a hot day… Did I mention it was a heavy rock? A greater rock sales person carries the rock themselves, to the front gate of their customer. The customer is forced to make some effort, maybe opening their gate and telling the sales person where the rock should go, but the hard labour is not done by the customer.

And you thought I was making up the rock sellers!

Relating this back to computer programming, the point to the story is this:  The greater the effort the programmer expends, the lesser the amount of effort the customer needs to put in,  to complete the task at hand. Really good software “flows”. It takes almost nothing to use this sort of software and the productive output from it is simply “satisfying” as a customer. Conversely, software that is difficult to use demonstrates a laziness on the behalf of the programmer(s). It is not a joy to use and the output comes with a “relief that the task is over”. Put simply, it is hard work for the customer. In the  fantastic  tale of the rock salesman, it is easy to see that the amount of effort expended in both cases would have been equivalent. It is stretching the rock-selling industry analogy too far to suggest that this perfectly matches the computer software market. But a certain truth remains: No one likes to do hard work if they can get away without it.
I implore you as programmers to put the hard yards in, so that your customers do not need to.

Footpeg damping

The VFR 800 has a distinct “Jekyll and Hyde” personality.  Honda have somewhat of a reputation of producing bland/characterless motorcycles.  I think the current model VFR is their attempt at denying this trait, although it is not the most convincing attempt at doing so.  In my mind, it’s at least 20HP short of being a wild child. 

At low revs everything seems typically Honda.  The ride is vibration free, it’s quiet and well behaved (well apart from a slight fueling glitch from zero throttle)  As the revs rise, so to does the vibration.  By the time the engine switches to use four valves per cylinder (6600RPM) it is well and truly noticeable.

I don’t mind this trait, although after the silky smooth power delivery of my last two Hondas it came as a bit of a surprise!  I have had comments from pillion passengers who found the vibrations felt through the foot-pegs to be excessive.

One of the simplest ways of reducing vibrations is to provide rubber dampeners.  The idea is to provide a rubber insulation between any metal to metal contact where the vibrations can be transferred.  Providing a rubber sleeve that holds the threaded bolt hole insulating it from the sub-frame would be the most effective solution.  This was a bit beyond my modest ambitions.  My solution involved $2 worth of tap washes purchased from the local markets. 

$2!  Tell 'im he's dreamin'

Firstly, I removed the pillion peg bracket from the sub-frame.  It’s held in place by two 8mm Allen key head bolts. 

The small round tap washer sits between the bolt head and the bracket, whilst the flat tap washer sits between the bracket and the frame.

Insert witty caption here...

The additional thickness of the two washers now means less bolt thread is used to secure the pillion peg brackets.  To counter the possibility of the bolts working their way loose, loc-tite has been applied to the bolt threads. 

Yeah, I know - wikipedia says red loctite for motorbikes

The result is noticeably* less vibrations are felt through the foot peg brackets.  There still is some, so don’t expect it to be a “magic bullet” solution. 

* It is noticeable, with a one from one test success rate.  I made this alteration to one foot-peg only and an “uninformed” pillion was able to spot which foot-peg had less vibrations.  Mission accomplished!

Please take a minute to read my disclaimer before replicating this modification.

The need for a fair End User Licence Agreement

There is a directory (or “folder” if you prefer) on my computer called “EULA”. In it is a text file copy of every End User Licence Agreement (EULA) I have “agreed” to for the software installed on the PC. The term “agreed” is in quotes, because I have yet to see an EULA which is presented with a check box labelled “I agree under duress” or “I don’t really agree, but I have no choice”. It is only an agreement in the loosest of meanings.

I feel I must be one of the few consumers of software who actually reads this long legal mumbo-jumbo. Due to the similarity of most EULAs I tend to “skim-read” them these days – more attuned to looking for differences. I suspect some ISVs actually copy their EULA from somewhere else and modify it to suit. (I suppose that EULAs are protected by copyright. I wonder if anyone has ever been sued for copying a EULA?) For ISVs developing software for the Windows platform, this would most likely mean the EULA is based off Microsoft’s.

Out of respect for their closest neighbours (i.e Canadians and Mexicans) Microsoft often include a Spanish and/or French section in their EULA. This raises an issue: What happens if the conditions set out in a foreign language differ from the English version of the EULA? Do these differences apply to me, even though I cannot read what is written? Maybe I didn’t read enough George Orwell, but at least in this case, I trust Microsoft to have done “the right thing” here and not purposefully changed the terms in a foreign language for their own benefit.

EULAs are currently biased in favour of the software producer. The customer pretty much signs away their entire recourse of legal action by simply installing the software. Listed in ten commandment style simplicity (minus thee-s and thou-s), here is a fairly standard EULA:

  1. You are allowed to make one copy of the software for back-up purposes.
  2. You have bought “a licence” to use the software. You have not bought “the software”.
  3. You are not allowed to “reverse engineer” the software.
  4. You are not allowed to perform “benchmark testing” against other similar products without the software producer’s explicit permission.
  5. You acknowledge that the software may not work and will not sue us if it doesn’t.
  6. You acknowledge that the software may not be suited to your purpose.
  7. You acknowledge that this software may cause you to lose money – and you won’t sue us if it does.
  8. If local law means the software producer can’t enforce this “no sue” policy, you can generally only sue them for what the software cost you to purchase.

Where the software comes with “samples” – be they audio sounds, video material, “sample templates” of documents or source code for a compiler, the EULAs tend to take two approaches. Either:

  • You can’t use the samples in your own commercial works.
  • You can use them if you alter them sufficiently for it to be deemed you have “added value” to their original form.

Now some of these points are fair enough. The right to protect your own intellectual property and source of income is understandable. But abdicating all responsibility for the software failing upon the user is a cop out. It promotes an industry that can quite simply be as reckless as it wants with the quality of its wares. An agreement implies some sort of mutual consent. But what a EULA represents is what the customer has to forgo. For the equation to be made fair, the software manufacturer should really indicate what it will do to fulfill their obligation to the user. Until government legislates this, the “fair EULA” is nothing more than a dream of disgruntled software users.

Like most things in life, this is not a “black or white” issue. The correct course of action probably has a distinct shade of grey. I am not sure whether the industry will ever adopt a fair EULA or whether governments will ever act to put one in place. Both parties stand to lose out big time. Abandoning “the reckless” approach will probably mean the end for some small time ISVs and somehow computing will be worse off without their endeavours (regardless of how buggy they may or may not be). But the law should always be there to protect the weak and/or innocent.

I am still contemplating what I feel would constitute a “fair EULA”, so that will have to be a topic for another day.

Quality vs. Quantity.

Earlier, I looked at how quality takes time.  Intelligence and other attributes are key ingredients that stop there being any simple formulaic way of determining quality simply by the time spent producing work.  It stands to reason that the longer you take to produce one unit of work, the less units of work you will be able to achieve in a given time frame.  Quality and quantity fight against each other every day.

It is probably a result of our social conditioning that most people strive to achieve quality in preference to quantity.  Throughout our schooling, accuracy and neatness are rewarded with good marks and cooing comments from proud parents.   As anyone who has read “Zen and the art of motorcycle maintenance” could tell you, defining quality is a difficult thing to do.  As a result, different programmers tend to have different ideas on when code has reached the status of “good code”.  Revisiting this code six months later can be quite a revelation!  More often than not, the opinion on whether the code was “good quality” or not has changed somewhat from the time of its original inception.

Software is a peculiar thing though.  At this early age of the computer industry, it doesn’t reward quality work – it rewards quantity work. Guy Kawasaki’s (in)famous “Don’t worry, be crappy” quote makes a lot of sense, even if the idea has serious limitations.  Earlier I suggested that quality and quantity compete with each other.  This is true – but unless you complete your body of work, the quality may as well be rubbish as no one apart from you will ever see it.

I feel dirty writing this post.  I strive to make my work “high quality”.  Sometimes it even passes the six month rule!  (I hate to say it, but sometimes it doesn’t…)  I always strive to improve my standard of coding.  Coding is only one aspect of a programmer’s  job.  Another aspect revolves around written and verbal communications.  In my mind, communication is probably the most important aspect of most (if not all) jobs.  This is certainly true of computer programming.

Written communications also deal with the quality versus quantity debate.  Blogging is my way of trying to improve in this area.  I am generally happy with the quality of my written work but, it comes at the expense of quantity…  Blogging is my way of “letting go” of the fear of producing sub-standard work.  I don’t think I have made a post yet where I have been 100% happy with the material I have written.  I always wanted more time to correct details, fine-tune sentences, find more references to support my views.  Still, one has to start somewhere!

Biking 101: Decelerating

So far we’ve covered going faster and we’ve covered going around corners.  The last essential ingredient is of course, stopping (or just slowing down).  Motorcycles use two separate hydraulic braking systems which operate independently of each other and (for most cases) affect one wheel each.  The front brake is controlled by a hand-lever on the right hand side whilst the rear wheel is controlled by a pedal activated by the rider’s right foot. 

Ironically, my current motorcycle (a Honda VFR 800) uses a system that sends a differing proportion of the braking force to both wheels when using either the brake lever or pedal.  It does this in an attempt to make braking a safer venture than it may normally be in the hands of an unskilled operator.  The weight transference (towards the front of the motorcycle) that occurs when braking, adversely affects the amount of braking force that can carried out effectively by each wheel.  Some figures suggest in dry conditions as much as 90% of the braking force can be delivered via the front wheel.  The “linked brakes” of the VFR are Honda’s solution to removing this judgement from the rider.

When you look at the contact patch that the front wheel has on the ground, you begin to realise that there is a lot of momentum being shed through a very small area.  Motorcycle training will teach riders that they need to “set up” their braking: transferring weight progressively to the front and thereby compressing the suspension and tyre gently.  As this weight transfer occurs, the tyre is flattened out on the ground, increasing the size of the contact patch.  This in turn allows more force to be applied in a controlled manner. 

There is a theory in physics known as the “Conservation of Energy”.  It states that “energy can neither be created nor destroyed. – It can only be converted from one form to another”.  A motorcycle, or indeed any mass when moving is said to have “kinetic energy”.  The faster it goes, the more kinetic energy it has.  Therefore, stopping a motorcycle reduces the amount of kinetic energy the bike has.  But, because of the “conservation of energy”, we know that this energy hasn’t been lost.  What has happened to it?  Chiefly, it has been converted into heat energy.  – That’s what brakes do, they turn kinetic energy into heat energy.  This heat energy is then dissipated through both the air and the braking components, thus doing its own little bit to help keep the planet warm…

Now the astute amongst you may be thinking along the lines of “it takes a lot of power to accelerate a motorcycle quickly, how can I generate the strength required to stop it as quickly, simply by squeezing the brake lever?”  If this thought has crossed your mind: Well done!  It shows you’ve been paying attention…  The answer lies in the fact that you are utilising a hydraulic brake system.  In cars and some top-end motorcycles featuring ABS systems, the brakes include a mechanical/electrical system to increase the force you can apply to the brakes yourself.  I’m not going to go into how these systems work, rather, I’ll stick to a plain-vanilla style brake set up found on most “conventional” motorcycles.

Hydraulics work on the principal that you can’t compress liquid.  In our case this liquid is brake fluid.  At the lever (or pedal) end, moving the level pushes a piston, which in turn pushes the liquid through the brake line(s).  At the other end of the brake line is the “brake caliper” which contains one or more pistons of its own.  With nowhere else for the liquid to go, these pistons are now displaced too, which pushes the brake pad onto the brake disk.  The disk is attached to the wheel, and so is rotating, whereas the pads and caliper are fixed.  When the disk and pads come into contact, there is friction which converts the kinetic energy into heat energy and “voilà!” you are slowing down!  (Hopefully slowing fast enough to avoid a sudden impact with the scenery…)

This still doesn’t explain how you manage to provide enough force for the brake pads to grip the disk with the necessary bite to stop.  Well, the really cool thing about hydraulics is known as “Hydraulic Multiplication”.  If you change the size of the piston at one end, you can increase the force this piston pushes with.  If this sounds too good to be true, it isn’t…  Although you are gaining more force, the distance you are moving the piston at the other end is reduced.  Fortunately for us, we don’t have to move the brake pads very far to make them grip the disk.  For a more in depth look at how hydraulics work, you may want to look at the brilliant “How stuff works” page.

How do you solve a problem?

What is it about thinking that makes people feel it is hard work? Me, being a “jelly-spined computer programmer” (as a friend once put it), finds manual labour “hard work”. There is something very obviously “hard work”-ish in say… shifting a load of gravel with a shovel and wheel-barrow. It’s not difficult, but it is physically taxing.

Mental exertion is always somewhat harder to explain and yet it is a very fatiguing thing to do. When it comes to solving mental puzzles (which I am using as a loose approximation of programming) there tends to be three ways to deal with the problem:

  1. Ask someone else how to solve it.
  2. Try the first thing you think of and repeat with “the next idea” until you get it right.
  3. Think about it carefully and work out the solution.

I have arranged these ways of solving the problem in order of least to most mental effort required. Sometimes option 1 is the correct one you should use. When you are a “junior” programmer, you can’t always be expected to know answers to problems. With any luck, you will have a mentor. A good mentor will have the skills to guide you to the solution in such a way that you learn the process you need to use in future situations.

Unfortunately, the second option is employed on a far too regular basis. I must admit there are times when I have used this approach myself. It feels like kicking your brain into neutral and see how much momentum you can build up by rolling with no effort on your behalf. Realistically, it’s more like using a hammer to beat the metaphorical square peg into the round hole. When that doesn’t work, you go look for a bigger hammer…

Option number two is so obviously the wrong way! Somehow, that isn’t enough to stop people using this approach. Some developers spend their entire career developing code in this manner. If patience is your trump card when it comes to programming, then maybe you are in the wrong career. It’s definitely an attribute worth having, but that alone just isn’t good enough.

As I mentioned earlier, I will admit that I have taken this “easy path” at times. Almost as certain, is there will be days in the future where I do so as well. So the point to make is:

“We are human. We will try to do things as lazily as possible. Thinking hard is just a requirement of the job. Don’t try and avoid it”.

Memorise it, print it out and stick it on your monitor I don’t care! Just promise me you will reflect on it if you find yourself “coasting along in neutral” when trying to solve a programming puzzle. Then move on to option three and just do it!