Software Isn’t for Life

Software is a form of product that will deteriorate and expire with time. With this in mind, how easy would it be for you to switch software from your preferred tools set to a new one?

I try and not be too dependent on the software that I use on a daily basis. I do have a favourite set of tools that I use but I’m always conscious of the fact that whatever I’m using might not be around tomorrow.

Take for instance my to do list. I’ve been using Todoist for some time now. What would happen if Todoist stopped trading next month? Or even next week? Barring a natural disaster, I’m pretty confident that most services, including Todoist, will allow a small window of time for you to transfer your data across to another application of your choice before that company closes down.

The good thing about software as a product is that there’s plenty of it. We’re spoiled for choice when it comes to software and with the now common place app stores from various technology companies, there’s an app store for most major hardware platforms.

What happens though when software becomes a dependency?

I’ve heard many people say that their preferred software product for a particular task is ‘X’ and that they just couldn’t do their job without it. Perhaps that’s true if you’re in a specialist job working on the next wave of new technology and innovation, but for most of us this just shouldn’t be the case. We should not be dependent on just one particular brand of software to get the job done. If you’re so dependent on one particular software product then I’d say that you’re narrowing your choices down too much.

The text editor is my daily tool for writing and cutting code. My preferred text editor is Sublime Text, but for any reason that Sublime Text was to stop being supported or even cease to exist, then what’s my options?

We’ll I’ve played with Vim enough over the years to make the jump to that, and there’s a number of other text editors that I could pick up like Chocolat that would do the job just fine. Yes, I may have invested a considerable amount of time getting to know the shortcuts keys of Sublime Text but if I had to then I would comfortable picking up something else. We should always have options to fall back on for the selected tools that we use on a daily basis. In most cases this second set of software might be products we’ve tried in the past or something that we previously have experience with.

Investing time and effort into a particular software product is fine if it’s something that you will use on a daily basis for about 8 hours a day, but anything else is simply a product or tool that could be replaced with alternatives already on the market or a custom made option if needed. Software isn’t for life, it’s simply a temporary means to an end until we find something better that works for us. With this in mind, are you to dependent on the software you use?

Fixie Friday - Cinelli Vigorelli Red Hook Crit Limited Edition

The Limits of Automation

The other day I experienced the limits of what automation can deliver and realized that not all tasks are best done in an automated fashion. Some tasks need that manual touch to get done properly.

At the start of the I got back on the writing bandwagon and published another of my muddled thoughts a couple of days ago. Being a lazy guy, I have’s Broadcast setup that takes my daily posts from the RSS feed and publishes them to and to my email subscribers. One of the reasons I done this is that I would ordinarily forget to do it.

This morning I had the realization that I might just be missing an opportunity here. Automating this sharing process from blog to you the reader is all well and good, but what if at an earlier point I could let you decide whether you want to read this post or not?

A couple of weeks ago I started adding a summary to the beginning of each post. In it I try and condense the gist of the post into a couple of lines. If it’s not for you, you can move on, if you’re interested then you keep on reading.

There was another couple of places though where I could be doing this, and that’s in the original broadcast message and the post to my timeline on I turned off the automatic posting and sharing of my blog and instead opted to use the intro to the blog post as a brief description on the broadcast. The post which was originally sent to my timeline, doesn’t include the intro and it uses a shortened URL which I don’t want. So as well as using the intro on the new broadcast, I’ll rewrite the intro as a condensed version for posting to my timeline on I’ll do both of these tasks myself rather than relying on the automation tools to do it for me.

Automation is great for when it’s mundane tasks that can be repeated over and over without interruption, but when we want to tailor that task each time it happens, we need to step in and do the work ourselves. It’s not a bad thing either. Now I get the chance to tweak the broadcast and post in the hopes that I can encourage you to keep reading as well as reaching out to more people.

To Kill a Project

Stopping a project isn’t easy to do, especially when that project is based on an idea that seemed to be within your grasp. Sometimes though it’s the best thing to do, but to ensure it’s dead we need to kill the project.

I had an idea a few months ago for a service for users of It was a service that curated the most interesting or popular posts from your timeline when you weren’t there to check it. For the most part this could be when you’re in bed or at work. So if you wanted to see the best posts from your timeline in terms of highest replies or stars, it would filter out the best posts for you and email them to you in a summary on a daily basis.

I’ve spoke to a couple of people on about the idea and they were favourable of the idea. After months of incubating the idea though I want to abandon the idea. I never wrote any code for it, registered any domains or even tested the idea. The idea might be a success, but given that the number of users on isn’t as much as Twitter, I’m making an educated guess that it won’t be profitable as a service. I want it off my radar for good. It’s too distracting having it sitting in my master list thinking I might do it one day.

I’m killing the project then. I’m not abandoning it, deleting it or putting it off. I’m killing it. Permanently.

With this action comes a sense of relief. No longer will it sit on my radar demanding another few minutes of contemplation. I can get rid of it permanently.

I’ve only done this a few times in the past and each time it was necessary to simply kill the project. For as long as it remains in a list or in your head, you’ll always spend a bit of time thinking that you’ll get round to it.

The first time I did this was when I killed my mind mapping blog, MindMapSwitch. I had gave up writing about mind mapping but I left the blog itself up in the hopes that one day I might go back and write about it. I didn’t. In fact for about two years it just sat there as another dead blog on the internet. A couple of years ago I decided that the blog had to go. No longer would I need to the account to keep it running. I wouldn’t be writing on that blog ever again. So I took it down. Gone was all the work that I put into it, but despite that, I felt great about the decision. Another little project that has been sitting on my radar is now gone forever. I don’t need to worry about it, spend time on it or even get it started. It’s gone for good.

That’s why it necessary to kill a project. There’s no sense in having a project or an idea sitting there on the shelf gathering dust. Yes, one day you might get round to it, but chances are you won’t. Better to kill the project and move on then have it pecking away at your conscience. Once you’ve killed that project you’ll feel a weight off your shoulders and you’ll have rid yourself of a commitment.

Fixie Friday - BB17 Karma

via FGGT

Photo by Father Tu

Monthly Redux - March


Balance isn’t something that comes up a lot when people are writing about productivity. Once you are aware of it though, it’s a fundamental lesson to learn if you want keep focused and make progress.

I’m like a kid in a candy shop when I have a new idea. I tend to drop just about everything I’m working on new idea for a night or two and then get back to what I was doing before. Not a good practice to follow. When you stop working on something else and spend some time with an idea, it can take over. The idea snowballs and then before you know it, you’ve grand plans for it and it overtakes everything else you are doing. Inevitably my workload becomes so much that I need to try and prioritise and sort my work into a schedule that can’t feasibly accommodate this new idea. What to do?

Well the answer is simple. From now on for every project I take on I need to drop something else. Realistically I can only manage one side project at a time on top of freelancing and family life. When I take on too much everything else suffers. It’s a balancing act.

The monthly themes I am doing just now are good for balancing work as it means that in one month I can focus on a single idea or product for that time. Since the start of the year I’ve used broad themes to cover everything but this month I’ll be focusing on a specific project. It’s the first of four projects that I’ll be working on this year. The goal is to clear the backlog of tasks for that project so that it can be left alone for another few months while I bring another few projects along.

This also means that I can schedule these ideas into the year so that I know what work lies ahead in my schedule. Not only is this good for scheduling purposes but the idea also gets a chance to incubate for a few weeks or months before I start on it. By then I might have discounted the idea will then pick something else to work on.

Fixie Friday - Mars Cycles Track

via FGGT

Complicated Software

Complicated software looks like hard work, but does that make simple software easier. I would say no. In fact I think it’s harder to produce simpler software than complicated software.

At the weekend I got into a conversation with my Dad about complicated software. My Dad is a draughtsman. He puts together the drawings for piping installations such as refineries and oil rigs. He uses software on a daily basis for his piping designs, but it wasn’t always done this way. When he started in his career nearly 40 years ago there wasn’t a computer to be found near the desk of any draughtsman. Everything was done with pen and paper. Simple tools by today’s new tool of choice, CAD software.

Over the last couple of decades the mouse has replaced the pencil as the draughtsman’s main tool for work. In this time the market for CAD software has boomed and with it come some of the most complex software I have ever heard of. My Dad has made the gradual change to CAD over the years through a number of training programmes and plenty of on the job experience. His biggest bug bear though is the software. In his opinion it is too complicated.

For over a decade now I’ve heard many complaints against software being too complicated. Complicated software isn’t the root of the problem though. Software starts with people and what those people want. These are the initial requirements of software, what we expect it to do. Given enough time, and no constraints, any software product can go from simple and easy to use to bloated and complicated. In the past it was thought that a software product rich in features was the way to sell it. What happens over time though is that the product continually grows and grows as it caters to more and more requests until it becomes just too big and complicated to use. Those original features that made the software a hit have become bogged down by other quick hit features that only cater to a small subset of users.

We software developers are a bit older and wiser now though and we’ve learned a lot from those first days of commercial software. The main thing I think many software developers have learned is that it is okay to say no to a request. This is perhaps the hardest thing to do, we want our software to be used by many, but that doesn’t mean catering to every request. Saying no to nine features, but yes to one is our way of saying that we care about the software we produce. If a feature doesn’t fall within the general mantra of the software then we should say no to it. Yes, we might gain a few more users, but in turn we could end up annoying half of our existing users.

The thought of complicated software has made me re-assess the projects that I am working on and how they can be simplified for the people that use them on a daily basis. It’s also made me question requests from clients for changes to their products. I could simply take the money and add the new feature, but by questioning that feature I could be opening a new discussion with the client to find the exact source of the problem and deliver a solution that will simplify the software instead of complicating it.

Back on the Course

Yesterday was such a glorious day in terms of weather. An ideal day to get Ethan back out on the golf course. Unfortunately the course is still a bit damp from the last couple of weeks of rain but hopefully it will dry out soon.