Software People Inspiring

Team Katas. Like, Y'Know, Katas For Teams

There are lots of well-known programming katas that individuals and pairs have been using to hone their craft. So far, though, there's been a tendency for these katas to focus on a small subset of disciplines - in particular Test-driven Development - and to stop short of creating anything more complex than a bowling game or Conway's Game of Life.

But what about all the other skills a software developer needs? Usually, what we're working on is more complex than a single algorithm, and usually we're working in teams, tackling different aspects of the problem in parallel.

Code katas tend not to exercise our communication skills, or disciplines like collaborative design, continuous integration and the whole messy business of delivering working software that does what the customer needs.

Then it suddenly occured to me this week, while running a 2-day workshop on collaborative design, that this whole workshop is a Team Kata. Well, potentially.

The group is split up into pairs and assigned different user stories for a community DVD library management system. They have to design and implement their aspect of the system in parallel with everyone else.

I act as the customer, and each pair has to agree an acceptance test with me. The ultimate aim of the exercise is to deliver working software that passes these acceptance tests. Ideally, it should be well-designed and maintainable, too.

I've done this sort of thing without applying programming and team disciplines, and it can be an utter train wreck. It sounds easy on paper: half a dozen or so simple user stories, a handful of core application classes and a user interface with a handful of views. For a single pair working on the stories in a sequence, it's a bit of a doddle. But for a team working in parallel, it's surprisingly tough. We measure delivery by how much of the acceptance tests we can pass at the end of the second day, and - so far - no group has delivered more than 30%. Collaboration is hard.

But, like all disciplines, it gets easier with practice. I'd wager that the same group, given a chance to repeat the exercise, would deliver considerably more the second time around -even if we gave them a completely new set of user stories for a different problem.

What always amazes me is that, in 2 days, with a bunch of UML training taking up some of that time, these groups deliver anything at all. I've watched some pretty experienced teams chase their own tales for a week before they even get a build up and running. The communication overhead defeats many teams, in my experience, and this is something that we can work on with deliberate practice.

So I'm proposing the notion of Team Katas. Get the whole team undertaking a group exercise to solve a shared problem, and vary both the problem, the rules of the exercise and the make-up of the team to sharpen those team skills and keep everybody frosty.

SC2012 Will Be My Last. Could SC2013 Be Your First?

This year's Software Craftsmanship conference will be my fourth, and if you know me, then you probably won't be surprised to hear that when I started the conference in 2009, I had a plan.

I told myself I would run 3 more SC conferences (after the first sold out) at Bletchley Park, and that the conference would be raising funds for that august institution.

We're on track to raise about £15,000 this year (touch wood), which would bring the total raised by all you generous codesmiths to roughly £40,000. This money has been spent wisely by the trust, and has contributed significantly to the refurbishment of the museum in B Block, as well as the new Alan Turing exhibition.

This year's conference will be the last that I organise personally. So what's next in the plan?

Well, that depends on you. If the conference is going to continue - and presumably evolve - then I'd like it to go to a good home. I would hope that any group who organised SC2013 and beyond feels as passionately about software as I do, and as all the great session leaders and everyone who's participated in and supported SC20xx do, too.

I won't lie to you; this is not a commercial conference. Unlike events that can attract CTOs, IT managers, project and programme managers and other people with budgets to spend, SC20xx is never going to attract vast amounts of sponsorship. So nobody's going to get paid to run this conference, and lavish goody bags and dancing girls are off the menu.

But if the format were changed to attract non-programmers, I feel strongly that it just wouldn't be the Software Craftsmanship conference.

I also feel strongly that Bletchley Park is the right home for it, and that it should be used to raise funds for projects there.

The hard-and-fast requirement I stipulated after the first conference that every session must involve live coding also comes with its drawbacks. Developers can feel self-conscious about programming in front of their peers, although anyone who's run a session from SC2010 onwards will probably tell you that this particular audience is much more enthusiastic and forgiving than most.

But, even though drumming up session leaders can be a pain in the arse, we have consistently managed to attract great sessions from great session leaders, and the roll call over the last 3 years is something I'm extremely proud of. It takes some arm-twisting and an element of horse whispering, but it definitely is worth it in the end. And not just for us, but also for those session leaders who were dipping their toes in the water for the first time. Many are now regulars at other conferences. Some have even started their own events. This is a good place to get seen.

And, again, without the hands-on element, would this be the Software Craftsmanship conference, or just A.N.Other software conference where folk dazzle us with BS about stuff they don't even do themselves? For me, this is the heart of the conference: it cuts through all that BS. Don't tell us, show us! And then let us have a go!

So this is the plan:

I won't be running SC2013. Maybe you will. If you're passionate about code, and think you can take the conference to new places, but without cutting out the heart, then I want to hear from you.

Whoever runs it from hereon in will have the freedom to do what they wish with it, as long as they satisfy three basic, non-negotiable criteria:

1. Hands-on coding in every session stays.

2. Bletchley Park is the venue

3. Bletchley Park gets the ticket sales. Everything else (e.g., sponsorship) is up to you.

Of course, if nobody wants to take over, then SC2012 will be the last Software Craftsmanship conference, which would be a real shame, but that's the plan.

I'll be asking people interested in running the conference to make a small pitch to the community at SC2012 (so, yes, you will need someone from your group to be there on the day to represent you), and I'll be asking the community to decide who they want to see running SC2013.

I will also be instituting (against my usual better judgement) a basic constitution for the conference which we'll all need to abide by, including my 3 non-negotiable requirements, as well as a requirement that we repeat this process again in 4 years' time if the conference is still running. In that sense, the conference will become the property of the people who participate and you will become the custodians of it. Which is as it should be.

Let Me Through, I'm A Software Engineer!

A software engineer is having dinner in a fancy restaurant one evening, when a diner on an adjacent table starts to choke on a piece of chicken bone.

With an impressive air of authority, the engineer exclaims "let me through, I'm an expert" and the crowd of concerned people that had gathered around the choking diner dispersed to let him see.

For about a minute, the engineer carefully examines the poor man - umm-ing and arrh-ing - as he gradually starts to turn a worrying shade of purple.

Eventually, with a triumphant air of smugness, the engineer delivers his verdict:

"You see, what you've done here is you've got one hole for eating AND breathing. What you want to do is have two separate holes, each with a distinct function."

Entrepreneurial Programming - The Sixty Four Challenge

All this talk about "lean start-ups" and "bacon entrepreneurs" (or whatever... TBH, I wasn't really paying attention) has got me thinking...

It seems that a little experiment, in the form of a challenge, might be in order. Many people - including people who should know better - continue to assert that quality and getting something to market quickly are a trade-off. It's the old "quick and dirty" school of thought.

If quick-and-dirty is the best short-term solution, then it stands to reason that in a short-term endevour, quick-and-dirty would give you an advantage over Clean Code.

I'm not at all convinced that it would. All the evidence I've seen suggests that the opposite is true.

But I'm not here to tell you ghost stories. How could we put it to the test? Asking a sample of people to start a real tech business and run it in a certain way just for an experiment doesn't seem reasonable. We've all got better things to do with our time. Well, maybe.

But, for a big enough sample, it might be worth investing a chunk of time to answer this question - along with potentially lots of other questions about what is the least we can do to start a successful tech business?

Here's a rough outline of an experiment in entrepreneurial programming I've been kicking around. I'll be interested to know what folk think.

This experiment would be called THE SIXTY FOUR CHALLENGE:

We would create an artificial tech business economy. 64,000 people will be given 64 tokens to spend on tech products and services created by one or more of 64 "tech businesses".

Each tech business is a team of people who get together to create a product or service out of software (e.g., a web or smartphone app).

Each team has no more than 64 person-days (64 x 8 hours) to design, build, sell and support their product or service.

The challenge lasts 64 days from a standing start to the final reckoning. At the end of those 64 days, we would tot up how much money (tokens) each startup has made from our artificial market.

Each start-up has a seed fund of 64 tokens, which they can use to buy things like hosting and professional services from other start-ups (at a negotiated value in tokens/hour or day - so a team made up entirely of web designers could potentially win just by doing web design for other teams, which many would argue is what the web is anyway). Hours worked for other teams would not count against the maximum 64 hours alotted to your team.

We would create special payment gateways and other tools for processing token payments and exchanging tokens between teams, sitting behind which would be an artificial bank that holds all of these accounts and provides transparency to the whole endevour.

You can change - and even completely re-write - the code as many times as you like over the 64 days.

At the end, the final accounts would be totted up and also the source code would be evaluated, and we'd see whether cleaner code = slower start-up. My guess is we would see no clear correlation, and that taking care over code quality would not be a significant disadvantage.

What do you reckon? Answers on a postcard, please.

New Screencast - TDD As If You Meant It

In this short cast I illustrate what I believe is meant by "TDD as if you meant it" (props. to Keith Braithwaite, who invented this workshop format for SC2009).

DISCLAIMER: I am not saying "don't do any up-front design at all". This is an exercise to stretch your refactoring and feedback-driven design muscles.

Towards A More Empirical Understanding of The Effects of TDD (That Really Matter)

There's been a handful of empirical studies done into the effects of Test-driven Development over the last decade.

Looking at the state of the art in this area of research, as a long-time TDD practitioner and coach I'm left feeling less than satisfied at the way these studies were conducted, and therefore the quality of the results.

Firstly, I'm not entirely satisfied that all of the studies were conducted by people who really understood what TDD is. They tend not to mention refactoring, for example. As refactoring is roughly half of the effort in TDD, this seems like a major oversight.

Secondly, studies seem to be largely conducted on groups who are introduced to the disciplines of TDD at the start. I know from years of experience training and coaching teams in TDD that the learning curve can be formidable, and that TDD can take hundreds of hours of good practice to really get the hang of. The idea of giving a group a crash course in it, and then setting them a small exercise from which my study will derive, seems unrealistic. A team that's been doing for it for more than a year is likely to produce measurably different results in both software quality (internal and external) and productivity.

Thirdly, studies do not account for the specific way in which TDD is being practiced within the teams. There are different schools of TDD, and a whole spectrum of possible ways it can be practiced. Team A might be writing tests at a high level, for example, and these tests may make many assertions. Team B might be rigorously applying the "tests should test one thing" rule. Both teams could be following the golden rule of TDD, namely that they don't write production code until a failing test requires it.

And finally, these studies aren't asking the important question; namely, what effect does TDD have on things that would matter to a business? What effect does it have on feature request cycle times? What effect does it have on sustainability of innovation?

Tell your CTO that TDD will reduce bug counts, or that it doesn't cost more to do, and he or she is likely to shrug their shoulders and say "so what?" Tell them that TDD can help reduce cycle times to less than a week, or that teams that do it well are able to sustain a reasonable pace of change for years on the same code base, and they may sit up and take notice.

IT managers are so used to telling businesses they'll have to wait six months to get that feature that marketing needed yesterday, or telling them that they can't have it because it's just too expensive to make changes to a legacy system, then you may be carried aloft like conquering heros if you can offer them a way out of that.

Even though the studies are flawed, though, they still tend to conclude that TDD has benefits. Code that is test-driven tends to be simpler, and have lower bug counts. And there's a real mix of results regarding productivity - so much so that it's reasonable to conclude that TDD has little impact on schedules or development costs in the short-to-medium term. And that's with sample groups who are usually just beginning with TDD.

I consider the study conducted at the BBC by Kerry Jones (now at social TV start-up Zeebox) and myself to be one of the better ones. It's using data comparisons from real-world projects and over a long term (1 year), and the developers participating went through not just a crash course in TDD but a fairly rigorous 6 month peer-learning exercise, with regular weekly practice and a practical TDD skills assessment which they all passed. They were all demonstrably capable of practicing TDD in roughly the same way.

Where we suffered was lack of useful data beyond the code itself. Like most organisations who do software development, teams at the BBC do not know how many person-hours go into different activities, or what the cycle time of feature requests is, or even how many bugs are reported with each release.

Anecdotally, they reported that on one project where the team practiced TDD fairly rigorously right from the start, the frequency of live releases was greater than at any time on any previous project. So frequent, in fact, that it was edging towards what we might recognise as "continuous deployment". Again, anecdotally, we heard reports that if the code passed all of the automated tests, the business was satisfied that it was fit for a release, and that lengthy acceptance testing phases were not considered necessary.

These are just anecdotes, though. We have hard evidence to support our claim that TDD improved code quality, but only the usual ghost stories to support any claims beyond that.

What was frustrating at the time, and this is usually the case, is that all the raw data we needed was probably there somewhere. Project management must surely know how many people put in how many days on each release. They must surely know when a feature was first added to the backlog, and when the working code went live.

Couple this with a bug-tracking database, a source code repository and the usual Scrum/Kanban data and I would have everything I need to tie it all together. The hardest piece of the jigsaw to find is how the code is being written. For that, you really need to see it being written. Just as it is with history, there's only so much you can learn from examining ancient artifacts. There's no substitute for a high-fidelity account from somewhere who was there.

If I was conducting an academic study on this now, I'd ask for several sources of useful data:

1. The source code repository containing a complete version history
2. The defect tracking database associated with that code
3. The complete project history (release/iteration plans & actuals, use case/user story estimates & actuals, backlogs, burndowns, staffing etc)
4. Something that would allow me to see code being written (e.g., screencasts made of developers working on the code, IDE session recordings)

Using this data, I could visualise the arc of a software product over its lifetime up to now and look for any correlations between TDD and other coding practices and the shape of the arc.

Software has a tendency to plateau, sooner or later. At some point, the cost of changing it outweighs the benefit of doing so. At this stage, we have a legacy system: namely one that is critical to the continued operation of a business while simultaneously being a significant impediment to the evolution of that business. Like old age, every software system has this coming. And it's arguably the default state of the majority of systems in use today. Which means that it's the default state for the majority of businesses that rely on legacy systems.

But some software reaches this plateau long before others, just as some people age faster than others. If we can postpone the inevitable for longer, our software can live a more active and fulfilling life for longer, and our businesses can stay adaptive using those systems for longer.

It's my theory that business evolution exhibits a sort of punctuated equilibrium. They tend to spend most of their time in prolonged phases of equilibrium, when things don't change much, and then suddenly - due to a new opportunity or threat or some other sudden change in the conditions that surround them - they frantically reinvent themselves to adapt and to stay alive through another prolonged phase of equilibrium.

Quite often, it's these short phases of organised panic that tend to give rise to the ambitious new IT projects, as businesses discover the prohibitive cost of teaching their legacy systems new tricks. It's often accompanied by major structural changes within the organisation and massive upheaval.

This isn't the best way to build a "learning organisation". The same principle applies to major "big bang" software releases and major organisational change programmes - when we change 1,001 things at once, we lose the ability to learn one lesson at a time. Maybe 499 of those changes were the wrong changes, but rolling back 499 changes without throwing the baby out with the bathwater is fiendishly difficult. Like software, businesses succeed or fail as a whole.

It falls on us to develop software in a way that supports continuous, sustainable business evolution and to help build real learning organisations - organisations that can learn one lesson at a time, and sustain the pace of learning indefinitely.

It is my belief that programming practices like TDD, refactoring and continuous integration can help to achieve this. But it's just a belief, based on wishy-washy personal experience. I have seen a ghost. Now I need to get some instruments in there, collect some hard data, and prove it to the rest of the world.

Digital Future - I Find It Hard To Mourn The Loss Of The "Rock Star"

Talks this morning about that thorny problem of how to make money selling digital copies of things that are just too darned easy to digitally copy.

Music's the classic example. Here's a brief history of the music industry:

50,000 BC - Ugg finds that the sound of banging two rocks together is pleasing. Ugg like bang rocks.

25,000 BC - Ugg finds that other people like the sound of two rocks being banged together, and that - while they may lack the requisite rock-banging skills to do it themselves - they are willing to exchange food, fire and sexual favours if Ugg will bang the rocks and they can sit and listen. Ugg like bang rocks for tribe.

24,999 - 1876 AD - that was the predimonant model (or near enough) in the music industry - people paying other people to bang rocks, bang drums, twang strings and make blowing noises through tubes so that they could listen. Ugg like steady income. Ugg happy.

1877 - 1989 AD - an idiot called Thomas Edison went and blew the bottom out of the banging-rocks-for-people market when he invented the phonograph. This was a technology that allowed the sound of rocks being banged together to be recorded and duplicated as many times as we liked. Anyone who had a phonograph could play these recordings in their own home, and no live rock-banger was required. A lot of rock bangers lost their livelihoods. But a lucky few, whose recordings they were, became very, very wealthy. Ugg like country estate with own salmon lake.

1989 AD - another idiot called Tim Bernard-Matthews (or something like that) invented a medium that would make it possible for digital recordings of people banging rocks together to be distributed electronically - and therefore incredibly inexpensively and quickly - to any connected device in the world. Making and distributing high-quality copies had, up to this point, been difficult and expensive. Suddenly it was easy and cheap. So easy and cheap that very quickly a lot of people realised they could make and distribute copies themselves, and not pay the rock bangers, their record labels or distributors a penny. Ugg no like bankruptcy proceedings. Ugg sad.

The problem, as I see it, is this. When I uploaded an "album" of my music to just one music-selling web site (though I was giving it away free), within 24 hours it was on roughly two dozen filesharing web sites. Within a week it was on hundreds. And some of them were charging money to download tracks from my free album. Within hours of Swedish metallers Meshuggah releasing their highly-anticipated Koloss album, tracks - and even the entire album in glorious HD sound - were turning up on YouTube. It seems the moment a digital copy is out there, then people are copying it and distributing it illegally. And you can police it all you want, but just like King Canute, we cannot command the tide to turn back.

So when the question is asked "how do we make money from music?", the wrong answer is "by selling copies of it". That business is dying, and nothing will stop it, short of undoing 20 years of technological progress.

There's a flip side to this. Digital rock banging may be bad news for rock-banging star Ugg, but it's fantastic news for all the unsigned and unloved rock bangers out there who never got the breaks Ugg did. Digital recording and distribution now makes it much easier and much cheaper to write and record music of a high quality. And the Web makes it much easier for musicians to build a following without having to sign over their souls to a record label. The music business will naturally redistribute itself from a handful of global corporations controlling most of what we hear, to a million cottage industries recording and releaseing a much wider diversity of music.

Musical genius Frank Zappa anticipated this. He had many issues with major labels in the 1960's and 70's, culminating in his forming his own label and handling distribution (usually by mail order) through his own business in the 80's and early 90's. And while Zappa never approached anything like the commercial success and wealth of Paul McCartney or Michael Jackson, for someone who wrote some pretty avante garde tunes, he still made enough money to live well, support his family, employ dozens of people, kit out a very high-tech studio, make several movies, and even hire prestigious orchestras to play his works.

How did Frank do it? Well, firstly, he built a very loyal following by writing music that wasn't a lowest-common-demoninator compromise. In the world of the multi-platinum-selling album, you aim for Joe Average. In a world of a million artists catering to a billion tastes, you focus your aim and find a niche. Being quite unlike anybody else is a major advantage in the age of digital media.

Secondly, Frank had a knack for marketing and publicity. He pioneered the use of billboards to advertise the first Mothers Of Invention album. He cultivated a striking image and is still to this day the undisputed master of the soundbite - arguably the most quotable man in rock. As his career developed, Frank employed all sorts of devious means - most notably comedy - to help his complex, modern music find an international audience. Frank found his audience even in countries where Frank Zappa's music was not allowed. He had a huge and devoted following in the former Soviet Union.

Thirdly, Frank could run a business. He managed his tours so well that, unlike most rock artists in the 70's and 80's, he actually made a profit from them. The size of his tours - often playing in local stadiums - ran counter to his small, niche stature in record sales.

And finally, and most importantly, Frank was a perfectionist and a workaholic. His live bands were the most rehearsed, most disciplined you would ever see. The only band I've seen come close was playing Frank Zappa's music and being led by his son, Dweezil. I kid you not: go see Zappa Plays Zappa and you'll be seeing the best live band you're ever going to see in any genre of music. Frank had high standards in all aspects of the music, and he wrote and wrote and wrote constantly, right up to his untimely death in 1993.

With any luck, the age of one-size-fits-all copy-and-paste music is coming to an end. In a fully digital era, innovation, originality, high standards, hard work and skillz will mark out those artists who will carve out a good living. The rest can go audition for X Factor.

As for the problem of illegal copying... As I see it, once a digital copy hits the market, all bets are off. Copies will be made and distributed. There's nothing we can do to stop it.

Which makes me wonder whether a new way of financing music isn't called for. You can't make a digital copy without having something to copy it from. If you're very careful about data security in the recording process, it should be possible to keep a digital copy from finding its way onto the Net until you're ready for that to happen. And perhaps the right time for the digital files to go public should be after you've at the very least recouped your costs, and hopefully made a profit. Once it goes out, you sell it the good old-fashioned way, secure in the knowledge that your bills have been paid.

The Web can help you build a following and find your audience. Once you've found them, you could find some innovative way of financing releases. For example, you could ask people to buy "shares" in it, or offer other funding options, and withhold the actual media until you've cleared your target. It's becoming common for creative projects to be funded this way, so why not go the whole hog, make the album, get it ready for release, and then let people listen to a small taster and decide if they'd like to "invest" in making the release happen.

Crowdsourcing is a potential way forward, in my opinion. Eventually, the music-buying culture may shift from punters purchasing units to patrons investing in new works. Artists will make their money from a smaller, but much more involved and engaged audience, one that has a stake in the outcome.

But many, many more of us - amateurs like me - will bang rocks together just for the sheer hell of it. Only now, it's possible for our private rock banging in our own caves to reverberate around the world. Personally, I find it hard to mourn the days when that wasn't possible.

Enough With The Movements! Movements Are Stupid.

I've been around the block a few times as a software developer, and as such I've witnessed several movements in the industry come and go.

Each movement (object technology, patterns, component-based, model-driven, Agile, service-oriented, Lean, craftsmanship etc etc) attempts to address a genuine problem, usually. And at the core of every movement, there's a little kernel of almost universal truth that remains true long after the movement that built upon it fell out of favour with the software chattering classes.

The problem I perceive is that this kernel of useful insight tends to become enshrouded in a shitload of meaningless gobbledygook, old wives tales and sales-speak, so that the majority of people jumping on to the bandwagon as the movement gains momentum often miss the underlying point completely (often referred to as "cargo cults").

Along with this kernel of useful insights there also tends to be a small kernel of software developers who actually get it. Object technology is not about SmallTalk. Patterns are not about frameworks. Components are not about COM or CORBA. Model-driven is not about Rational Rose. SOA is not about web services. Agile is not about Scrums. Responsibility-driven Design is not about mock objects. Craftsmanship is not about masters and apprentices or guilds or taking oaths.

In my experience, movements are a hugely inefficient medium for communicating useful insights. They are noisy and lossy.

My question is, do we need movements? When I flick through my textbooks from my physics degree course, they don't read as a series of cultural movements within the physics community. What is true is true. If we keep testing it and it keeps working, then the insights hold.

What is the problem in switching from a model of successive waves of movements, leaving a long trail of people who still don't get it, and possibly never will, to a model that focuses on testable, tested, proven insights into software development?

I feel for the kid who comes into this industry today - or on any other day. I went through the exact same thing before I started reading voraciously to find out what had come before. They may be deluged with wave after wave of meaningless noise, and every year, as more books get published about the latest, greatest shiny thing, it must get harder and harder to pick out the underlying signal from all the branding, posturing and reinvention of the wheel.

You see, it's like this. Two decades of practice and reading has inexorably led me to the understanding that very little of what I've learned that's genuinely important wasn't known about and written about before I was even born. And, just as it it is with physics, once you peel away the layers of all these different kinds of particle, you discover underlying patterns that can be explained surprisingly succinctly.

For those who say "oh, well, software development's much more complicated than that", I call "bullshit". We've made it much more complicated than it needs to be. It's a lot like physics or chess (both set-theoretic constructs where simple rules can give rise to high complexity, just like code): sure, it's hard, but that's not the same as complicated. The end result of what we do as programmers can be massively complicated. But the underlying principles and disciplines are simple. Simple and hard.

We do not master complexity by playing up to it. By making what we do complicated. We master complexity by keeping it simple and mastering how software comes about at the most fundamental level.

Logic is simple, but algorithms can be complex. A Turing Machine is simple, but a multi-core processor is complex. Programming languages are simple, but a program can be highly complex. Programming principles are simple, but can give rise to highly complex endevours.

Complexity theory teaches us that to shape complex systems, we must focus on the simple underlying rules that give rise to them. At its heart, software development has a surprisingly small core of fundamental principles that are easy to understand and hard to master, many of which your average programmer is blissfully unaware.

True evolution and progress in software development, as far as I can see, will require us to drop the brands, dump the fads and the fashions, and focus on what we know - as proven from several decades of experience and several trillion lines of code.

Stop Chasing Exit Strategies And Start Chasing Great Software

Oooh, the shiny - it dazzles, it excites!

Today it was announced in the "Technology News" (though it's rarely about technology these days - they should just call it "Corporate Law News") that police state-friendly social networking site Facebook is acquiring pointless image filter service Instagram for $1 billion.

Now, I had a play with Instagram, and from what I could see of its design, they may as well have just had a big button with "Click here for Exit Strategy". But that could be said of so very many start-ups now.

Every software application should start with an overriding goal - a reason for it to exist. But increasingly, that goal seems to be to sell it to one of the big companies for a gazillion dollars, and all other concerns along the way are mere details. More and more products seem to solve no problem, and often they seem to have not just disinterest in their users' needs, but actual contempt for them.

My goal is to create better software (and, more recently, to try and help other people create better software). Most important to me is what value software brings to the people who use it.

I'm increasingly becoming frustrated by developers who just seem to be chasing the Almighty Dollar (or Pound or Yen). It seems to lead to empty software. Software that is, to all intents and purposes, nothing more than a lottery ticket. Issues like whether or not it solves the customer's problems or whether or not it enhances their lives or their jobs in some way take a back seat to whether or not we have the right exit strategy.

A classic example of this kind of thinking is the very damaging advice being propogated among the tech start-up community that the software that powers your new business only needs to last until you find a buyer. That's a perspective on "good enough" that I find dishonest and irresponsible. If a car company only built cars to last long enough to sell their business, the managers and engineers involved could be looking at custodial sentences.

If "good enough" is not driven by your users and their needs, then you should pack up and get out of the software business. You don't belong here. Go start a homeopathy business or something.

And the biggest irony is that, no matter how well they're run, the vast majority of tech start-ups will never achieve their exit strategy. Success on the scale of Facebook and Instagram is vanishingly rare, and almost entirely about being in the right place at the right time. So you'll almost certainly be stuck with that code you didn't take enough care over, and those users you didn't listen to for years after you thought you'd be sunning it up on a tropical beach somewhere while some mug like Zuckerberg deals with the consequences.

I'm a software developer, not an entrepreneur. What I care about is doing the best possible job of satisfying people's needs with the software I contribute to. And my primary focus is the end user. The game's afoot when we start getting feedback from real users. That's when we really start to learn what works for them and what doesn't.

And that's why I believe that it's so very important to be able to sustain the pace of innovation for as long as possible - years or even decades - on a software product, so we can keep learning and keep improving the product. I don't profess to know what users want, and I don't profess to know how to build a $ billion business. But I do know that companies that can sustain the pace for longer will eventually outlearn their competition and build better products and services. I've seen it many times (and watched the consequences of not doing it many more.)

Whether you achieve your exit strategy or not, there's an advantage to sustainable innovation. If your exit strategy's going well, it can get you there faster, and if you're going to be stuck with this technology for good, then it's definitely a wise precaution. At least then your going concern can keep going.

So my philosophy is to chase great software, and I'll gladly leave chasing exit strategies to the likes of Instagram.

Programming For Kids & Social Mobility

On the subject of getting more kids programming, there's a very important aspect to all of this that doesn't get much mention, which is the potential for programming skills to lift children out of poverty.

Social mobility in the UK, and much of the developed world, is on the decline. After WWII, we had a brief golden age of social justice and mobility, when the UK government felt that our war heros returning from 6 years of hell deserved to come back to a county fit for such heros.

Inequality in Britain before the war was a major problem. Being poor could be fatal, literally. Men and women not born into money were expected to know their place, and if you were born into service, you died in service. If you were lucky.

Post-war Britian opened up further and higher education, paying fees and subsidising living costs for students and making it possible for the sons and daughters of coal miners to study and become doctors, lawyers, scientists and even Prime Ministers.

With the withdrawal of state-subsidies in education, including living allowances designed to bridge the gap between school-leaving age (16) and higher education - a lifeline to kids from families who could not keep supporting their children once they were old enough to leave home - this process is in reverse.

We have a million unemployed between the age of 18 and 24, and I genuinely fear for a future blighted by a disenfranchised generation and by a resurgent elite voting themselves an even bigger slice of the pie, with the majority of our current government drawn exclusively from top private schools and Oxford or Cambridge, and most of them being millionaires (born into wealthy families, not self-made.)

I do not believe in a Just World. I do not believe that the unemployed and the poor are unemployed and poor because they're not as clever as I am, or not as hard-working. I believe that I am lucky, they are less lucky, and people like David Cameron are incredibly lucky. Brains and brawn have nothing to do with it.

Which means that among the households on the lowest 10% of incomes there's every bit as much potential as there is among the top 10%. Kids may aspire to be politicians or lawyers or bankers, but the fact is that we still - to our shame - have many high-paying professions that are snobs when it comes to who they let in.

But there's one high-paying profession that doesn't seem to care all that much whether you have "good breeding". And that's ours. We may even be the most meritocratic profession of them all. I don't have figures for that, but I've seen so many examples of people from lower-middle class and working class backgrounds earning six-figure salaries working for some fairly prestigious organisations.

There's an opportunity to join the dots into a perfect circle here. Software development is meritocratic and open to pretty much anyone who can prove they can do it. The cost of entry is comparitively very low. All you need is a half-decent computer and access to tools and learning resources, many of which are free. After that, you're just investing your time.

Increasingly, more and more of us agree that the best way to become a great developer is to learn from real experience, and the necessary educational/theoretical material is also becoming freely available thanks to MIT and other great Open Learning pioneers.

Talk of apprenticeships for software developers - real long-term ones, and not these bizarre commercial arrangements that have been popping up of late where apprentices are expected to pay, for some reason - continues to gather momentum. The principle that someone who geninely wants to be a professional software developer should be able to learn without incurring any debt is both realistic and desirable.

There are hundreds of thousands of kids in school now for whom the prospects look grim. Their chances of lifting themselves out of poverty are lower than they've been for three generations. And at the same time, the UK software machine needs feeding faster and faster. There's an opportunity here for a portion of these children to fill that hole and enter a profession that could completely transform their prospects.