James higgs  00a652

James Higgs

James has been developing software commercially for almost 20 years, in fields as diverse as manufacturing, TV broadcasting and retail. For the last decade and a half, he has focused almost exclusively on the web. Today he is increasingly fascinated with mobile devices, in particular Apple's iOS devices.

[CLOSED] Hiring: Freelance QA Engineer

Freelance QA Engineer
London, UK

We’re looking for a freelance QA engineer to help us out on a range of projects for a minimum of three months, with an immediate start.

You will be helping us to launch and improve several products that we have in development. QA is a crucial role in helping us to meet the very high quality that our clients demand and which we expect of ourselves.


We are hiring: Ruby Developer

We are looking for a great technologist to join our team.

We believe that technology is not invisible to users, but rather integral to how people feel about a product and the companies that make them. The products we make resemble digital start-ups and we use similar approaches to build them.


Making editorial tools for ITV News

One of the fundamental principles we lived by throughout the process of redesigning the ITV News website was that we needed to ground what were doing in the real needs of users. Cath explained our approach in an excellent post a few weeks ago.

All too often on content management projects a very significant group of users are taken for granted: those who will create and manage the content. On this project, we were detemined that we would really try to understand the editorial experience in depth, and provide tools that fit the journalists’ requirements.

We started with a fascinating and intense day in the ITN newsroom with Jason Mills and his team. We were allowed to attend the morning editorial conference and busy journalists tolerated our interruptions and stupid questions throughout the day. Finally, we were allowed to have a nose around in the studio and then watch the ITV Evening News transmission from the gallery.

Alastair Stewart in the ITV News Studio


Apple's aesthetic dichotomy

When one talks about Apple's design, one immediately thinks of Jony Ive's modernist, rational industrial designs for computers, peripherals, and of course the iPad and iPhone.

These devices have become increasingly simple and pared down, even as the power contained in them has increased. There is very little, if anything, extraneous on the Magic Trackpad or the MacBook Air. And of course the iPhones 4 and 4S are radically simple, yet well-constructed masterpieces of industrial design. 
But there's something I've puzzled about for a long time in Apple's aesthetic. Inside these unsentimental, rational, economic designs, Apple has delivered an increasingly sacchirine series of software releases.

A simple strategy for managing technical debt

Yesterday, I tried to explain the concept of technical debt. Today, I’ll try to suggest a practical way to track and deal with debt in your project.

As with debt in the real world, the trick with technical debt is to track your liabilities and make sure you have a plan for addressing them. Allowing debts to build up without thinking about what you’re doing is a terrible way to run your personal finances and your software development project.

So long as you are making informed and deliberate decisions about when to incur debt and when to pay it down, you do not necessarily need a plan to eliminate your debt entirely. Rather, you should aim to keep it at a sustainable level so that you’re able to add new features to your product relatively easily and without too many side-effects.


The Four Grades of Technical Debt

Almost all communication between developers and non-technical colleagues or clients is done through a set of metaphors. Some of them (the construction metaphor, for example) are actively harmful, but others are potentially very useful.

The idea of technical debt is one of these but, as with any metaphor, it’s important to understand where the limits of its applicability are. For these metaphors to be useful, they need to be used accurately.

There’s a pronounced tendency within the agency world to appropriate technical terms and then to use them incorrectly (‘operating system’ is the trope du jour), presumably in order to appear more technically knowledgeable but, to anyone who knows what these things really mean, the effect is just to reveal the metaphor abuser as a bullshitter.

Abused in this way, useful terms gradually become stripped of their meaning and replacements have to be found. I worry that this is happening with the term ‘technical debt’. Hopefully, this post will help to clarify its meaning.