On Technology Choices

latest-small-64There’s a nasty habit in software to choose technology based on what’s the latest thing to arrive. You can see this in tools (e.g. GIT) or languages (e.g. Ruby) or libraries (e.g. AngularJS). The thought is because a technology choice is new, it’ll be better than the one before it – and in all honesty, a lot of the time this is true.

However, avoid being dependent or biased based on the relative age of a technology when making choices. Pick the right tool for the job is the rule we’d all like to live by, but be aware that it’s in a technologist nature to pick the newest shiniest toy in all cases.

When a new technology is born it’s sometimes to fix a perceived problem in existing solutions. Sometimes this is a great thing. Take GIT for instance, SVN was hurting distributed teams, merging and branching were painful and slowly but surely developer’s approaches were being limited by the tooling they were using. So we all started moving to GIT.


Does a new technology come without penalty? The answer is flatly NO. There is re-training, the new gotchas that come from a new model and the overall cost of moving from one to the other. Think for a minute, were the problems that the new technology was solving actually problems you were encountering? Were you using SVN with distributed teams? Were you using lots of branches and lots of merging?

The point isn’t that picking a new technology is bad, rather than yet again you need to think for yourself.

  • Is it going to help?
  • Is the older technology going to be updated to fix the problems you’re experiencing in a lower cost time period than the one you’re moving to?
  • Are you just storing up a problem for later?

For instance, I’ve just gone back to Flash/Flex because it solves a need for me. Yes, it’s old technology (relatively) but it’s the best tool for what I’m trying to achieve today. Is it bad because it’s old? No. In fact, it’s been exercised so heavily due to it’s age it flips round and becomes a good choice.

Know why you’re choosing the technologies you’re choosing, if the primary reason is that it’s new (and be honest with yourself) then think again. Alternatively if you have infinite time and people knock yourself, hell we all like to play with new toys!

On Naming

latest-small-64So, why “Kev on Software”? As you can imagine the first bit is easy – my name is Kevin, but why “on Software”. Back way back when there was a blog called “Joel on Software” – by Joel Spolsky. He wrote passionately about what made good and bad software, and where he saw the pitfalls. It’s been many years since I’ve been regular reader but most of his opinion pieces stick with me, even if I didn’t agree. I think thats what his blog taught me most, that thinking for yourself is the key to everything, especially in software. Guidelines, methodologies, courses and approaches are all great, but if you stop thinking for yourself you’ve already set up to fail.

As I was thinking about the name, it occurred to me I care about naming in software more generally. When you’re building code, or documentation or even marketing material the names you use mean everything. The right name makes something instantly memorable, the wrong name can be useless or in the worst case mislead. Consider the following:

I have an object that contains a set of Book objects. If thats it’s only description in your system, then BookList makes a perfectly good name. However, where in your system is a collection of books meaning really only a collection of books?

Is it a Shelf? Is it a Catalog? Is it a Library? Does it really matter? Well yes, it can do and this is where the thinking for yourself bit comes in.

  • Who is reading this code, is it only ever you or are there other people maintaining it?
  • Does the context mean it doesn’t have all the properties of a list, e.g. can you add and remove items? (Yes, you could for for ReadOnlyBookList, but now its getting silly)
  • How long is this code going to last, does the design of the interface to this class really matter at this stage?

Reading the above you’re probably saying, but you’re not arguing either way, and that’s correct. Think for yourself!

If the code isn’t going to last more than a day, who cares what it’s called? Why waste perfectly good cycles on a name that will disappear shortly. That said, are you sure it’s only going to last that long – and are you willing to put the time into change it (and it’s ripples across the code base) if the code does end up lasting longer?

Is the addition of methods in the interface for a BookList going to imply something outside of the context of the class? Is removing items from the list possible in the context, and if not, is having the method going to mislead and confuse?

Are you the only one who is ever going to maintain this code? In which case does it really matter given you’re going to keep the whole thing in your head anyway? Are you sure?

The above questions, and many others, sound like a lot of thinking to do as you’re endeavouring to code away as quickly as possible. However, once you’re thinking about it every day as you code, it’s split second decision making – that you don’t need to cross check with every guy around you and his dog.

You think, then act. If a discussion does arise later then you know why you made the decision and if things have changed you refactor.


Why now?

latest-small-64So here we are, another day, another new blog – but this time its personal. I’ve been developing software a while, 20 odd years commercially and if you count all the years I spent as a kid we’re talking 30 years.

I’ve watched software turn from something a few people knew how to do, to being a skill, to being a formal method, to being a discipline in its own right and finally being an integral part of every enterprise business everywhere. It’s been fun and I thought until recently I didn’t really mind how it was done as long as I still had a job.

Then it happened, I became a manager, I watched as teams of people I looked after did things different ways, and believed and subscribed to different methods than I did. No, it didn’t scare me, its positive right? Well yes it is, but then you start seeing the time thats so important to your business disappearing down rat holes of belief and opinion. Remember, when you’re writing software it shouldn’t ever be just for “the sake of it” or worse still as an “engineering exercise”. Commercial software serves the business it’s written for, like it or not, as a software developer you’re a cog in a large machine thats trying to make money.

The reason for this blog? I posted this on facebook today and got a score of replies about software. I didn’t realise but I actually care, not sure when it happened, but I do and I’ve done this stuff, a lot. This blog documents my opinions and hopes to drive discussion if not agreement.