Luke Hansell

I recently noticed that my site was broken… When we ported it to the new server the DB got a bit messed up and ended up linking to lukehansell2.com instead of lukehansell.com for everything. so no posts etc. loaded. Anyway this should be solved now. So for anyone attempting to actually view content on this site you should be able to again!

I realise that the site is currently in a bit of a state. However there’s a brilliant project that I’ve been wanting to work on for years that I’ve just started. All my free time is currently taken up with this. Therefore I’ve not had a chance to really even look at this site since it was hastily ported over to a new server (hence the loss of styling and default wordpress everything).

Hopefully soon I’ll be able to get it all back up and running smoothly. Until then, my apologies and please watch this space for info on the aforementioned project!

Every year the animals of the forest held a race to see which of them was the fastest. Each year the race was won either by the grey hare or the white hare. Each trained hard so that the following year they may defeat their rival.

The other animals soon grew weary of always losing and one by one they declined to race any more. Eventually there was only the two hares and an old tortoise left in the race. The two hares each said,

“We know that next year one of us will win. Since the tortoise proves no challenge why train so hard?”

The two hares, comfortable in their coming victory neglected their training and over the next year grew fat till neither could run any more. The tortoise won the race with ease.

Healthy competition benefits both;

mutual laziness benefits the weak

The fox sniggered at the owl,
“Ha! I know more answers to questions than you!”
The owl replied,
“yes, but I know more questions to answers.”

Competitive advantage is knowing the answers to questions no one else has thought of.

The other day I was reading a post on a web site in which the author was discussing his old slap-dash method of code. He referred to it as “scratching the itch”. Basically you have a problem and you find the quickest solution to it. Now I’ve seen this many times and after I finished reading the article I kept thinking about it. I came up with three typical responses I see from programmers when presented with a problem (whether debugging, maintenance or adding new features):

1. scratching the itch
2. hacking off the arm
3. doing it the hard (and right) way

-option 1-

Scratching the itch is great because it gets rid of the symptom and it does it quickly. It however works like western medicine: you cure the symptom but not the cause. The underlying problem that initially meant you had to debug/maintain your code is still there, you’ve just covered it over with poly-filler. This method of coding is good for 3 things: getting results quick, making you look good to non-programmers and making a mess of a project.

The problem with scratching the itch is that when you have a big project and a lot of itches you suddenly end up with a lot of caveats in your code. You end up with a scenario where your code reads like this:

If this happens

->do this

-> unless this has happened

---> or this

-> but you can do this anyway



A shoddy example I know, but you get the point.

Imagine then that your project expands, new developers join and new clients request new features of the same code. The caveats then need re-explaining to everyone and you or you have to write a whole new set of rules to work around your previous set, whilst still taking into account the original code. The whole process is cyclical and you create more issues further down the line then you originally had.

-option 2-

This option doesn’t really provide a solution to the issue, it just gets rid of it. When the going gets tough, get rid of the problem. Unfortunately, unlike in most other aspects of life, this isn’t really an option when coding, especially when you’ve got angry clients on your back because of a small bug or change to the design they want to make. Much like in real life if you hack off you arm because it itches, you’ve just got one more bigger problem to deal with…

-option 3-

This is my smart option. Forget about the previous two, they’re just there for show. This is where the business is at. Unfortunately that also means that in the short term it is expensive in terms of time, money and patience. You may not look like the whiz kid who can fix an issue in 5 seconds flat, but they won’t have any further cause to complain, and sooner or later that’s going to count for something.

When a change needs to be made, whether it’s a bug or a new feature to be implemented, be smart about it. Step back and examine the context and the current architecture. Ask yourself “how can I implement this causing the least damage to the future of this system?” Address the problem first instead of glazing over it. By stopping and thinking (this harks back to my last post) you can implement a solution that causes the least damage, solves the actual issue at it’s source (cause not symptom) and takes care of itself without leaving holes for others to plug at a later date.

To do this you really need to know your system and be able to identify how to best solve the issue. This whole process is akin to building an extension on a house. You can either: a) nail some wood to the side and call it a room b) bulldoze the house and start again or c) lay out a plan properly and a solid structure from the foundations up.  If I had three builders show me these three plans I know which I’d prefer and I know which is going to cause the least problems in the long run. Would you trust a Cowboy Builder? Then why would you be a Cowboy Coder?

Believe me I’ve seen this many times from good programmers to downright bad programmers. The lure of the quick fix is just too appealing. Saying “here you go” five minutes after a client request a new feature will make him like you, but years of having to come back with bugs afterwards will spoil your reputation much more. It’s kind of like the other post here about business and cake (we’re on a greatest hits of my old blog posts!). It may be sugary on the outside, but if the insides are rotten then no one is going to take another bite.

The bottom line here is that problems are going to arise. Clients will always want new features and maintenance contracts have to be fulfilled. Bugs will happen, changes to the plan will happen, what determines the success of these changes and ultimately your projects is how you handle them. Not only how you plan for what’s happening now, but also for what might happen in the future. Remember problems are more expensive to fix the further down the project cycle you get, so do yourself a favour and think before you type.

to summarise

3 methods of problem solving

->scratching the item -> quick fix with lots of praise and problems

-> hacking off the arm -> lots of blood and tears

-> doing it the hard way -> address problem not symptoms and plan! -> takes time but is worth it in the long run

So there you have it, my attempt at a quick explanation about something that occasionally really bugs me… (I promise that pun was not intended…)

Don’t be a Cowboy Coder!

Everyone knows that before you start a new project you need to plan. It’s a given really, the more you plan before you begin a project the less headaches you get further into it (and the less it costs you to fix the problem). Sometimes you don’t have time to plan, and I understand and appreciate this fact, but at every stage that you can you should go back over these amendments and re-build them back into your initial plan, trust me it’ll save you a  lot of time and heartache further on up the road!

I don’t however want to write about planning, and I don’t want to talk about the first steps of specification gathering etc that happens initially. This post is about the stage in-between these: understanding! Between the client gathering etc and planning you should stop to understand the project, and the context in which it resides. This can be understanding the current system, the current way of doing business, how it may affect future endeavours, how you’re going to attempt to complete and implement your project or even exactly what the project is.

For instance I’ve seen it happen many a time where a developer has not fully understood the current implementation of a system and has jumped in with some radical quick fix. In the end all this means is that the rest of the developers have to take into account the loopholes that this developer has created. Once you start stacking up these little niches you can create a massive load of code that would never need to be run if the changes that had been made (or even better the initial system) had taken into account all possible requirements and the current system architecture.

The other example comes in the form of adding columns to database architectures before fully understanding the entire database, or at least all connected fields. Often you can end up re-creating something that already exists (though it may be in another form – think birthdate and age). This is not only a waste of time but also a waste of resources and memory. Database architects often go to a lot of trouble to create a system that caters for every need, but they can’t predict the future. Just think – understand the current system – before you add extra fields. I’m not saying don’t do it, obviously you have to some times, just stop to consider how best to implement the changes.

It may seem trivial and a waste of time but stopping to properly map out your thoughts and all its ramifications before beginning your plan will mean you end up with a much more all-encompassing project that doesn’t require everyone else to tip-toe around it. Even just explaining to yourself and making some notes on paper (I find physical paper is much more revealing and free flowing than a word processor where ideas can be lost below the fold) can lead you to discover something in the system that you didn’t expect or an easier way of accomplishing the task. Take the time, you’ll always get it back in not bug fixing later!

Of course you also have to know when to stop. At some point you need to move on to the planning stage, don’t be afraid to do so as long as you believe you understand what is going on and why it’s happening. Once you believe you’ve achieved this feel free to move on, also feel free to stop again!

It’s been ages since I’ve posted anything. This I know. In all honesty I’ve not really had the time over the past few months to even consider doing any programming etc for fun. However I’m determined that this is going to change.

I’ve got a new project in mind, it’s one I’ve wanted to tackle for a while. I’m jumping back into the saddle with AI programming and am going to look at building an evolving community in a virtual world (by virtual world I probably mean text based).

The aim here is to mimmic natural selection and attempt to create a population which can sustain it’s own life for an extended period, and then play with the variables to see how it evolves to deal with the pressures. I’m sure this kind of project has been done many a time before, but I want to start small, with even the smallest of abilities to try and show how certain behaviours may come about… I’m also considering writing a book…

On a more business level: consider your profit per employee. Is a large group of employees with a small profit per head better than a tight nit bunch with high profit per person? More power versus too many cooks? Ok so the business insight is a little short, but it’s late and I’m excited about the new project!

Remember: when someone says something is impossible that means they’ve given up, that doesn’t mean you should as well.

“A business is like a cake”

Interesting and somewhat evocative words from Mr Hicks the managing director of Mainline Menswear, the leading independent online fashion retailer in the UK.

I agree, business is like a cake. People see the icing first. They don’t see the hard work that went into producing it, and they don’t see the structure inside that keeps it all stable until they’ve bitten into it.

I suppose this acts as a warning to consumers as much as it does the businesses, for if the business inside is poorly baked then the customer will never take another bite. What you, as a business or indeed an individual would like is the ability to finish the cake, get the most out of it and come away smiling thinking “I really wish I had another one of those cakes!”

To use another old phrase “you can’t polish a turd.” To try to do so in business is suicide. You may attract customers with shiny advertising and a brilliant exterior, but if the interior doesn’t work then you’re not going to be in business for long.

There’s another tip for you: make it work, then worry about polishing it.

I’m going to leave this post with a question. What if instead if cake a business was like jelly? You can see all the way through, but still can’t fathom what makes it work…

If there is one thing that you could ascertain from some of my previous blogs it would be my distaste of the Apple corporation. However, (and it’s quite a big however to those that know me) I recently purchased and Apple iPhone 4, and whilst I find some of the interfaces annoying, unintuitive and occasionally boring I am currently sat in a coffee shop doing the asymptotic thing for geeks by updating my website and sipping an americano. Cliche is an understatement. But what I’m finding from this experience is a real use for the iPhone…

Today my car broke down and I was able to direct the recovery person to my car using the phone’s GPS and keep myself entertained and my social media world updated whilst I waited. Boring, but less so than doing nothing at all!

I suppose the problem I have with Apple is their closed circuit nature when it comes to developing. Apple is the prime example of a corporation protecting it’s interests by taking he fun out of tweaking, something that as a developer I often rely on. What I’ve found is that the iPhone does a limited, but vast array of things. And he things it does? Well it generally does well. I suppose the real test is when I read this back and find all the errors from the spelling suggestions etc.

I really can’t fathom why I’m actually writing this. Some sort of fickle appology to the spirit of iFans, but I am nonetheless. I suppose the moral of this story would be: don’t be afraid to change lanes on the motorway, just check behind lest you cause an incident in your wake.

By the way this coffee sucks.

I’ve not updated things in a while, and for a new site I suppose that’s a killer really. However, I’m hoping to still go strong…

I’ve recently finished my University course and started a new job (developing apps actually – so watch for more complaints regarding those!). Now that things have settled down again I’ll be back on form with updates etc on here and my apps.

Speaking of updates, version 2 of the Guitar Tuner pushed the number of users well over the 100 mark. I’m pretty pleased with that, especially as it was a simple test of the water! I’m going to continue developing and adding to the Tuner extension, I believe there are still some things that need work regarding it. If you think of anything that I could work on with regards it then as always feel free to contact me.

Remember: everything that will exist, exists now. The pieces just aren’t in the right order…