Entries for label: bugs

Found 1 entry.

Not Doing Smilies

Sometimes you wonder how you got into a particular situation. Sometimes you got yourself there, other times, you're where you are because of decisions other people made before you turned up.

It turns out I was in a situation today who's root cause was due to the people before me. It was only when I booked time against the project did I think of this blog entry. I booked some of the time spent with the comment:

Not Doing Smilies

At the time I wrote it I was being completely serious since I had to stop a particular website from converting those :-) smilies into images. Yes, it was that weird.

It was only afterwards, when a colleague of mine told me it was the "best comment ever", that I realised I myself was not doing my usual smilies.

Why wasn't I smiling? You see, we were in a situation whereby we were repaying 'Technical Debt'. I know this because Stephen gave us a great talk on it a few months ago. I guess I always knew what it was since I've had to clean up other people's messes before but his talk really rammed it home how many multiple times we actually have to pay it back. Once in technical debt, you spend continuously more trying to get out of it. It's almost like it spirals out of control and in some of those cases, many people's fixes are just papering over the cracks (another colleague's comment today).

The General Problem

So there we were, trying to figure out what the hell was going on with something which had about the same tensile strength as a piece of chewing gum. It was inherently brittle and it just pained me to wonder why and how it was originally set up as it was.

As it turns out, the problem above wasn't the overall problem but was at the end of a long list of problems. The root cause problem however is in the way this particular part of the project was set up. It was done in a hurry in the first place so that the client could get something up and going 'as fast as possible'. I'm guessing this is what the client wanted.

If you're anything like me, then as soon as the client says 'as soon as you can', 'by tomorrow' or 'ASAP' then you know you're onto a losing situation already. Even if you argue, refuse or try to clarify why this isn't a good idea, you're usually stared back at with a I'm the client and I'm paying for it, so you just do it' look. By then, no matter what good reasons you give, it then becomes a powerplay in which you're bound to be on the losing side - for reasons other than technical ones.

Another negative in all of this is the fact that the client - in a fair majority of cases - may actually be an internal person who is working alongside you. This person might be someone in a higher position, a manager or maybe just someone with the loudest voice. The end result is the same; you're left to do a sub-standard piece of work against your wishes. And no matter what you argue, how you put it and explain the reasons why this decision is a bad mistake, you're still forced to do it.

This doesn't sound good does it?

And you know that ultimately, it's going to be you who has to clean up the mess afterwards. Let's face it, you're the person most intimately involved in the code and therefore you just know why it's going to fail. It's so clear to you yet still, there is nothing you can do about it. Yet all these other people who don't know the code as well as you force you to do it. My brain hurts thinking about how this can ever be a good thing.

History Repeats Itself

I don't blame the people before me for what happened today since I wasn't there, I wasn't in the situation they were when those decisions were being made but I can only imagine that they were left with no choice since they had to get this thing going 'ASAP'. Granted, I might have done something different in their situation but that solution might not have been much better than the one we were left with today.

So what was initially designed as something to get 'up and going very quickly', soon descended into a botch job that no-one liked, no-one took ownership of (because it was a botch job) and therefore that particular subsystem was left to rot and die unloved and in a state of disrepair. Eventually, it all came to a head when the brittleness of the solution came back to bite us - all of us - on the sensitive behind! No-one really likes being bitten on the bum no matter what they say!

Before we move on, let me just re-iterate one part of that previous paragraph, and I'm going to put it in a quote so that if you skimmed over it just prior to this paragraph, you'll definitely see it this time:

... no-one took ownership of [it] (because it was a botch job)

This is one of the most important things in software and probably in lots of other walks of life too. If something is so bad that no-one wants to look after it, then you're on to a losing situation already. If a particular job was done correctly (because they were given the correct amount of time and support) then it would be easier to maintain and for people to actually take ownership of it. That way, it wouldn't rot in hell like all those other bad pieces of software out there do.

This in itself is bad, but here is something even worse ... prepare yourself now ... in our industry, we've seen this happen a thousand times before, no-one has ever learnt their lessons from this and yet we'll see it again and again and again in the future!

That's just sad. Really sad.

All I can do at this moment is slap my forehead and shout "Craptastic Batman"!

Who Pays to Fix Things Up

At first glance, it turns out that the people who have to pay to fix the whole mess up is us. The client certainly won't be billed for this situation I'm sure. So it turns out we're paying for it. In fact, we're paying for it in many more ways that one:

  1. our time spent to fix it up
  2. our developer's energy since it is quite a stressful situation
  3. our developer's non-work time, since it had time spent on it over the weekend
  4. our enthusiasm wanes for something that wasn't already initially liked
  5. our time (and therefore money) to re-implement it properly, in a good way and without duct tape

In fact, it's not just us paying for it. The client also has to pay for it, though not in a direct monetry sense:

  1. people using that part of the system couldn't use it for a while
  2. some client's time was spent liasing with us at every step of the way
  3. other areas of the system were slower or substandard and therefore affecting even more people using it

Finally - and this is the worst of all - the visitors to the website also had to 'pay' ... since they received a substandard experience because of the problems. Either that costs the visitor a little bit of time or it may result in their eventual rejection of the site and never to return.

Shortlist for Clients and Managers to help 'Make Things Better' (TM)

To finish off on a high point, here's my quick checklist for making things work out better from the start. This is not a technical list but a list which can be used to just generally make things suck less:

  • when the developer says something will take 32 hours, don't say "do it in 16" - they know the code better than you, believe that if nothing else
  • if you have an idea for a new feature, ask how long it will take first; don't say "we want it by Friday" - if you haven't had this feature up until this point, then you can do without it for another short while until it is done properly
  • if you desparately need a feature for a particular date, please think of it in advance or at least don't expect other things to keep on trucking. Prioritising is the key and that'll really help things
  • kthxbai

See, I told you it was a quick checklist. Now go and mull it over and let me know what you think.

:-)

Labels: website, geek, planet-geek, developer, planet-catalyst, bugs

Inserted: 2008-10-28 19:51 (1 year, 10 months ago)