The ups and downs of software development.

[ Note for readers – none of this is a comment on my current employer, or fellow employees, who I think are fab! ]

I wonder if any of you have ever bought a skeleton watch? For people that like gadgets, they’re quite cool: you can wind the watch up, see all the moving parts whirring back and forth, and for a brief moment think wow, that’s really neat.

The joy of creating: The best parts of software development are like that, especially when you’re developing something new: you find a neat way of solving the problem, maybe some cool algorithm, or maybe some way of putting existing software components together, and when you’ve put the whole thing together, it whirrs into action like some finely crafted watch, and if your debugging skills are good, you can see all the various parts moving back and forth doing what they’re meant to do.

If you did a computer science degree, that’s probably the bit that you thought was fun, and kept you interested.

Conversely, there are some parts of software development that I think most people find a pain. I find them a pain, and not particularly fun. Maybe there are some guys out there that like them. Specifically: build systems and test frameworks.

When you initially develop them, there is of course the coolness factor of getting everything up and running, however after that it gets less pleasant, for a couple of reasons:

Scripting: Scripting can be a pain in the backside: You’re having to tie together disparate software systems, with different ways of working, and may have to know several different scripting languages with different conventions to get everything to work.

Test frameworks: In a test framework, you may not be writing just an algorithm, but instead are having to take some set of commands and pipe them through various frameworks to execute remotely on various machines, and then collate the results. If you built the test system, then it’s OK, but if you’re changing it because you’ve added functionality elsewhere, then you need to learn a load of plumbing that makes no sense at all, just to add some extra test for some new functionality.

Test compatibility and versioning control. Is it me, or is getting test frameworks to run reliably a pain? Simple test frameworks are fine, but as they grow bigger and bigger, the number of things you need to control for increases exponentially e.g.:

  • We need to check our software works. All the different deployments and variants.
  • On various different OS builds. All of which need to be taken into account…
  • … and might be hotfixed and patched or not.
  • Which need to be installed and deployed in an automated manner….
  • … requiring more framework to install / deploy, across multiple OS’es.

After a little while, the whole thing can turn out to be positively labyrynthine. I guess that why people hire hordes of test engineers.

Third party software. Third party software can be a pain. It’s not that there’s anything wrong with it, per-se. It’s just that it’s third party stuff. And hence you don’t have the source / don’t know how it works. Even more annoying is when it auto-upgrades itself, and the first you know is when your tests break for no apparent reason.

Almost all of the most difficult and confusing bug hunts I have been on have involved bugs in third party software. Typically what happens is that the flow of control disappears into the complete black lagoon of some third party component, and then never reappears for some reason that is not immediately apparent. You then have to fight a huge battle to get some other organisation to find and fix their bug.

So, there you have it. The ups and downs of software development.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *