Software People Inspiring

Music By Programmers - Week #1 Update

The album to raise money for maths and programming workshops at Bletchley Park and The National Museum Of Computing has been out for a week now.

And what a week it's been! Things kicked off on the previous Friday with an article that ended up being the BBC Tech News number two story, getting a link on the news home page, which generated a lot of interest.





Then on Monday we were assisted by a generous tweet from Stephen Fry.





Together with bags of other social media activity, and coverage by PC Pro, The Register and other noteworthy websites, the buzz was enough to propel Music By Programmers into the download bestseller charts on Amazon, iTunes and Google Play.





The limited edition CD went on sale around lunchtime on Monday, and sold out on Tuesday.

The week ended with interviews for other web news sites, as well as BBC local radio, about these computer programmers who were "storming the charts".

Naturally, the web having the short attention span that it does, we've tailed off quite spectacularly since Friday - though as of writing we're still in Amazon's Top 40 Dance & Electronica albums. As the saying goes, we've had our 15 megabytes of fame. Now the real work starts!

Of course, being pop stars for a week isn't really the point of it all - gratifying though it is to see something you've helped create up there among the Daft Punk's and the will.i.am's for a short while. Something to tell the grandchildren. (If I never have granchildren, I'll borrow someone else's and tell them.)

A huge "thank you" if you bought the album and spread the word. With no marketing budget and no label behind us, we're relying completely on word-of-mouth. Without your support, none of this would be possible.

How this all translate into sales, and therefore money raised, we shall have to wait and see. It can take months to get sales figures - and money - from the online retailers. My feeling is that we're well on our way to achieving our target, though.

But I doubt we're there yet, so we still need your support to make our goals happen. If you've not bought your copy yet, please consider downloading it today. Roughly £4-5 from every sale goes directly to these educational projects, so every download counts.

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.

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.

Announcing A Powerful New Framework - Programming Language

Programming Language is a powerful new framework that enables developers to quickly and easily handle Dependency Injection, Inversion of Control, Model-View-Controller and many other common design problems.

Programming Language is easy to use and takes no time to master. There's a version of Programming Language for pretty much every platform - Java, .NET, Linux, iOS etc. You name it, there's a Programming Language for it.

Programming Language is completely object-oriented (providing you're working on an OO programming platform, of course.)

Here are just a couple of examples that illustrate the power and flexibility of the Programming Language framework.

Dependency Injection in Programming Language for Java



In this example, we use Programming Language to provide a mapping between a method parameter, declared as an instance of some interface Abstraction, and a concrete implementation of abstraction. These mappings are stored in a special, easily configurable file called a "Java class". The client method can now access features of Implementation without binding directly to it, and we can easily substitute Implementation for any other class that implements the Abstraction interface (e.g., for the purposes of mocking or stubbing it in unit tests).

Inversion of Control in Programming Language .NET



In this second example, we use the advanced IoC feature of Programming Language to define the explicit order of workflow in a user interface using a special mapping file called a "C# class". This gives us greater flexibility over the workflow. If we want to change the order of events, we simply edit the special mapping file, recompile and - bingo!

Of course, these are just two simple examples. But I'm sure even the least experienced developers among you will already see the incredible potential of the Programming Language framework.

Here's a list of some of the other powerful features accessible through Programming Language:

* Factories
* Builders
* Observers & Events
* Interpreters
* Undoable Commands
* Adaptors
* Proxies
* Persistence
* Role-based Access Control
* And many, many more.

You can download the latest stable build of Programming Language here.

Ethical Shopping - Gamification I Could Get Behind

I'm a bit, y'know, "weeurgh" when it comes to the subject of gamification. It just sounds too much like something out of a Philip K Dick novel.

But, putting aside the unwitting self-enslavement of consumers, there's one kind of gamification I might support. I think we could "gamify" ethical buying.

Imagine we're all carrying barcode scanners on us. Which many of us now are, it seems. I'm in the supermarket, and I'm presented with a whole shelf of different products that do pretty much the same thing, and I'm deciding which one to buy. The information I have in front of me comes from the retailer and from the manufacturer. How much does it cost? What does the manufacturer tell me I can expect from it?

It's all a bit one-sided, really. What I don't see is the carbon footprint of each product. Or the working conditions that went into making it. Or the amount of money the manufacturer spent lobbying congress to get laws concerning the testing and safety of that product relaxed.

What if I could scan that product's barcode and find out a bunch of stuff the retailer and manufacturer don't want me to know? Would that affect my decision? Maybe Washing Power X is 20p cheaper than Washing Powder Y, but what if I knew that the factory where they made Washing Powder X had been fined for dumping toxic chemicals into the local river?

If I was of a mind to shop more ethically, it might be of interest to me to have to hand information like that while I'm shopping. And databases full of that kind of information do exist.

I might even welcome a bit of friendly competition to see if I use my household budget more ethically than my friends and family. Using barcodes, it might be possible to assign an Ethics Score to my shopping basket, and if I wanted a better score I could visit their web site to look for better alternatives to the products I'm buying.

I'd already kicked this idea around for ethical investing - creating a browser plug-in that superimposes information about a company over its stock symbol so we can see at a glance how it scores on things like workers' rights, the environment and so on.

Hopefully, armed with extra knowledge about products, our inherent instinct not to be total and utter bastards might create a sort of adaptive pressure that gently modifies our buying (or investing) behaviour over time, skewing the markets towards better conduct.

That's a kind of gamification I might be able to get behind.

We Cannot Afford To Underinvest In UK Computing

A company director would understand that they have to invest proportionately in marketing their business. Typically, businesses spend about 5% of their annual turnover on marketing just to stand still. And considerably more if they're trying to build their business from a standing start or if they're launching major new products.

If you were running a £1 billion-a-year business, you might invest £50 million every year on marketing. If you were in charge of the marketing department of that business, and they gave you just £50,000 to market their £1 billion-a-year business, you'd assume they'd grossly miscalculated. Or you'd assume they know nothing about marketing.

You have to speculate to accumulate, and you have to speculate proportionately. The amount you invest usually needs to be pitched to match the size of the problem you're trying to solve. £50,000 would be a very healthy marketing budget for a business turning over £1 million a year. But it's a drop in the ocean for a company turning over £1 billion.

What would likely happen if you invested a disproportionately small amount into marketing your business? Your business would shrink.

So when it comes to deciding how much we should invest in the future of UK computing, we need to first ask "what is the size of the problem?" How much is computing worth to UK plc?

My issue is this: when we hear about computing education and the UK's computing industry in the mainstream media, in government and in other places where these decisions are shaped, the scope of the discussion is limited to a tiny fraction of our real "digital economy". While we agonise over the future of computer games development in the UK, we'd do well to remember that computing plays a large part in the fortunes of major supermarket chains whose annual profits can outstrip our gaming industry by themselves.

It's easy to forget that supermarkets are a product of the computing age, and that their operational effectiveness and competitiveness is closely tied to their ability to create, adapt and evolve their bespoke IT systems. Tescos and Marks & Spencers need skilled programmers every bit as much as the games developers do.

The reality is that there probably isn't a single company in the FTSE100 index for whom that isn't now true. The combined economic value of those 100 public companies runs into hundreds of billions, and the impact of computing on their bottom lines can be profound. If Acme Plc want to change the way they handle sales and fulfilment, chances are they won't be able to do it without changing their systems. In comparison, the economic impact of a delay in shipping the next whizzy shoot'em-up is chickenfeed.

Then there's the critical importance of computing in UK science and engineering. These days, most scientists don't sit in labs with tests tubes and bunsen burners. They sit at computers, writing software to analyse and interpret data and simulate the real world. Can CERN operate without computers? Not at all. Not even for a moment.

Here's the real bottom line for UK computing. WIthout it, we go right back to the 1940s. And so does our economy. Seven decades of amazing scientific advancement, progress in standards of living, economic growth and prosperity, the only rational explanation for which is computers. It's certainly not because we've been getting smarter or working harder.

The real value of computing to the UK is incalculable. It has seeped into every aspect of our lives and transformed many parts of our existing economy, as well as creating entirely new ones that were impossible without computers.

Strategically, computing is more important to UK plc than anything else. That may sound like a bold claim. But if you sit down and do the maths, it's undeniably true. Whatever we're planning for the future, it will almost certainly rely on computing. And there's no putting the genie back into the bottle.

When we miss this much, much bigger picture and focus in on computer games and digital media, we risk massively underinvesting in our digital future, by several orders of magnitude. Investment in computing education, apprenticeships, help for tech start-ups and all that good stuff, if measured in the millions of pounds, would be like a £1 billion-a-year company investing £50,000 a year in marketing. The net effect is that our economy will shrink.

I don't understand why politicians and business leaders and pundits don't get this. Computing is a very real limiting factor on every aspect of our economy. If we cannot nurture the talent and the skills required to build this future economy on the scale required, then that future won't happen on the scale we need. It's really as simple as that.

At this point, recession or not, we must consider investing billions every year into computing education. We have a huge amount of ground to make up that we've lost over the last two decades. A genuine UK computing renaissance isn't going to happen on a shoestring budget.

Money must be found to put a qualified computing teacher - y'know, one who can actually really program - in every single school, and they must be paid enough to ensure that some coding job in the City won't lure them away. My guess is that will cost in excess of £1 billion a year.

Money must be found to give every child a programmable computer when they start school. That could run into £50 million a year (thanks to the Raspberry Pi).

Money must be found to create and operate high quality learning resources, such as web sites, videos, TV shows and books, and make them freely available to children and schools. We could be talking about another £200M+.

Funds must be created to finance and encourage UK tech start-ups and ensure all that new talent doesn't leave the country. We've been historically great at research and development and inventing cool stuff, but absolutely hopeless at turning that ingenuity and creativity into British businesses. Intellectually, we punch well above our weight. it's just a shame that we're such entrepreneurial weaklings. A fund of several billion pounds a year to invest in good tech start-ups and growing tech businesses might help ensure that UK software businesess can grow beyond the point where they just become fodder for foreign buyers.

And maybe a lot of these tech start-ups won't go the distance, but while they're trying, it will keep all that talent productively busy and professionally satisfied ready for the day when those lucky few grow into our own versions of Google and Microsoft. Or they'll take their places in the wider economy, helping banks and supermarkets and rail operators and hospitals and TV channels to stay ahead of the competition and keep UK plc ticking along for future generations.

At this critical time, we must not skimp and we must not falter. We cannot afford to underinvest in our computing future.

A Blog Post For Your Kids - Why I'm Very Glad I Learned To Program

Computers are everywhere.

I'm not just talking about those things with screens and keyboards and mice that you have at home, or in the classroom, or at your Dad's office.

There are computers in your mobile phone, translating 1's and 0's that are sent through the air into your grandmother's voice reminding you that grandad's birthday is coming up, and telling you not to buy him socks again this year.

There are computers in your TV sets, translating 1's and 0's that have been beamed from a transmitter, or sent down a fibre-optic cable under the street outside your home, into moving pictures of Matt Smith telling us that "bow ties are cool" (which they are, by the way.)

There are computers in the engine of your Mum's car, continually monitoring how it performs and making decisions about how much petrol to inject from moment to moment. It's computers that help your Mum get more miles to the gallon - which means less pollution and destruction to the environment, and more money for Wagon Wheels. (Wagon Wheels are cool.)

There are computers on board the airliner that takes you to an exotic faraway holiday destination (like Coventry, for example), carefully controlling thousands of different flight parameters many times a second to help ensure a safe and comfortable journey.

There are computers in your local supermarket - thousands of them - continually updating stock information every time an item is scanned at the checkout, automatically reordering items from suppliers when they run out, and doing a thousand other things that need to be done every day to run a supermarket.

There's a computer inside your CD player, your toaster, your microwave oven, and many other household electronic and electrical items.

There are computers in hospitals, tirelessly watching over critically ill patients day and night to ensure doctors know as soon as their heart rate, or their blood pressure, or their temperature becomes abnormal, and alerting medical staff as soon as something appears to be wrong. They also have computers that can see right through you, building accurate 3-dimensional models of your internal organs - brain, heart, lungs, kidneys, bones, muscles, blood vessels, shoes etc - so doctors can diagnose problems without having to cut you open, and can plan operations with life-saving precision in advance.

There are computers in recording studios that capture and store your music, and can allow producers to manipulate sounds - vocals, guitars, keyboards, drums - in ways that were totally unimaginable 30 years ago. And the finished music can be distributed as 1's and 0's to anywhere in the world almost instantly and for free, thanks to computers.

There are computers on film sets, controlling the motion of cameras so that every zoom, every dolly, every pan can be replayed with pinpoint accuracy over and over again, which is what gave us Star Wars and virtually every major blockbuster movie since. And computers are used to capture performances of actors that can then be applied to completely digital characters like Gollum in Lord Of The Rings, King Kong, and every single character in the new Tin-Tin picture. Thanks to computers, an average-height London actor can convincingly play a giant gorilla who climbs the Empire State Building.

There are computers in science laboratories, that store data from experiments and perform extremely complex calculations that have revealed a whole world of things that were impossible to see before. We can only detect planets circling distant stars thanks to the immense number-crunching power of computers. We can only catalogue the hugely complex human genome thanks to the extradordinary data storage and retrieval power of computers. We could only ever hope to detect a message from an intelligent alien civilisation using computers to process the billions of radio signals streaming down to us from deep space, and pick out that one artificial signal from all the natural ones. In the last 50 years, we have made more scientific advancements than we did in the previous 4,000 years, thanks largely to the power of computers.

Thanks to computers, our power to collect, create, analyse, search and share information - in all its different forms, from text to sound to pictures to movies, and a thousand million other kinds of data - has doubled every couple of years, and will continue to expand at that rate for decades to come.

You hold more computing power in your hand when you use a smartphone than was used to make the dinosaurs in Jurassic Park just two decades ago. In 1992, your smartphone would have been called a "supercomputer". In twenty years time, your smartphone will have more computing power than was used to create all of the computer-generated scenes in Avatar.

Imagine what you could do with that kind of computing power!

That's what I do. I'm a computer programmer. I write the programs that these computing devices run. I spend my life imagining ways to apply this ever-increasing computing power to solving people's problems and making their lives better.

I've written all kinds of programs, for all kinds of computers.

I've written programs that help people to design better electronic circuit boards and even to make better computers (yes, we use computers to design computers, which is one of the reasons why computers keep getting better and faster and smaller.)

I've written programs to help people find jobs over the Internet. I've written programs for banks, for supermarkets, for mobile phone companies, for TV and film companies, for law practices and even for software companies (yes, programmers use computer programs to write computer programs - and as those programs get better, we get better at writing programs, which is why programs keep getting bigger and more sophisticated.)

In my spare time, I've written programs just for myself that anyone can download and use for free, and, if they want, they can add to these programs to make them better. Many computer programmers just want to help people, and we are famously keen on sharing our own programs with anybody that wants to use them.

Millions of people have used programs I've contributed to; all kinds of people from all around the world. Programming is a great way to touch lots of people's lives, and to change the world just a little bit for them - hopefully making it better!

Think about the programs you use and enjoy. Perhaps you love to play games on your XBox or Nintendo Wii. The people who wrote those programs take great care and pride in entertaining you while you play the game. They create amazing and fantastical worlds for you to explore and enjoy, and it's all generated from inside a little box that most of us have in our homes or classrooms or offices.

That's what I love most about being a programmer - anyone can do it. If you have access to a personal computer, you can write your own programs. You can create your own games, your own worlds, and then share them with friends around the world. A generation ago, this was unimaginable.

That's why I started programming. I was at school when the first home computing revolution happened in the early 1980's. Computers like the Sinclair ZX81 and ZX Spectrum, the Commodore 64 and the BBC Micro - the BBC had their own brand of computer back then - started appearing in people's homes. These were very simple, basic computers compared to what we have today.

In my house, we had a Commodore 64, which boasted a tiny 64 kilobytes of usable memory - that's about 50,000 times less memory than your home computer probably has today. But, with a bit of cunning and a lot of hard work, people were able to write pretty fun and interesting programs using just those 64KB of Random Access Memory - especially games. Lots of games!

The thing was, you didn't have to just play games on your Commodore 64, you could write games, too. And lots of kids did. Some of the games kids wrote for their home computers were so good that they sold them, and built their own computer game empires right there from their bedrooms.

Many of those kids are programmers today. We got bitten by the bug of writing our own programs, and have been in love with programming ever since. And although many of us aren't writing games today, we are writing programs that are changing the world in all sorts of other ways.

And that's why I'm very, very glad I learned to program.

Continuous Delivery is a Platform for Excellence, Not Excellence Itself

In case anyone was wondering, I tend to experience a sort of "heirarchy of needs" in software development. When I meet teams, I usually find out where they are on this ladder and ask them to climb up to the next rung.

It goes a little like this:

0. Are you using a version control system for your code? No? Okay, things really are bad. Sort this out first. You'd be surprised how much relies on that later. Without the ability to go back to previous versions of your code, everything you do will carry a much higher risk. This is your seatbelt.

1. Do you produce working software on a regular basis (e.g., weekly) that you can get customer feedback on? No? Okay, start here. Do small releases and short iterations.

2. How closely do you collaborate with the customer and the end users? If the answer is "infrequently", "not at all", or "oh, we pay a BA to do that", then I urge them to get regular direct collaboration with the customer - this means programmers talking to customers. Anything else is a fudge.

3. Do you agree acceptance tests with the customer so you know if you've delivered what they wanted? No? Okay, then you should start doing this. "Customer collaboration" can be massively more effective when we make things explicit. Teams need a testable definition of "done": it makes things much more focused and predictable and can save an enormous amount of time. Writing working code is a great way to figure out what the customer really needed, but it's a very expensive way to find out what they wanted.

4. Do you automate your tests? No? Well, the effect of test automation can be profound. I've watched teams go round and round in circles trying to stabilise their code for a release, wasting hundreds of thousands of pounds. The problem with manual testing (or little or noe testing at all), is that you get very long feedback cycles between a programmer making a mistake and that mistake being discovered. It becomes very easy to break the code without finding out until weeks or even months later, and the cost of fixing those problems escalates dramatically the later they're discovered. Start automating your acceptance tests at the very least. The extra effort will more than pay for itself. i've never seen an instance when it didn't.

5. Do your programmers integrate their code frequently, and is there any kind of automated process for building and deploying the software? No? Software development has a sort of metabolism. Automated builds and continuous integration are like high fibre diets. You'd be surprised how many symptoms of dysfunctional software development miraculously vanish when programmers start checking inevery hour or three. It will also be the foundation for that Holy Grail of software development, which will come to later.

6. Do your programmers write the tests first, and do they only write code to pass failing tests? No? Okay, this is where it gets more serious. Adopting Test-driven Design is a none-trivial undertaking, but the benefits are becoming well-understood. Teams that do TDD tend to produce mucyh more reliable code. They tend to deliver more predictably, and, in many cases, a bit sooner and with less hassle. They also often produce code that's a bit simpler and cleaner. Most importantly, the feedback we get from developer tests (unit tests) is often the most useful of all. When an acceptance test fails, we have to debug an entire call stack to figure out what went wrong and pinpoint the bug. Well-written unit tests can significantly narrow it down. We also get feedback far sooner from small unit tests than we do from big end-to-end tests, because we write far less code to pass each test. Getting this feedback sooner has a big effect on our ability to safely change our code, and is a cornerstone in sustaining the pace of development long enough for us to learn valuable lessons from it.

Now, before we continue, notice that I called it "Test-driven Design", and not "Test-driven Development". Test-driven Development is defined as "Test-driven Design + Refactoring", which brings us neatly on to...

7. Do you refactor your code to keep it clean? The thing about Agile that too many teams overlook is that being responsive to change is in no small way dependent on our ability to change the code. As code grows and evolves, there's a tendency for what we call "code smells" to creep in. A "code smell" is a design flaw in the code that indicates the onset of entropy - growing disorder in the code. Examples of code smells include things like long and complex methods, big classes or classes that do too many things, classes that depend too much on other classes, and so on. All these things have a tendency to make the code harder to change. By aggressively eliminating code smells, we can keep our code simple and malleable enough to allow us to keep on delivering those valuable changes.

8. Do you collect hard data to help objectively measure how well you're doing 1-7? If you come to me and ask me to help you diet (though God knows why you would), the first thing I'm going to do is recommend you buy a set of bathroom scales and a tape measure. Too many teams rely on highly subjective personal feelings and instincts when assessing how well they do stuff. Conversely, some teams - a much smaller number - rely too heavily on metrics and reject their own experience and judgement when the numbers disagree with their perceptions. Strike a balance here: don't rely entirely on voodoo, but don't treat statistics as gospel either. Use the data to inform your judgement. At best, it will help you ask the right questions, which is a good start towards 9.

9. Do you look at how you're doing - in particular at the quality of the end product - and ask yourselves "how could we do this better?" And do you actually follow up on those ideas for improving? Yes, yes, I know. Most Agile coaches would probably introduce retrospectives at stage 0 in their heirarchy of needs. I find, though, that until we have climbed a few rungs up that ladder, discussion is moot. Teams may well need them for clearing the air and for personal validation and ego-massaging and having a good old moan, but I've seen far too many teams abuse retrospectives by slagging everything off left, right and centre and then doing absolutely nothing about it afterwards. I find retrospectives far more productive when they're introduced to teams who are actually not doing too badly, actually, thanks very much. and I always temper 9 with 8 - too many retrospectives are guided by healing crystals and necromancy, and not enough benefit from the revealing light of empiricism. Joe may well think that Jim's code is crap, but a dig around with NDepend may reveal a different picture. You'd be amazed how many truly awful programmers genuinely believe it's everybody elses' code that sucks.

10. Can your customer deploy the latest working version of the software at the click of a mouse whenever they choose to, and as often as they choose to? You see, when the code is always working, and when what's in source control is never more than maybe an hour or two away from what's on the programmer's desktops, and when making changes to the code is relatively straightfoward, and when rolling back to previous versions - any previous version - is a safe and simple process, then deployment becomes a business decision. They're not waiting for you to debug it enough for it to be usable. They're not waiting for smal changes that should have taken hours but for some reason seem to take weeks or months. They can ask for feature X in the morning, and if the team says X is ready at 5pm then they can be sure that it is indeed ready and, if they choose to, they can release feature X to the end users straight away. This is the Holy Grail - continuous, sustained delivery. Short cycle times with little or no latency. The ability to learn your way to the most valuable solutions, one lesson at a time. The ability to keep on learning and keep on evolving the solution indefinitely. To get to this rung on my ladder, you cannot skip 1-9. There's little point in even trying continuous delivery if you're not 99.99% confident that the software works and that it will be easy to change, or that it can be deployed and rolled back if necessary at the touch of a button.

Now at this point you're probably wondering what happened to user experience, scalability, security, or what about safety-critical systems, or what about blah blah blah etc etc. I do not deny that these things can be very important. But I've learned from experience that these are things that come after 1-10 in my heirarchy of needs for programmers. That's not to say they can't be more important to customers and end users - indeed, user experience is often 1 on their list. But to achieve a great user experience, software that works and that can evolve is essential, since it's user feedback that will help us find the optimal user experience.

To put it another way, on my list, 10 is actually still at the bottom of the ladder. Continuous delivery and ongoing optmisation of our working practices is a platform for true excellence, not excellence itself. 10 is where your journey starts. Everything before that is just packing and booking your flights.

Educating The Next Generation of Programmers - Time For Practitioner Power?

With the 100th anniversary of the birth of computing pioneer Alan Turing approaching (June 23rd 2012, in case you were wondering), this leaves many of us in the UK- the birthplace of computing (don't argue, it is!) - wondering just what the hell happened to all that potential.

We now find ourselves in a country where computing continues a long and sorry decline. We're caught in a vicious loop. As interest in computing ebbs away year on year, we end up in a ridiculous situation where we have so very few teachers that can really program a computer, and kids who are being put off programming by that lack of practical support they get in the classroom.

As a practitioner, and someone who was once a a teenager (don't argue, I was!), I would have found the new OCR GCSE in Computing - which is admittedly a step up from GCSE ICT - more than a little insulting.

Kids are expected to write programs to move characters around non-visual mazes, or to validate passsword, or to store highest scores for a computer game they're not expected to write.

The programming concepts 16 year-olds are expected to grasp are missing such things as functions, modules, classes, windows, events and other stuff that more than a few 9 year olds have somehow mastered.

It appears GSCE Computing stops short of anything useful or contemporary. To end discussion of "design" at simple algorithms robs kids of an opportunity to stretch and show us the smarts and the ingenuity that had much younger kids creating software empires from their bedrooms during the home computing boom of the 1980's.

And I really do think that starting kids on programming at 14 is leaving it too late. We generally start kids on foreign languages much younger, because frankly 2 years isn't anywhere near enough.

I believe kids should be exposed to the kind of very simple programming GCSE Computing covers at ages 9+, and by the time they're 16, I'd expect them to be able to create working applications with multiple features/functions, a graphical user interface of some sort, and to have unit tested the damned thing. I'd expect a 16 year old to be comfortable coding with objects and classes. I'd expect a 16 year old to be intellectually mature enough to cope with these techniques. Maybe if we didn't waste so much time teaching them how ard drive works or about registers or about the Von Neumman architecture, which, let's face it, is pretty irrelevant to getting programs written in C# or Java or Ruby to work.

If we approach programming as a practical skill, like speaking a foreign language, then GCSE Computing is still selling kids far short of what our own experiences as kids tell us unequivocally they should be capable of.

I see only one practical impediment, and only one justification for the lack of ambition in the GSCE's design - teachers. It's the teachers who find this stuff hard. And I can't help feeling that the GCSE has been designed to make it easier to teach, not to make it useful and just-enough-of-a-challenge for kids.

Many schools lack a single teacher who can program to an acceptable level of ability. Among the 10,000 or so teachers who qualified in 2008 in the UK, apparantly only 3 (not 3% - THREE!) had computing educations.

And herein lies what I believe is the bottleneck. An impediment not just to computing education, and to our childrens' interest in computing careers. No, this is an impediment to our society and our economy. We've been living in an information age for longer than many of us are aware, and the importance of computing and software increases exponentially as our computing skills base declines.

And programming's not just a great career option; it's a fantastic career option. Good money, smart people, solving puzzles every day for a living, great working conditions, and most of us don't even have to wear a suit. You can telecommute. You can get involved in an international community and see the world (well, you can see the insides of airports, taxis and hotels of the world - but you know what I mean). And we probably have one of the lowest barriers to entry for starting a business, and demonstrably the best scalability for rapidly growing a business, of any line of work I can think of. If you're interested in making your fortune, it's probably ten times harder to make it out of cakes or hotels or golfing lessons as it is to make it out of code.

And we're genuinely one of the nicest professions. Try working in sales, or media, or law, or medicine. Trust me - we're probably the most welcoming, forgiving, co-operative, generous bunch of people you're likely to end up working with.

So why aren't kids - and especially girls - stampeding to join us?

Firstly, I get a real sense that the computing they learn about at school (and see in the media - it's not all the education system's fault) bears little or no resemblance to the profession we know and love. It's dry, boring, academic, and mostly populated by blokes with beards in sandals. I suspect a month spent at a start-up in Shoreditch would completely dispel that myth. These days it's hard to tell whether you're a programmer or a TV researcher or a graphic designer or a stand-up comedian. Of course, the easiest way to tell would be to check their bank balance - the programmer will have the biggest disposable income.

Secondly, there's the bottleneck: teachers. Kids who see beyond the mythology and are interested in learning to program can expect little support in the classroom.

I think we can address both of these obstacle in one strategy: it's time for practitioner power.

Some statistics, which I quite literally just dreamed up. Well, okay, I Googled a bit, too.

There are about 4,000 secondary schools ("high schools") in the UK covering about 3,000,000 pupils.

There are about 300,000 professional programmers working in the UK.

If we wanted to set a goal of at least one skilled programmer-teacher in every school, there are a number of ways we can go about it.

The direct route would be to put skilled and experienced practitioners in the classroom. If 1/1000 programmers spent one year teaching in any given year, then that would just about meet our goal. That would mean than 1/20 professional programmers would have to give up one year in industry once in their career. There are obstacles, of course. Not anyone can just walk into a school and start teaching. A 1-year sabbatical to teach could have to be preceded by another year qualifying to teach, and then there's a heap of checks and bureaucracy to climb over.

An indirect, but more pragmatic route would be to coach 4,000 teacher-programmers. If 1/1000 practitioners coached one teacher for maybe 2-3 years (on weekends, evenings, summer camps etc), then this could produce the army of skilled teacher-programmers we need. The effects would take much longer to be felt, of course, and it wouldn't expose kids to people with real industry experience, but it would be less of an ask for practitioners.

Option 3, of course, is to do both. A bit of industry experience drafted into schools (and maybe some teachers drafted into industry at the same time), as well as oodles of coaching for teacher-programmers.

We would have to be clear that the end goal here is to raise the standard of programming in schools well beyond where the bar is currently set by GCSE Computing. We should all get together - teachers, practitioners, employers - to review the expectations year-on-year, review our performance, and incrementally raise the bar until we have 16 year old kids writing proper software, as we know they can.

Involving the education boards and examiners introduces some difficulties, particularly given the speed at which they work, so it may be desirable for the first few years to side-step all of this and push programming as an after-school activity to show how much further kids can go if they're given the opportunity to progress far beyond what the syllabus gives them credit for.

In our schools, we have some very successful non-academic programs run for the schools by external bodies (like the Duke of Edinburgh Awards, and music qualifications), and it's entirely conceivable that something like that could be created for programming, led by teachers, parents and especially practitioners. Kids could progress from age 9+ and end up writing real software with real-world applications that have real benefits. So by the time they reach university, the bit where you make the computer do what you want will be second nature to them.

On The Subject Of "Value"

I really need to get up from my desk and get ready to go out. (Some software craftsmanship thing going on this evening, so will lurk at the back and see what folk are saying.)

Meanwhile, among other distractions, a debate on Twitter about the value of software/features has inspired me to jot down a couple of thoughts before I get busy.

There are people out there who believe it's possible to measure and estimate the value of a feature in ourely financial terms - what it's worth in pounds sterling or dollars.

I have two thoughts on this: first of all, if this were really true, the successes in our industry might be much easier to predict, which we tend to find they're not. So, going purely on the evidence of the distribution of software success, I'd say nobody's cracked this one.

More importantly, I think this is a naive and one-dimensional view of "value". In my experience, value is usually a very complex, nuanced and subjective thing. For hundreds of years businesses have faltered when they focus entirely on the mighty dollar (or euro,or yen) at the expense of other kinds of value.

Profit doesn't exist in a vacuum. It's a product of many interrelated factors, like customer satisfaction, employee morale, skills, environmental factors, human rights records and a miriad of other, sometimes competing, concerns.

One pespective in particular can be very hard to pin down and explain in terms of mere numbers: the user's point of view.

What I've seen happen all too often is customers and product owners/managers defining and prioritising features based on what the business wants, not on what the users might want. Indeed, it's actually rare to find real target end users getting involved in the design of the software.

Now, we have to be very careful here; what the people paying for the software, and what the people using the software want are not necessarily the same thing.

For example, a Facebook user might not think advertising is very important to them. Indeed, they may find some forms of FB advertising intrusive and annoying. But to Facebook's owners, advertising is very, very important. So important, in fact, that in recent years the users' needs seem to have taken a back seat while the developers forge ahead with all manner of features designed to make the site more bankable.

Of course, advertising keeps Facebook, and many other web sites, free to use. So a balance has to be struck. I've felt of late that the balance has tipped too far in favour of what Facebook wants.

You see, you may think you're new car is going to be worth $50,000, but that's only true if someone's willing to pay $50,000 to drive it. If the end user doesn't see the value, then it's worth nothing at all.

Car manufacturers usually put the driver at the centre of their design process. Making as car desirable is what makes it valuable.

It seems we have yet to learn this lesson in software development.