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.

Open source software. Too much of a giveaway?

The very quickest of quick notes on open source software. I can’t help but feel that software developers, as a whole, have somewhat given away too much. A browse of github / sourceforce and the like would indicate that for just about every sort of software that the end consumer would be happy to pay good money for, there is a version or competing product which is available in open source form for free.

Although the reasons for individual projects being open sourced differ, there seem to be several categories that are of note:

Category 1, part, or ex-commercial software:

Companies have been unable to make a profit or viable product from a software project, and upon winding the project down, have decided to open-source the software.

Alternatively, the company has gone bust, but the developers have been loath to throw away many man years of work, and have hence open sourced it.

Or, the company has a product of sorts, but has not been able to obtain or hold on to the manpower or expertise to keep it viable, so in the hope of spurring development (often towards third party add-ons, improvements), they decide to open-source it.

Category 2. Convenience and altruism.

Truth be told, most projects are too small for just one guy, and quite often, collaborative projects need many people, widely distributed across the globe. However, in many cases, these people do not fall under the easy case of being employed by the same company, or, the project is simply a group of like minded people, who have a common goal and want to work on the project in their spare time. In such cases an open source development model seems ideal.

So what’s the downside?

The downside is that there are only so many new things under the sun.

The open source model is based on the premise that freely available software ecosystems stimulate further development by lowering barriers to entry. This is certainly the case. It’s also true that open source software is often (but not always) of relatively high quality, there being more eyes to examine, understand, and fix the code.

The problem is that I and many other software developers take the point of view that given years of learning, training and career progression, we’d like to be able to make money out of our skillset. Open source software makes it increasingly difficult to do that – if something has been done well, and it’s been open sourced, and exists in a free distribution, then savvy consumers are less likely to pay money for a similar product, if they can get something good enough for their needs for free.

Note the phrase there: “good enough for their needs”. For example: If I want an office suite, I could buy a copy of MS office, or I could use LibreOffice (ex StarOffice) which is free.

Truth be told, MS Office is probably the better product: It’s newer, has more features, and is kept up to date with the very lastest GUI toolkits and OS releases. However, I probably only use about 10% of the features in the product, and all of the features I use are also in LibreOffice, hence I use the latter.

The case now comes that if I am Joe software developer, and I want to make money by writing and developing an office suite, there is no way that I’m going to be able to make any money out of it.

So, here’s the question. Have OSS developers gone and cheapened their trade by writing so much free software?