Matthew Lang

Big decisions are often fraught with risk. Sometimes though the only way to make the right decision though is to test the options first.

For the last few months I've been working on a CMS application for a client that has been steadily growing in size. We both agree that there will come a time where we will need to make some decisions about the design of the application so that it remains easy enough to maintain and develop but also scales up with the client's expected growth for the next few years.

It's something we've both been putting off for some time now, but with more projects and clients appearing in the client's pipeline, we've decided that now is the right time to start making these decisions.

The problem has always been though that if we make the wrong decision we end up too far down a path that we don't want to be. Backtracking might not be an option and working towards a different solution is something that we don't want to end up doing either.

The answer to this dilemma has been surprising simple. For each technical decision we have to make, we have a number of options that we can consider. Rather than analysing and committing to the most attractive option (in theory anyway), we have decided to take a day and implement that option in a single day to see where we get to. If by the end of the day, we're still happy that we've made the right decision, then we continue on with this option. If we're starting to have doubts, we abandon the option and try something else.

Software developers will recognise this concept as a spike. This is the idea that you carry out enough work to recognise the risks and knowledge that are associated with change in design or functionality. The spike gives the developer the chance to find out the risk and complexity involved in such a change. With the information, developers can provide better estimates for these changes or completely rule out a change.

The spike is a great way to ensure that you limit risk from a decision without committing to that decision. It will involve some time to determine if the option you are spiking is worth pursuing, there's no getting around it. However it is better to invest some time in pursuing the right decision rather than blindly committing to the wrong decision is it not?

Love the raw finish on this.

via FGGT

Apple's addition of a smart watch to their product line is a sign that smart watches are definitely here for a while but is it too early to be calling time on watches?

A few people have mentioned that smart watches will kill the watch. I think it's a little too early to be making that statement.

The smart watch is still new in terms of technology. We've had attempts at smart watches in the past, some good, some bad, and there will be a few more iterations on what makes a good smart watch. That is until companies all meet at that point where they all agree sub-consciously agree on the design template for a smart watch. There will be a few more years yet before we get to that stage where we know that the smart watch will just work for us.

Then there's the technology aspect of the smart watch. It does so much more than a regular watch does, but do you want it to do that? Despite the fact I've had smart phones for over five years now and they've all been able to tell me the time, I still wear a watch. I like wearing a watch. It means I can keep my phone in my pocket when I need to know what time it is. If I didn't wear a watch I would probably have my head buried in phone everywhere I went. As soon I would check the time on it, I would leave it out and read it until I got bored. Thankfully I don't do this thanks to single purpose of the watch. It just tells the time.

I also don't want another device in my house that requires charging on a daily basis. I wouldn't say my house is brimming with technology but we have our fair share of gadgets in the house. A couple of smart phones, a tablet, a laptop, a Kindle, a games console and a couple of televisions. Maybe slightly less than most people but it's something I've tried to keep a cap on. The Kindle is great as it only requires charging every two or three months and only needs an hour to be fully charged. Adding a smart watch to this mix is not something that appeals to my environmental side. I'd rather have a watch that required a single small battery every couple of years than having to charge my smart watch on a frequent basis.

We've seen these statements before about technology phasing out tried and tested ways of doing things in the past.

Remember when Amazon launched the Kindle? Lots of people made predictions that books would be phased out in favour the new digital books. As convenient as a Kindle is though, sometimes a book is definitely better. It requires no power to read the book, it's just as portable and there's that great feeling of scribbling notes in the sidelines. Thankfully today there are still a healthy number of book stores around and they're filled with books. The death of the book? Not yet, which makes me wonder if making statements about the death of the watch is just technology fans getting ahead of themselves.

The smart watch does herald a change in the way we can carry technology about with us. We have another small window to look at when we're out and about seeing the world, meeting people and making experiences. That can still be done with or without a smart watch. For me, I'll be casting my eye towards the traditional mechanical watches for my next timepiece purchase. They're less intrusive, more reliable and cheaper to run over time and besides, I can do everything I need with my smart phone, right?

Love American Football? Love writing code?

Here's a quick run down of American Football related terms in the context of software development.

As promised to one of my App.net followers, here's a quick run down of the setup I use for writing in Markdown.

I stopped using Sublime Text as my preferred code editor a couple of months ago, but there's something that I still use it for every day and that's for writing my blog. As a result I've removed a lot of packages from Sublime Text and managed to whittle it down to just the essentials. Here's a run down of everything I use for writing in Markdown with Sublime Text.

Theme and Colour Scheme

After a number of years of trying different themes on Sublime Text, I've now resorted back to the excellent Soda theme. It's stable and easy on the eye. There are a number of great themes out there but in my experience, they're not as solid as Soda.

As for the colour scheme I'm sticking with Solarized but instead of using the dark variation for coding, I use the light variation. It's makes a nice context switch trigger when I'm moving from code to writing.

Packages

I don't use a lot of packages for writing in Markdown, but there are a few that definitely help.

• MarkdownEditing - A Markdown plugin for Sublime Text that provides good syntax highlighting and editing features.
• Origami - The default pane layouts and keyboards shortcuts can be infuriating. Origami solves by letting you splits panes easily.
• WordCount - Nice way of seeing your word count. Always handy if you like keeping an eye on that sort of thing.
• Marked App Menu - Opens Marked and Marked 2 from the document that you are working on.

External Tools

A special mention goes to Brett Terpstra's fantastic Marked app which is great for previewing and reviewing your Markdown documents. Simply open your Markdown document in Marked and watch it update your Markdown document in a theme of your choosing while you type. Not only that, but Marked also has a ton of features that allow you to review your writing. If you're a Mac owner, I strongly suggest you check this out.

Keep It Light!

My setup for Markdown writing is rather light, but it's supposed to be light. When I am writing I'm not thinking about keyboard shortcuts I could use to type faster or neat plugins to use. Most of the packages I use are there because I can just install them and that's it. There's little configuration or maintenance to do and that's the way it should be.

I've been writing for so long with Markdown that the mark up is becoming automatic as I type so I don't need to worry too much about using shortcut keys for things. I just keep typing, peppering my words with little bits of mark up as I go.

Free services are the most popular way to attract users, but what are you compromising on for this to happen?

The word 'free' is still a popular way for many online services to gain the users they need in order to start becoming more than just another blip on the Internet radar. With that enticing offer of being free, most people sign up, use the service and then decide if they want to keep using it or not. The pull of being free can be a powerful thing and like so many things people like it when they get something for free.

In the beginning users of the service are happy. They can't believe their luck that this service is free and they can use it on a daily basis. They love the new service and sing its praises to their friends who in turn sign up as well. It is free after all. The trend continues and if the service is a hit it can eventually scale to becoming the next big thing.

After a few years, the service owners wants to start making some money, but they don't want to charge their loyal users for the privilage of using their service. That would be a terrible idea. Instead the service owners decide to change some things about the way the service works. Maybe they limit the API, change a well liked feature to what the service owners think is better (for them anyway) or even just start throwing some ads in. That last one always works right?

Alas the loyal users of the service start to feel like they have been cheated and throw their arms up in the air in objection to the new changes the service are implementing. Just because they have been loyal to the service since its early days, it's wrongly assumed that the service owners are going to listen to their users. Sadly they don't. And then an amazing thing happens. Despite the drawbacks to using the service with the new changes they don't approve of, the users decide to keep using the service. It's not about free anymore though, it's about the people your connected to using this service. How will you ever connect to these people without this service?

Clearly I'm taking a few examples from social networks like Twitter and Facebook, but the rules apply to any service that starts out being free and refuses to entertain the idea of a paid account or subscription. The rule is that in order to gain the user base you need to become a smash hit, you need to make your service free for everyone. You need to make it instantly attractive for people to use and that starts with giving it away for free.

It's a plan that has been played out with many services now and while there have been successful exceptions to this (well done Trello), many free services stick to being free and then try to generate revenue by using brand advertising and promotion or selling data as a product to others.

It's at this point where the idea of a free account is nothing more than a compromise. In exchange for using the service in question, you must be prepared to accept the changes to the service and continue using it as best as you can. You might not like the changes that the service are implementing but the decision to continue using it or leave the service is down to you. You're the user after all.

This is the cost of many free services now. If they don't require something back from you in return now, chances are they will in the future. It's just a matter of deciding how much you're willing to compromise on to continue using the service.

I would love to have one of these Weston phone pouches sitting on the shoulder strap of my Gulper.

via PEDAL Consumption

I watched DHH's keynote from RailsConf 2014 and it re-iterated a few things for me but what stood out was the similarities between writers and programmers.

There's been a lot of talk in the Rails community about architectures, design patterns and testing recently. DHH touched on this in his keynote but one thing I wanted to mention here was the idea of drafts.

When it comes to writing code, your first attempt is never your last. Unless you have all the knowledge and time under the sun to get it right first time, there's always going to be scope to improve that code you just wrote.

I tell my clients when I think that a section of code could be improved by re-writing it. I'll pick the smaller sections of code to re-write as they offer the greater awards for the smallest investment in time. This suits my clients as they usually want features over improved code, but if I can improve the code base in anyway, then I'll aim for those bits of code that can be improved with just a small amount of time.

The same goes for writing. Your first draft is never your final piece. It might just flow from your pen but reading it back it might not sound as good as you first thought. Unfortunately re-writing my blog posts is something that I don't usually do. I'm just so busy at the moment that the most I can do is a first draft, a read through to correct mistakes, a quick couple of improvements and then publish it. It's hardly the process that I should be working towards.

Rather than worrying about the re-writing of these blog posts though, I'm looking at larger bits of writing that I have done. I have a first draft of my grass roots productivity series that I have compiled together for an e-book. I should make some time to go through this and re-write it. It's been a while since I looked at it and perhaps the unfamiliarity of it might reveal the places where I could improve it.

I know now though that regardless of whether it's source code for an application or words for a book, the first draft should never be your final attempt. Maybe there is more in common between writers and programmers than I first thought.

via PEDAL Consumption

It's taken me a long time to find a habitual way of reading books that works for me. I call it the daily reading ritual.

When I first started my career in programming there was one titbit of advice that I had seen repeated over and over again.

Read a programming book every month.

I don't know how many of you have read a programming book, but for those that don't know they can be difficult to read. The trouble with programming books is that they are better used as reference books. Lookup material for when you're stuck.

I tried the one book a month goal and I failed miserably. For the next few years I kept on trying but no matter what book it was I would either give up on it or still be reading it at the end of the month.

So how do you digest a programming book without it becoming a monotonous chore?

What I've found that works really well for me is that I take five non-fiction books (programming or otherwise) that I want to read and I read a chapter of each book on a specific weekday. At the moment Monday is a freelance and marketing book, Tuesday is a sketch noting book an so on. What this gives you is variety. Every day is different. It's breaks the monotony barrier.

What about fiction books though?

Fiction books are easy to read because you usually have no idea what's going to happen and it's the authors job to send you to a place that's not your usual environment. It's a form of escapism.

I don't set a time limit for these as it takes the enjoyment away from the book. Instead I try and read these books as often as I can. It's usually at night when the kids are sleeping.

Since starting this ritual I've found it much easier to make progress on the books I've wanted to read. Not only that but I've also managed to set aside a few minutes in the morning for the non-fiction books and then at night I can plough through whatever fiction book I'm reading.