Site Morph at Silicon Milk Roundabout

After what seemed like a short afternoon presenting at Silicon Milk Roundabout
I am left with a few feelings I would like to share: Again I was impressed by
the organisation of the team running the event. It is a really great event.
This was my first time attending as a potential employer. It is quite a
different expirienc on the other side of the stand.

While my feed ache from standing for five hours the more lasting feeling
is that it was well worth the effort attending. There seems to be no shortage
of talent in the London tech scene. From technology advocates trying to leave
the corporate offices of financial institutions to third year graduates seeking
their first taste of gainful employment: there is a great mix of interest and

One slightly surprising thing that grabbed me and a number of people I talked
to was that there seemed to be a strong bias for back end developers. I should
say that for most people back end seems to mean their art is executed by the
server rather than the browser. This left me with a few questions. Are there
just more back end developers? Are the back end officianado's just more likely
to work in a startup or: Are the more aesthetic front end developers already
working for the start up of their dreams?

At the same time that there seemed to be a relative shortage of front end
developers; I should say, for me front end is anyting involved in presentation
and includes the web server; it seemed like everyone I talked to today was
trying to hire a front end developer. While I tried to talk to everyone I saw
wearing a frontend badge I am sure I didn't meet them all. Having said that I
estimate there can only have been a few tens of front end developers at the
event and seemingly hundreds of jobs for them.

Design work seems to have taken on life of it's own in the last few years as we
have seen the shift via a pervasive Internet to a more aesthetic web including
ever more design. This leads to another question: are you a web developer if
you don't include design aspects in your portfolio of skills?

Finally I would like to share a few things we learned from this even:

  • Make sure you have a nice poster that explains your start-up. We had lots
    of interest because of ours.

  • Make sure you invite a few friends to give you a break when you start
    loosing your voice.

  • For a small stand you can probably only hand out about 100 leaflets in
    five hours per presenter. Yes that is one every 3 minutes.

  • Take a table and chair and put them at the back for the tiny moments you
    can take a breather.

I am positive that we have found some great candidates. Hope to see everyone
again at the next event.


PHP : The only choice for front end development?

Is it the only option?

In a recent chat with a ex-colleague we were discussing how hard it might be to find a front end developer who can also use Java. They rightly pointed out that there are a lot more design oriented front end developers using PHP. This reminded me of Jeff Atwood's post on The PHP Singularity where he talks about how the only option is to invent something that is so much better that it's use is not even a question.

This is also relevant because I have been evaluating Java page template technologies like the play framework. Most of the options like that are very similar to template frameworks from other languages. On a personal note, I am not a great fan of these due to the tag soup issues they seem to promote.

While the search continues most of the current stack I am using is a minimal non template approach similar to the work from Apache on wicket. Perhaps the need to get other front end orientated developers involved in current projects will force the requirement but let's hope that I can find someone at Silicon Milk Roundabout that can read Java and create usable and attractive UIs


Why I am giving up my day job to run a technology start up

As some of you know I have been working on a new idea, a website called SiteMorph. Until now I have been doing this while working full time for one of the web’s largest brands.

I have decided to ‘quit my job and chase my dream’ of making SiteMorph a success. I think it is a great idea: help small websites increase sales or conversions by turning their data into actionable insight. From working with colleagues it is clear that in terms of website optimisation and tuning, manual analysis can yield staggering improvements in sales and conversions. The goal of SiteMorph is to offer a low cost self guided alternative to a full service consultant.

The site is officially launching this month (March 2012). We already have our first customer and a list of people wanting to try the site. As well as myself there are a number of other contributors including one of the top Google Analytics consultants in Europe.

Given the timing, my minimal commitments, collaborators and minimum collateral, everything feels right to take the plunge now.

As I start this venture I know that my best work is still ahead.


Is technical debt the Pinocchio’s nose of software engineering?

Technical debt seems like the Pinocchio's nose of software engineering; the ‘lie’ that something is finished perpetuates and causes it to multiply in size. Matthew Heusser in his article[1] says in other professional bodies people are referred to as ‘shysters’ or ‘hacks’ if they breach the confidence placed in them. As an example of good professional practice, Matthew describes a lawyer who would drop a case rather than compromise their counsel.

Whether the pressure to ‘get things done’ is internal or external to our engineer; let’s assume for now that they want to do the right thing.Our hypothetical engineer may choose to leave as in Matthews’s example of a lawyer but he then faces is the ‘better the devil you know’ dilemma (fear of the unknown). Another solution may be to find technically competent teams in their organisation who create a professional environment.

The strange thing about these questions of practice is that we all know that time invested in testing and other code hygiene issues pays off even in the relatively short term. Take for example the data from InfoQ that tells us "defects per thousand lines of code, decreased between 40% and 90% relative to the projects that did not use TDD"[6].

In his article Matthew goes to to say "the solution is not to try to measure the debt. If you do that, you’ll take a proxy measurement, which the team can exploit. More time spent measuring more things quickly becomes a death spiral" [1]. Intuitively the only way to avoid an ever growing debt is to avoid it in the first place; this seems like your mom telling you to save for things rather than taking a loan, you know you should, but few do. Another perspective from Ben Scofield is that "adequacy is very interesting. For one thing, adequate performers win more often than they lose" [5]. Given how seductive the allure of ‘winning’ is, the problem becomes how to avoid needing a hero complex in order to do the right thing.

Matthew’s reference to the ‘zero sum gain’ principle evoked another old favourite: the no win scenario. The answer could be the ‘change the rules of the game’. This is mentioned as a solution to the ‘no win situation’ [2] popularised by (among others) the character James.T. Kirk in the fictional Kobayashi Maru training simulation [3]. Try imagining a ship full of software engineers in the same simulator saying ‘sorry guys - we have a deadline so you’re just going to have to sort out your own life support problems’.

To understand how to change the rules of the game first we must change ourselves and our comprehension of the situation. One technique that I found useful is described by Andrew Hunt and David Thomas in ‘The Pragmatic Programmer’ as ‘Tracer Code’. The idea is that you change the assumptions of what you have to deliver in order to learn more about what it is you are trying to build [4].

Ultimately the answer has to be to find a way to avoid stepping on the slippery slope of saying something is ‘done’ when it is not finished. As Matthew says at that point you are a few measure-and-manage steps away from a death spiral.

[1]November/December 2011 Better Software, P18: 10 Thoughts on Technical Debt by Matthew Heusser.
[2] http://en.wikipedia.org/wiki/No-win_situation
[3] http://en.wikipedia.org/wiki/Kobayashi_Maru
[4] http://pragprog.com/the-pragmatic-programmer/extracts/tips
[5] http://pragprog.com/magazines/2010-08/in-defense-of-mediocrity
[6] http://www.infoq.com/news/2009/03/TDD-Improves-Quality

Thanks to Julian Harty for his editorial input.