Tag Archives: computerscience

My delicious.com bookmarks for April 28th through May 3rd

Professionalism

A few years ago I was subcontracted to one of the large consultancies. I was taking over from someone who was, supposedly, quite senior and the task at hand, I was told, was very hard. I should take copious notes as she wouldn’t necessarily be around afterwards to help me. Making a mistake or missing out any one step could be disastrous to the whole process. If I did everything properly each new installation would take about a week.

This turned out not to be entirely correct.

After sitting through over a week of her spelling out each and every step in excruciating detail — much of which I don’t think she really understood — I spent three days writing a shell script to automate over ninety percent of the process. I don’t mean a quick, shoddy hack either. I spent the time to gold-plate it. It was a work of art. I set it up so that you only needed to copy the one file and allowed for the user forgetting to switch FTP into binary mode1.

In the end, my three days of work reduced the week long process to about an hour, and most of that was waiting for the file to transfer over the network.

I say all this not to show off. I think any engineer would have thought to do this. I note the extra refinements so you realise that it could have been done in much less than three days had I not wanted to practice my Unix-fu.

Result: I was heavily criticised for not following the proscribed process. I pointed out that my new scheme was quicker, easier and less error-prone. They countered that I had been unprofessional to begin a “development project without authorisation.”

What does “professionalism” mean to you?

Sometimes, I think, it’s used as an excuse to do or not do something in a particular way. “That’s not professional” is kind of a cop-out. In this case I can only assume that the real reason was that they wanted to bill a week of my time to the client for each installation. Of course they couldn’t say that.

Since then, every time I hear the phrase “that’s not professional” I try to drill down and find the real, underlying reason. I’m hoping that one of these days I won’t be disappointed with what I find. It hasn’t happened yet.

  1. I basically appended a tar’d and uuencoded file to the end of the shell script which it knew how to extract and decode. []

The W Effect

This is probably the meanest article title I’ve ever written, as the “W” refers to a person, someone that I used to work with1. The critical phrase went something like this:

“How hard can it be? It’s only a button!”

Those two, tiny sentences hide a lot. Let me explain.

I’m mainly technical. I have been in the industry for over ten years now, did a computer science degree and spent many hours when I should have been revising for my German GCSE programming my Sinclair Spectrum. This means that when someone says “It’s only a button” I instinctively cringe. I may not know the details but I’ve seen enough “simple” buttons with days worth of work behind them that I’ve learned to be cautious.

Of course, not only technical skills are required for most modern applications. Even a relatively small iPhone utility, such as Yummy, needed some time in front of Adobe Illustrator for the icon. Needless to say, that time wasn’t mine.

I am a keen photographer and I have read The Non-Designer’s Design Book but when it comes to art and design I leave the implementation to other people.

Naturally I have opinions. I may, as a “customer,” have constraints. It has to be a particular size or colour, the shape must evoke a certain feeling or imagery. I probably even have a budget. I instinctively like or dislike designs.

But what I don’t profess to know is the design process or how long it should take, and that’s the problem with the “how hard can it be” quote from above.

“W” was from another discipline, couldn’t imagine what might be hard technically and made a commitment to the client based on that hunch. Unfortunately while their part would only take a few hours, it turned out that there were several weeks of technical work to make that button operate.

Of course I don’t want to come down too hard on “W,” as this is both a fairly extreme case and something that we all do to some extent. Things that we don’t understand almost always seem easier than they are in reality. The trick, insofar as there is one, is acknowledge that it does happen and consult with someone who does understand it before making commitments.

  1. In fact I had a number of choices, and that’s the point. However this, as you’ll see, is an extreme case and is the first I remember. []

My del.icio.us bookmarks for July 15th through July 16th

  • Ars Book Review: "Patent Failure" – Interesting book review about the effect of patents on an industry. Apparently cost more money than they make in anything but chemical and pharmaceuticals.
  • Lucky to be a Programmer – I don't program as much as I used to but this explains why I love to when I get the chance.
  • WordPress 2.6 – Usual drill. I've upgraded to the latest version of WordPress, the underlying software of ZX81.org.uk. If you see anything wrong please let me know!
  • 20 Amazing Facts About  Voting in the USA – Still in any doubt that computerised voting machines are a bad idea for free and fair elections?

My del.icio.us bookmarks for February 26th through February 27th

Random Changes

When it first happened I was irritated. A few days later I was irritated that I was still irritated. It didn’t make any sense, it wasn’t a big thing and it shouldn’t have bugged me at all, much less still a few days later.

After a while I realised that my irritation was more rational than I initially thought so I started to write them down as a way of structuring them. And here they are.

So what went wrong? Well, first we’ll need a little background, although I’m sure you will appreciate that I can’t go into all the details.

My day-job involves writing code, enhancing and fixing a sprawling, ten year old application and this day was no different. For the previous few weeks I had been developing a small improvement to one of the reports. I had satisfied the requirements by modifying an existing report, including the occasional conditional where appropriate. Not my best piece of work by any means but I had spent some time on it, had some of myself invested in it in some small way. I checked in the change to our source control system and moved on to other things. A short while later someone reported a bug against it. Not an unusual occurrence with the very vague requirements I was working to and the general standard of my code, however one thing did surprise me — I was sure that I’d tested for and added code for that particular scenario.

It turns out that I was right. The problem was that somebody had completely rewritten my code. The new implementation was very elegant, more aesthetically pleasing that my hack. Remember that I never believed it was the best code I’ve ever written, so if the code actually worked correctly I wouldn’t have cared. But it didn’t. It had fixed one small problem with my code but had introduced at least one new problem, one that was far more difficult to fix than the problem it was trying to solve.

There’s a technical, software engineering, side to this and there’s the effect is had on me. If I was being grand I suppose I’d call that the psychological side. I would like to talk about both of these aspects.

First, let’s discuss the technical side.

When modifying a large, established code base I have always believed that the correct approach is to make as few, targeted changes as possible to get the job done. The problem with a non-trivial code-base is that embedded inside it is dozens of small tweaks that you would never think of making but the software has accumulated in the School of Hard-Knocks. Real life has a tendency to throw up scenarios that, theoretically, are not possible. No matter how good you are at writing code these things happen.

This changed violated this principle. That alone annoyed me.

Of course the counter-argument is that we should be continually refactoring the code. This is the Extreme Programming approach and is one that I have talked about previously. I do have some sympathy for this argument, except that in this case it t really apply. While the new code was undoubtedly cleverer than the code it replaced, it’s difficult to say that it’s better. When you’re writing code that may well be around in a number of years time it needs to be understandable. Writing clever code can be a disadvantage. A few extra lines of code, if they’re simple and easily understood, are often a good thing. It’s easy to forget that it’s not just the computer that needs to read the code.

Naturally the reason that people do this is that it’s much easier than reading and understanding the code, and this is probably more true in the language that we use than most (it’s a proprietary one that you won’t have heard of). So the author of the new code will have saved himself a few hours of work but by creating a clever yet difficult to understand alternative he has generated more work and confusion for legions of support analysts in the future. This costs the company time and money, although the author of the new code appears to be a super-hero as he checked in hundreds of lines of new code compared with my much smaller number.

The psychological aspects are less easy to define but in many ways are more important. Unfortunately I would concede that I am less capable of discussing them in anything like scientific manner. It’s not going to stop me trying, however!

The question at the centre of is all is: why do certain kinds of people like writing software? It’s a painstaking and fiddly task which requires unheard-of precision and attention to detail. Why would anyone want to do that?

I’m sure there are as many answers as there are programmers, but a common root cause would be the simple challenge of solving a complicated problem. There’s a certain satisfaction in completing something tricky and, even if you recognise that there are other ways of doing something, there’s usually a certain pride in the way you did it. It may not be the best, but it’s your way.

So really it’s one of those seven deadly sins: pride.

Also there is a large motivational aspect to it. At this point in the project I was already lacking my usual level of enthusiasm for a number of reasons that I won’t get into here. What kind of effect is someone unnecessarily rewriting my code going to have on me at this low ebb? Why would I want to write more code and make more fixes now? Surely it’s just going to get rewritten.

Note that I didn’t say “criticised.” I think an important aspect to get across here is that I am not above criticism. If the code had been improved, if the new author had discussed the options with me first and we’d agreed a way forward, I doubt that I would be writing this piece here and now.

Now there may well be some degree of bitterness here, however I think ll agree that there are both technical and human factors reasons why things should have been different.