Commercial reality

One of my favourite blog writers is Eric Sink.  I find his writing style entertaining and informative.  I do not find Revision Control Systems the most interesting subject matter. I use one, it works, I am happy.  But for Eric, they are his speciality.  After all, he owns a company that writes them.  In a recent article, he discussed speed vs. storage space trade off.  He used a source code file containing a single class, which was 400KB in size for the latest revision as his “guinea-pig” and braced himself for a barrage of comments regarding whether such a file constitutes an example of poor coding.

Certainly, when you take into accounts things such as the single-responsibility principle, it seems unlikely that a single class could grow to such a size.  It would seem that such a class could be a target for a future refactoring exercise.  Refactoring is a worthy cause.  There is no shortage of reading material that carefully constructs solid arguments for why it should be done.  But a more worthy cause is making software sell.  Pet projects and home-hobbies aside, software is of no benefit, if no one is using it. 

Commercial reality dictates that if a new feature will help sell more copies of the software, then adding the feature is what is important.  It is true that the more obfuscated code becomes, the harder it is to expand to incorporate new features.  I have heard of software projects grinding to a halt because adding new features simply became too difficult to accommodate. 

Using commercial pressures as an excuse to write sloppy code is not acceptable.  I have seen examples of code that looks like “the first thing that popped into the developer’s head” has been committed to the Revision Control System.  Often, with very little extra thought (read “time”) a neater, better solution could have been found.  This is where task estimation is important.  In my experience, programmers will use the amount of time allocated, to perform any task.  In all likelihood, they will get to the end of that time-frame and realise they overlooked at least one aspect and then take longer, but that is not the point I am trying to make here! 

If you have allocated “a day” to add a feature, then most often, that is how long it will take to add.  If you had allocated “half a day” for the same feature, then I would wager that the feature would have been added in about that half-day timeframe.  Granted, this is not always the case, but experience has shown me how often this is a surprisingly accurate revelation. 

This stems from the fact that if a programmer knows how long they are expected to take, they will get it working first, then tinker with the code until the time has elapsed.  Some “tinker time” assists in overall code readability.  If you are not prepared to add “code refactoring tasks” to your project plan (regardless of the project methodology you use) then allowing a certain “slackness” in task estimation allows your code a fighting chance of staying relatively neat.

When time pressures arise, neatness and accuracy of code are amongst the early casualties.  Unfortunately, this seems unavoidable and is just the price that is paid to remain profitable.  Whilst I strive to write and maintain neat, manageable, accurate code, I live in the real world and know that regularly revised source code over two years old (Eric’s example was seven years old) will likely be of the “too long / overly complex” variety.  I will not be one to criticise him for that.

What else to do on a day off?

Due to the “Global Financial Crisis”, my work-place has asked all its employees to participate in a “Furlough Program” to reduce revenue spent on wages.  For whatever reason, I had never heard of the term before.  For us, the Furlough program consists of each employee taking five days off (of the employee’s choice) as “unpaid leave”.  This does not affect our various “leave days” or share options programs, just our take home pay.

Monday was my first Furlough day, which I put to good use by going for a ride.  Not only was this good mental therapy for me, but I did my little bit for the economy by spending the money I wasn’t earning in other small communities.

There is something to be said for pleasure-riding on a week day.  The roads are less full of tourists, but more full of road-works and heavy transport. As I chose less popular roads to begin with, I managed to have the true sense of freedom that makes motorcycling such an appealing past time for many riders.

After an extended period of perfect motorcycle riding weather, it was fairly predictable that this day would be the day the weather turned.  Somehow I managed to avoid the rain, although I could not say the same for some of the roads on which I travelled.  The roads varied in quality and motorcycling appeal.  Some I had travelled before, some were “new” to me.  Some were so bumpy, I’m not planning on using them again!

I rode over 400 km (250 miles) on Monday, stopping to take photos along the way.  Unfortunately a couple of the best photo opportunities were lost, due to the look-outs being in the clouds.  Several incidents happened to me along the way, from which I learnt (or at least was reminded) of some important lessons:

  1. Any ride for me will likely consist of at least some motorway/freeway riding.  At one stage I noticed a lounge chair in the emergency stopping lane to the side of the freeway.  A little over 500 metres further down the road, was a ute, also in the stopping lane.  In the back of the ute, was a matching chair…  I am guessing it was more luck than anything else that had seen the first chair end up on the side of the road, not in the middle of a lane.  From my perspective, this had not been a “close call”, but I have been in similar situations that were much closer.  It was a timely reminder to pay attention even in the boring bits of a ride.
  2. I saw several kangaroos in a paddock.  Contrary to popular belief, if you live in an Australian city, you won’t see them hopping down the street.  I didn’t stop to take a photo of them, figuring if I saw another lot I would photograph them.  Of course, I didn’t. The lesson here is, never let a photo opportunity pass!
  3. I rode through the village of Woodenbong.  It doesn’t mean what you might think! :-)

For anyone around the Brisbane region of Queensland, this trip is roughly the one I took (albeit in the opposite direction).  I have put some of the photos of the day on my Flickr page.

Professional Code of Conduct

What stops a bank teller from stealing money from a bank?  These people literally handle lots of cash.  It would seem that handling large amounts of cash can make them blasé about its value.  I am also sure that most bank tellers are ethical people too.  But I doubt that any bank would be happy with just these assurances that money was not going to be stolen by the tellers.  Instead, the processes used by the bank would generate an audit trail, sufficiently detailed that theft by tellers would quickly be discovered. If tellers stealing money is seen as a risk, then the risk is minimised by the processes used.

Not all careers are able to be adequately scrutinised by processes to avoid unethical dealings.  Doctors make the “Declaration of Geneva” – which is the modern version of the “Hippocratic oath”  . This is a statement regarding their ethical treatment of their patients.  Not being a doctor, I am not sure how seriously they take the oath, but, as a patient, I would like to believe that this is a binding principle for them. 

Computer programming strikes me as a career that could do with an “oath”.  Some programs have the ability to harm people, harm their finances or otherwise adversely affect human life.  How seriously do the programmers of such systems take their jobs?  Again, I would like to think that they take that responsibility very seriously.  Would taking an oath make a difference here?  Computer programming requires no formal education, and quite often the “rich and famous” leaders of the industry are mavericks without one.  Without formal qualifications, do you know whether or not the programmer has produced good quality work?  Unfortunately, these two aspects (“education” and “quality work”) are only tenuously linked in the computing field.  I use this point as a defence for my claim that we are still very much in the infancy of the computer industry.  In years to come, I hope the two are more closely aligned.

I believe that taking an appropriate oath could be an important aspect of computer programming in years to come.  Such an oath would require several parts to it:

Part 1: To be honest and ethical in code that is written.
This includes things such as not writing Trojan horses, illicit collection of users’ private data and ensuring that computational output given is truthful and accurate to the best of your ability.

Part 2: To follow industry best practises with respect to producing high-quality code.
Whatever I write here will date the article, but things such as writing unit-tests for code and following an appropriate development methodology are along the lines of what I am referring to.

Part 3: To reduce the severity or likelihood of errors when they are discovered in software.
The whole notion of “Bug prioritisation” is based upon fixing the most serious ones first, and leaving more obscure bugs with less impact until later.  This point in an oath is to ensure that bugs are not left behind for the wrong reasons.  (e.g. Because there were “more fun” bits to write)

Part 4: To periodically update technical skills through on-going education.
The intent here is to ensure that code written is done on the strongest and most relevant platform.  There is a balance required here.  On one side the aim is not to produce code that “rots” because it is old and unmaintainable and on the other side, trying to avoid re-writing everything in the latest trendy language.

I suspect that such an oath needs to be complied with “in the spirit that it is written”.  Programmers, by their very nature are constrained by binary logic.  As such, I could imagine an extreme-nerdy glee some programmers would have in deconstructing such an oath.  In this sense, “deconstructing” is exactly the right term to use:  Applying a warped perspective on a literal interpretation of an oath would not be constructive for our industry.  You have two choices when constructing something like an oath.  You can write it in straightforward simple terms and use the phrase “in the spirit that it is written”, or you can write it so precisely that there is no room for interpretation.  Precise wording undermines the effectiveness of a document by writing it in “legal-ese”.  No-one likes reading such a document and people often hide behind the excuse that they didn’t understand such a document.

I have never made the “Declaration of Geneva”, but I do understand what it means, and I expect any doctor that treats me to have made it, or a similar oath.  It could have been written with legal precision, but for the benefit of doctors and patients alike, it was not.  Similarly, if the software industry was bound by an oath or affirmation, then it would need to be one that could be understood by both the programmers and the end-users.

Do end-users care about ethical programmers?  I somehow doubt that it is as important to them as an ethical medical practitioner is, but they probably do expect that the software they use has been written by diligent programmers.  If you were to point out that private information on their computer may be accessible by a rogue program, then I expect they would care about the programmers being ethical as well!  Due to the all-pervasive nature of software in western society, you could wonder why the general-public has not started to care more, about such matters. With “public education”, you could probably raise the level of concern, but such an approach does seem to be way over the top.  It is probably just as effective for those of us in the industry to care about such matters.