Thursday 14 February 2013

Code Killers

When I were a lad (imagine the old Hovis ad music playing in the background and with the voices of the Monty Python team playing oneupmanship as Northerners, that should help - history ed) it was really time consuming to change code, we are talking about programming/coding computers here for any neophytes wondering what code is.

We are talking the late 70's and early 80's when Unix (tm) was starting to make inroads into (UK) companies and 'C' was the new kid on the block (great name for a boy band - music ed)

Editors (newspaper editors? - ed), that is applications that you use to compose/write/hack code with, were fairly basic. Vi and Emacs ruled the roost in most of the Unix (tm) world and Eclipse et al weren't even a speck on the blue event horizon.

To change the name of a single function or alter its parameters was not at all easy and  generally involved the use of a plethora (great word - literary ed) of command line tools like find, grep and sed to track down all the places where the function was found to be lurking and then manually alter them. Expertise with sed  and general shell commands meant you could write scripts to facilitate this process to a certain degree, but not completely by any means.

This was a time of small monitors (actually large steam driven monstrosities with green or orange characters vying with each other to be the one true colour). It was a time when you used to print out code, tens of thousands of lines on huge 132 column band printers hidden away in computer rooms which were serviced by an interesting band of folks called computer operators.

Moving on to a new project involved reading through hundreds of printed pages, real physical pages, fan-folded with holes punched in them, pages that had to be put into folders to manage them or you'd be overwhelmed with wave upon wave of paper on your desk; if the pages were not controlled in this manner you might find them early one morning playing slinky between your desktop and the floor. Generally this slinky'ing would occur Friday afternoons post lunchtime for reasons that escape me (are you sure about that - truthfulness ed)

Actual hand written edits would be applied to the printouts to save printing out dozens of pages of brand new listings. Those were the days when you had to learn to write with pencil and paper. These were the days when talk of the paperless office was summarily dismissed as foolish nonsense and small groups of developers would gather in dark corners and whisper about what the future might hold.

Aye, when I were a lad... (Whoa there Tex! What happened to the 'Code Killers' you put as the post title? - ed).

What I was trying to do, I will have you know, was set the scene of yesteryear (you were doing a great job - motivational ed). So, assuming you are still with me; programmers were cautious about changing function names, parameters etc. as they resultant edits could be incredibly time consuming and it was hell if it was the compiler that found you out, or heaven forbid code failed at run-time. So we used to think and think hard about the name of a function and its parameters as the consequence of getting it wrong would involve a lot of mind-numbing editing.

It is not like that today, I can tell you. We have multiple (well in the best of companies - technology ed) enormous, thin (size 0 - fashion ed), elegant, sexy, svelte monitors, with large swathes of multi-coloured (swap shop anyone - historical tv ed) real estate and incredibly powerful editors where you can change the name of a function/method with such consumate (very proud of your use of interesting words - literary ed) ease, in fact dozens of times before you finish even one cup of coffee. In fact I can't remember the time I last printed out any code at all. (David pauses to think ... and no he cannot remember - ed)

My point, what is my point? It is that today, any fool can join a team and take over the code; code that you have lovingly crafted, code that you have brought up to be fine, upstanding, useful, elegant, smart and sophisticated code; code to make you proud and stand tall among the great coders of the world; and ruin it in moments.

Why would people do this, because they can and they know best!

In most professions, and I do count writing software as a  profession (though not the oldest - viz advisory ed), you need to pass tests, get a licence, be mentored to prove you understand what you are doing and practice, practice, practice possibly for years before you are allowed to do anything real. For instance:
  • cutting up people (surgeons),
  • prescribing medicines (doctors), 
  • flying airplanes (pilots)
  • and so forth and so on... 
But with writing code, anyone can do it, even with the most basic of experience, like three years at University. We all know that after that three years studying at some glamorous campus, where the only admiring glances you get are from the other guys/gals in your class when you show off your latest piece of sleek computing kit; or maybe when you show them how you have used the newest language to hit the streets to perform something just simply astounding. 

You just know that you are ("King of the world" again? - ed) the bees knees, top dog, undoubtedly one of the highest of the highest percentile of programmers (top 1%, like all of the rest of us), that you know absolutely everything about everything and can't wait to get out there and prove to the world how good you really. You are chomping at the bit to put those old timers down as the dribbling fools that they are.

Pause, for thought, that wasn't the rant I was looking for, so moving along...and getting back on track...

What do I want? What I want is for new programmers to think just a little, a tad, a smidgeon (a little bit), a moment, to ponder, to take a look at the existing code, to see its shape, see the way it flows, sense its grand sweeping vista, maybe and I hesitate to use this word, to understand it, before they lay into and cause wholesale slaughter of that so, so innocent code. 

Remember that this code has been through a painful gestation period, where the programmers have built (if you could get the word "construct" in here somewhere I would be happy  - literary ed) a potentially beautiful construct. These programmers will have spent hundreds, maybe thousands of hours building this edifice (top marks for that - literary ed), they will have used every pattern in the book. They will have fought, what appears in retrospect, to be battle after battle with business analysts, project managers, testers (of all flavours) and even (shock horror) end users and eventually worn them down to accepting that what they are asking for is simply not possible, but then having to done it anyway because they don't call the shots.

Sigh. Talk about waxing lyrical (thought we'd lost you there at one point - safety ed)

The point that I am trying to make, is that one person can, with a modern editor, destroy a piece of work in a number of short thoughtless bloody moments. Has this happened to you? It has happened to me, and what is worse, on more than one occasion (you are doing a great job of holding it together - dr ed) 

How to fix this? What I am proposing is that programmers, or coders if you prefer, who do this kind of wholesale slaughter should be taken before the General Programming Council (GPC). These violators  need to be forced to justify their actions before this grand old body. The GPC contains the great and good of the coding world, as well as cohorts of your coding peers. The suspect (oops), programmer, should, suffer consequences if and only if, they fail to convince this hallowed assembly of the rightfulness of their changes. The programmer, when found guilty, should then be struck off, not only off the General Register of Programming Practitioners (GRoPP), but and I hesitate to suggest it, also have their licence to code revoked! This may seem like some to be harsh, but we all know that this is very  necessary.

So to ensure that this doesn't happen to you, I would humbly suggest, ask, prompt, even cajole you to take some time to look at the existing code before you change it. Maybe even talk to the people who wrote it (though getting coders to talk can sometimes be a bit of a chore in its own right, as many lack social skills), if you can find them. Find out why they did what they did (for Maria - music ed; thinking about it I did have a project manager called Maria once - ed), as they didn't do it to wind you up, they did it for a good reason, it made sense at the time! These coders would, given the chance, do it differently if they had to do it again. You must remember hindsight is so, so much easier than foresight. So to sum and and bring the title back into focus.

The editor in front of you is a 'code killer', so be very, very careful how you use it.

Afterthought

This post was started around 4 am in the morning (UK time), as sometimes, when you wake up full of pressing ideas, it is wise to write them down somewhere. I used the Blogger app on my mobile (until it ran out of juice, beeped loudly and woke Bridget up; can't say she was best pleased about that. What is worse is that I then put mobile on to charge next to the bed, and hours later when it was fully charged beeped loudly and woke her again! Talk about being in the dog house.), then I finished this post off later on the laptop. Funny that the Blogger app on the phone is still not doing the white space correctly. I really must investigate and find that configuration option. No not really, not that urgent

Minor updates

Couple of minor typographical errors sorted, 'like social skills' vs 'lack social skills' - but I might argue that they would 'like social skills' but that is not what I meant.

BTW I have had some strong feedback from a major authority that I was not in the doghouse this morning. Phew!

No comments:

Post a Comment