November 21, 2015

Getting Software Teams Back On Track

A recent tweet about things teams do when the schedule is slipping that can actually make things worse seems to have resonated with a lot of people.

It naturally begs the question: what could we do to get us back on track?

Well, the first - and most painful lesson - is to accept that just maybe we can't get back on track. And therefore we'll have to rethink the plan. There are two ways we can remake a plan that we know can work:

1. Move the delivery date back to fit all the work in

2. Deliver less to meet the delivery date

It's not a conversation a lot of teams relish having with their customer, but there is some silver living re: #2

When I say "deliver less", I mean "less software". If we're clear in our minds that software and value aren't the same thing, it becomes possible to deliver most of the value a customer needs - to solve their key problem, essentially - without delivering all the features we planned to.

This is the software development equivalent of saying "The house won't be finished on time, but you will be able to move in on that date".

If you're doing Agile Software Development, this may already have happened. And if it hasn't, then maybe you're not really doing Agile Software Development.

This solution does require us to have a clear idea of what the real end goals of the software are. You have to shift the emphasis from delivering a shopping list of features to solving a set of problems. Then you can buy yourself flexibility on design. More choices can be a powerful thing when you need to solve a problem in a fixed amount of time.

When I've inherited team leader roles on compromised projects, the first thing I've done is stop everything and get the team to step back and ask "What are we trying to achieve here? Is there a simpler way?" So be prepared to ditch the design and to ditch the plan that goes with it. In my own experience of saving compromised projects, this is the key. Prepare for some full and frank conversations with your customer.

But what of the three things I tweeted about that we know can make late deliveries even later?

Hiring More Developers has long been known to make things worse.

The reasons why hiring more developers exacerbates the problem are explained beautifully in Fred Brook's famous book The Mythical Man-Month. I believe every software developer and every software development manager should read it.

Developers who were busy getting shit done suddenly become busy getting new team members up to speed. It's like promoting your most effective sales people to management roles; watch those sales plummet!

Add to that an exponential explosion in the number of lines of communication within the team required to keep everyone abreast of what everyone else is doing - which, sadly, in software is a necessity because it's all connected - and we are fighting a double productivity hit of losing your most productive developers to mentoring duties and the rapidly diminishing returns of bigger teams.

So, the advice is very simply DON'T DO IT. No matter how tempted you are. No matter how much pressure you're under from above. DON'T DO IT.

But what if the team's already too big? What if the reason you're not getting shit done is because the team overhead is holding you back? Here, you may have to make very difficult decisions, ranging in severity from moving people on to other projects - if they exist - or side-lining people who are getting in the way, to letting people go as a last resort.

If you are a bit top-heavy, or have a few too many trainees, it's possible to absorb the hit. If, on the other hand, you have 3 architects, 2 project managers, 6 tech leads, 4 business analysts, 30 developers and 10 testers... well, as far as I'm concerned a lot of those people are enjoying what is effectively a kind of in-work welfare. They're getting paid - and possibly paid very well - to not just add no value, but to positively suck value out of the team. You're paying them to slow you down. We all know it, but few dare say it.

In those cases when the team is very obviously too big, then you'll have very little choice but to simplify it if you want to deliver something of value when the customer needs it.

Alas, these kinds of decisions - to hire or to redistribute or to fire - are usually out of the hands of the likes of me and you, and managing upwards in these situations carries great risk; specifically the risk that the person going will be the one who blows the whistle. The default behaviour in these situations is to quite knowingly choose failure; perversely, for the good of the team.

Cutting Corners is a classic mistake. For about as long as we've known that hiring more developers will make things worse, we've also known that skimping on quality actually makes us go slower.

The reasons are simple, well-understood and backed up by a veritable Himalayas of hard evidence; bugs cost exponentially more time and money to fix the longer they go undetected. Less testing, less often, therefore, creates a downstream tsunami of necessary bug fixes that will take 10-100x times as long to fix than if we'd caught them sooner.

You can spot the teams that have been doing what we call "code-and-fix" development not just by the size of their bug list, but by the sheer amount of time and effort it takes them to "stabilise" the software to make it fit for release. I've watched teams go round and round in circles for months trying to make code good enough to ship.

This is why teams in the know, when the schedule's slipping, do more testing, more rigorously, and more often. Yes, it's more work now. But it's 10-100x less work later.

For sure, there are no silver bullets in software development. But when it comes to putting teams back on track, creating fast-running automated tests is the closest thing I've seen. It can completely transform the outlook.

Likewise moving to Specification By Example in our discussions about requirements with the customer can have a transformative effect. You'd be amazed how many misunderstandings you catch when you ask for concrete examples to clarify what they mean. A couple of hours spent clarifying a requirement with executable acceptance tests could save you weeks of unnecessary rework.

Same goes for the maintainability of the code. Less thought and care put into making our code easy to understand and easy to change (without breaking) can cost us dearly, and sooner than we think. I've found myself being hampered in the afternoon by code I wrote in the morning.

As in golf, the way to get a better score faster is to take more care over our shots.

This, too, is a tough sell both to team mates and to managers. The entirely debunked myth that better quality software takes longer to deliver still persists. And there may be new skills that have to be learned to make a defect prevention and "clean code" approach work. If the team's not already up-to-speed on the principles and practices, then - well, you're a bit buggered, really, because you're months (possibly years) away from conquering that learning curve.

If the team, on the whole, does have the necessary skills, then that would beg the question: why weren't you already doing these things? If the answer is "the boss won't let us", then here comes another difficult conversation, potentially.

My own experience, and the anecdotes I hear from people in that situation, is that you should never have that conversation. If you're having that conversation, all is very possibly already lost. It rarely goes the way you wish it to. By giving managers and customers a choice over quality, 99 times out of 100, they'll veto it in favour of "features". Even though, as we know, skimping on quality will deliver less features. But the perceived conflict between those two concerns beats most teams who make the mistake of offering it as a choice.

So, when it comes to meeting delivery dates, make quality non-negotiable. And the best way to do that is to never talk about it outside of the team. If you do TDD, for example, than that is the way you deliver working software. Just as surely as using a text editor is. When did you last offer the boss the choice of whether or not you should use a text editor?

And when things are slipping, you need to pull on those quality levers even harder. If you've been taking baby steps, take even babier steps. If you've been building and testing daily, build and test hourly. If you've been devoting an average 20 minutes to discussing a user story with the customer, devote an hour and agree executable tests, including all the edge cases you can think of. If you're averaging one unit test for 10 lines of code, aim to make your unit tests even more focused. If you're averaging one team code review in each iteration, do peer code reviews before every commit. And so on.

Finally, Working Long Hours - we know from many studies done over the last century - is not sustainable, hurts teams and projects, and is a false economy. Going as far back as Henry Ford, who discovered that when he reduced factory workers' hours from 50 to 40 a week, they got more done, we've known that hours worked != useful output.

Software development in particular is susceptible to burnout when we push teams into "crunch mode". It's an activity that requires focus and clarity, and focus and clarity are perishable goods that need to be replenished frequently. From my own experiments with teams, and with myself, I learned that the average developer will achieve roughly as much in 4 hours a day as she does in 8, and more than she would in 12 hours.

Some folk say "it's okay in the short term", but I've found no evidence anywhere that even this is true. Maybe an assembly line worker can work a few long shifts to meet a deadline, but that ain't software development.

We're also very susceptible to the illusion of productivity, and I think this explains where the "it helps in the short-term" myth comes from. Sure, we feel like we're getting shit done. But that may well be because we are blind to the downstream consequences of the mistakes we make along the way. Towards the end of an 8-hour day, I find - when I measure it objectively - that I'm making more mistakes. And so I've learned to quit while I'm ahead, and have found it beneficial to have teams do likewise. Learn to recognise when you're passing from a zone of "flow" into a zone of "liability".

And so, when I lead teams, I have a very low tolerance for longer hours as any kind of solution - even a short-term one.

And, yes, this too is a very tough sell to management. And to many developers still enraptured by the illusion of their own productivity. It takes real nerve - when a deadline is looming and everyone's frantically firefighting - to calmly get up from your desk at 5-6pm and go home. But it is, as far as I can tell, the best thing you can do for the project.

Similar - and closely related to the need to take more care - is the need to stay even more refreshed. Take more short breaks, have a proper relaxing (but not carb-heavy, because that'll make you sleepy) lunch. Be extra diligent about leaving at a reasonable time and having an even better work-life balance.

And then turn your focus on to what you actually do when you are at your desk instead of how long you spend at your desk.

One thing that really annoys me is how many organisations insist on long hours, but then merrily burn those hours on meaningless distractions like meetings and dysfunctional working environments like open-plan offices. I tend to find a strong correlation between the two. Wanna' get more done? Tackle the working environment, not the hours.

So, there you have it. To summarise; to improve your chances of meeting a delivery date:

1. Manage expectations of about what will be delivered and when. Simplify the product, simplify the plan. Focus on the end goal, not the shopping list.

2. Resist the temptation to hire more developers. If your team is already far too big, have that difficult conversation.

3. Turn the quality dial UP. Make quality non-negotiable.

4. Work FEWER hours. Take MORE breaks. Instead of focusing on hours, focus on what gets done in those hours, and remove obstacles to getting things done, like the working environment.

Of course, I say all these things safe in the knowledge that most teams will be too afraid to try them. It's easy on paper. But in practice, it takes a certain kind of team with a certain kind of leadership to make these things happen.

So, finally:


This doesn't necessarily mean someone bullish like me fighting the team's battles for them (though I have done it many times). But somehow, from somewhere within, the team needs to find this strength and self-belief and assert themselves on key issues like scope, deadlines, team size, working hours, office environments and so on. They've made you responsible for delivering: now assert the authority that has to accompany that responsibility if it's got to work.

Good luck!

November 4, 2015

The X Factor-isation of Programming May Attract The Wrong Kids

I've watched a few documentaries recently about kids getting into "tech" (y'know, tech... like the spinning jenny and the seed drill).

The overriding theme is not one of tech itself - that tends to get edited out - but of entrepreneurialism. These things have become so closely intertwined, especially in the media, that many seem to view them as the same thing. Why would you write an "app" if not to make money?

Well, for millions of us who rode the first wave of home computing in the 1980s, the answer is very simply: for the sheer heck of it.

Why does a kid paint, or draw, or bake bread, or make sandcastles? Is it part of some business plan for a painting/drawing/baking/sandcastle start-up? As a kid, I painted because I enjoyed it. And I programmed because I enjoyed it. It was its own reward.

I worry now for this X Factor-isation of computer programming. Partly because it sets very unrealistic expectations - just like real X Factor. yes, some people get rich and famous making music. The vast majority don't. And the reasons for that are beyond their control. Getting good at making music, on the other hand, is within our control. We can practice; we can learn; we can get lots of experience trying different things.

But how many X Factor contestants are prepared to put in the hours to get good at making music? How many leave those auditions resolved to learn more about harmony and to get better at playing the piano or the guitar?

Without an intrinsic love of what you're doing - be it making music or writing computer programs - learning to do it better will likely as not take up far more time and require far more application than greed and willpower would motivate them to do. If there's no joy in it for you, then you won't go past the basics. It's just too much trouble.

And this is why I believe all the emphasis on start-ups and business plans and marketing and pitching and all the rest of it is a mistake. Want to be in business? Then be in business. Computer programming isn't business. Any more than playing the piano is.

Yes, some people make money programming computers. And some people make money playing the piano. But if you hire a session musician, I guarantee you'll be working with someone who - first and foremost - loves to make music. They might not love making your music, but then they'll go back to their home studio and extract the necessary joy from working on their own. They'll get a job to finance it. Just like so many programmers wade through 9-5 data processing drudgery and then go home and work on a personal project that excites them.

It troubles me deeply that we're dangling the wrong carrot for kids to aspire to. Indeed, it troubles me that we're dangling carrots at all. Programming is its own carrot for those who will enjoy it.

October 29, 2015

Software Developers: Are You Tired Of Unqualified People Telling You How To Do Your Job?

Are you a software developer? A real one, who does actual programming and technical architecture and build automation and testing and stuff?

Have you - in some language(s) on some platform(s) - created valuable working software for a real customer in the real world by yourself? Have you created valuable working software for a real customer in the real world working in a team?

Are you tired of being told what to do, and being spoken for, by people who are not software developers and don't understand software development? Do you wish you, your team and your profession had more of a say in things; more of a voice?

Do you believe that software developers get the best results when:

a. We work in small teams with other skilled developers?

b. We work directly with the customer and end users?

c. We are left to make the technical decisions that we are best qualified to make?

d. We have control over who we work with, who can take leadership on what based on their expertise, and make developer hiring decisions?

e. We are not micromanaged and are responsible for how we use our time?

f. We work the way we believe works best, and are measured solely on what we deliver?

g. We decide how to bring new and inexperienced junior developers up to speed, and we decide when they're ready to work unsupervised, which we believe any real software developer should be able to?

If you answered "yes" to all these questions, then you're not alone. I've yet to meet a software developer who didn't have any war stories about clueless managers, micromanagement, lack of respect for them and their team, being forced to work with trainees who didn't know they were trainees, and being forced to work in dysfunctional ways because they had absolutely no say in it.

I think it's high time we took responsibility for our fate. I believe these things happen because we let them happen. But I appreciate just how seemingly impossible it is to be the lone voice on a team - the one person who stands up and says "this is all wrong". The typical end result is a rapid exit from the team, with no improvement in the team's prospects.

At the risk of summoning the ghosts of Marx and Lenin, what's needed is a bit of basic solidarity.

90% of software developers are perfectly happy producing crap and not rocking the boat. And they and their customers are welcome to it.

But the remaining 10% of us who actually give a damn need to be a bit more organised, lest we doom ourselves to frustrating careers locking swords fruitlessly with the other 90%. Been there, done that, wiped the blood off the t-shirt.

So - and I'm sure I'll live to regret this - I'm wondering if the time has come for the 10% to get together and join a sort of "club". I'm not sure what form this club might take, or exactly how we gain entrance to it, but I am increasingly convinced that the club is needed.

Call it a "guild", call it an "alliance", or an "institute": nay matter. What matters is the need for a network of moral support, congregating under a banner defined by the desire and the ability to do real software development, unhindered by unqualified managers and incompetent team members trying to drive the bus.

Who's with me?

October 28, 2015

Focusing On Typing Speed Not Only Misses The Point, But Can Exclude Talented Developers

After harumpty-three years of programming computers, I've long ago abandoned the notion that how fast I can type out code is a limiting factor on how soon I can deliver valuable working software.

Typing, as an activity, is a such a tiny part of what software developers do, that you could be a really slow typist, working in a clunky language full of redundancy and clutter - like Visual Basic - and still get more done than someone who can bash out 100 w.p.m in a tight, streamlined language like Ruby or Haskell.

If you don't believe me, look back at your commits for the last week, count the number of words you typed, and divide that by the number of minutes you worked. I average about two words a minute, which adds up to about 800 LOC a week, or 40 KLOC a year.

Now, my boss - who's sitting with me right now - may mistakenly believe that I must be pressing a key once every thirty seconds. And 40 KLOC doesn't sound like very much at all, until you qualify that with "on legacy code, which most developers spend most of their time working on, in a team, with customers and so on". In other words; real software development, with all the usual obstacles. Starting with a clean slate, working alone, with no customer to seek input and feedback from, I move faster - maybe 100-200 KLOC a year. But, arguably, a lot faster towards solutions of less value. Which opens up a whole debate about what "developer productivity" is anyway...

My actual typing speed - out on the open on a flat surface with the wind behind me - is about 30 w.p.m. What's actually happening here is that I spend very little of my time - less than 5% - typing code.

If I was a 60 w.p.m typist, my productivity - in terms of working software delivered - would not double. It would barely change, because how much I achieve per hour/day/week year is not constrained by the physical act of typing in the code to any appreciable extent. An average of 2 w.p.m. is a reflection of how fast I make decisions about the code. Every line of code contains decisions - names, types, dependencies, formulas and expressions, strategies for solving problems etc. And then there are all the changes: I rarely leave a line of code untouched once it's been written. Refactoring accounts for a lot of the time I spend working on code.

But - and this is backed up by a mountain of evidence - by far the bulk of mine and most developers' time is spend reading code; typically between 50-80%. Which is why my efforts are most focused - after worrying about whether or not it works - on how easy the code is to read.

So, maybe 5% or less of my focus is on write-ability of code, compared to 50% or more on readability. To put it more bluntly, readability matters 10x as much to me.

But our ingénue profession still obsesses mostly over write-ability of code, not on readability. And those of us who can look back on many wasted years servicing this obsession - and it is years, over the lifetime of a career - may sound the warning bells for younger developers still chasing the illusion of productivity. But, it seems, the message "go slow to go fast" still hasn't broken through into the collective Developer Borg consciousness, even within the software craftsmanship community.

But, hey, it's your time and your customer, and who am I to say how you should waste it?

Where I do have a problem, though, is in how this obsession with how fast we type the code can exclude developers with disabilities that make faster typing an impossibility.

I've coached and mentored developers with disabilities, and the first thing I learned is that as much, if not more, can get done. Typing isn't the bottleneck; thinking is the bottleneck; feedback is the bottleneck; cost of change is the bottleneck. Typing is, at worst, a minor irritation to impatient people.

In the UK, and many other developed nations, you're not allowed to discriminate against a software developer on the grounds of disability. But, sadly, I've seen teams do exactly this, entirely on the basis that they are too slow at typing. "They wouldn't be able to keep up. Nobody would want to pair with them. They'll hold the team back."

It's bullshit. And dangerous bullshit, because it restricts opportunities to some very talented developers, which is bad news for them and bad news for you and bad news for the world who could have benefitted from the fruits of their labours.

Just as we need to get past the face-time culture of many development organisations to open the doors to talented programmers with other commitments, like parenting, we need to get past this obsession with typing speed because:

a. It really doesn't make much difference, and
b. It focuses us on an relatively unimportant skill that can exclude some really great developers from joining the party

10 w.p.m. is plenty. It's 5x what you need. It's not they who need to speed up. It's we who need to slow down. Take a deep breath, and focus on the stuff that makes a difference. Hey, maybe think about the problem a bit more? (I know - kerrrrazy!)

October 19, 2015

Software Craftsmanship 2016 - Would You Like To Host An Official Event Where You Are?

So, finally, evil plans are taking shape for the revival of the original software craftsmanship conference.

Started in 2009, SC20xx ran for 5 very successful years, and saw innovative new hands-on sessions from some of our best code craft thought leaders.

The unusual "less talking, more coding" format and the distinctly community-led nature of the events made for a fun-packed and challenging day, and my aim is to build on that going forward.

At SC2016, talks will be banned altogether. Nope, not even Open Space talks, or Lightning Talks, or Talks Wearing Various Naval Headwear. We're making the final progression, and transcending traditional conference formats altogether. No talking, just coding.

SC2016 will bring together likeminded passionate programmers, simply to work on pre-set problems, pair program, share ideas and have a laugh - all without the annoyance of someone (probably like me) talking at you.

The aim will be to develop a DVD-ROM or USB stick crammed full of project ideas and exercises for code crafters - some short and self-contained, some larger and more ambitious. You come along, grab a coffee, find someone you like the look of, and get to work. We'll provide desks, chairs, Wi-Fi, doors, windows, walls, ceilings, etc - and coffee, obviously - and mentors on hand to help out with any technical issues.

And here comes the best part: because the conference will effectively come on a disc, it suddenly becomes possible to unshackle the event from its geophysical constraints. To put it more bluntly, other folk can run an SC2016 event in their area. You will need to find some suitable space (e.g., a cow shed, or dry lake bed which inexplicably has Internet and power sockets), provide some basic refreshments (water, tea/coffee, a simple buffet lunch if you can stretch to it), and - provided you stick to the rules - we'll list your event among the official ones on the SC website.

More details will be finalised in the coming few weeks, but here's what I already know:

When? Saturday May 15th

Where? Anywhere suitable (tables, chairs, Wi-Fi - basically, an office or meeting space)

What? A packed day meeting likeminded craftspersons and having fun tackling handpicked projects of all shapes and sizes

Who? Anyone who gives a shit about writing good software, and about getting better at it

How much? The plan now is to try to offer places for free, though organisers of individual events may choose to charge a small fee to cover their nominal costs (e.g., if they can't find a sponsor to pay for catering).

And the expenses? Costs will be managed at a local level by event organisers. How much it costs will depend on where you host it, what you do about catering, and so on. Logistically, SC2016 events will be very similar to the kind of meet-ups and Code Retreats groups run locally all the time, and we expect costs to be in the order of £100-300, assuming a venue is provided for free. Of course, if you have 10,000 at your SC2016 event, and want to feed them lobster for lunch, your costs will be significantly higher!

If you're outside London (I'll be running it here), and interested in hosting or running an SC2016 event where you are, please get in touch before Nov 30th.

Remember - can be anywhere in the world: India, the US, Canada, Spain, France, Narnia, Gallifrey or Trumpton.

Drop us a line.

October 13, 2015

Widening The Goalposts By Asking "Why?"

It's been probably a decade or so since I last visited this topic, but it comes up often in conversation, so I thought this would be a good time to revisit it.

One of the key reasons why it's so important for software teams to have high-level goals to work towards is because high-level goals tend to leave us wider potential solution spaces for meeting those goals.

One of the biggest problems in software development is our tendency to confuse problems with solutions. That is - put more bluntly - we tend to be working towards implementing someone's design rather than solving a problem.

User stories, for example, are typically design decisions: descriptions of features or properties the software must have. These are not requirements, they are solutions masquerading as requirements.

I can illustrate why this is a problem with a very simple programming language I've just invented called DICE.

In DICE, we can specify the results of throws of a pair of dice, like this:

{ 1, 6 }

Imagine our customer writes user stories along the lines of:

As a gambler, I need to throw a 1 and a 6, so that I can score a 7.

As a developer, I would seriously consider tearing up the first part of this user story. Why does it need to be a {1, 6} ? What the customer wants is a total of 7.

There is only one way of throwing {1,6}, but there are 6 ways of throwing a total of 7.

The number of different ways of throwing something is the solution space. Throwing any combination that totals 7 has six times as many solutions as throwing specifically {1,6}.

{1,6} is a design for scoring a 7. But 7 is the requirement. By taking a step back from the design and asking "why do they want to throw {1,6} ?", we can discover the real goal and widen our choices for achieving it.

When we have more choices, our odds of finding a solution with limited time and resources increase. It's the most powerful question a team under time pressure can ask: why?

Many are the times when my team's been banging up against it time-wise and we've taken a step back, gone back to the real underlying goal, and come up with a simpler and quicker way of giving the customer what they really want.

And we don't have to stop at one "why?"; so the customer really wants a total of 7. Again, why? The customer tell us "because I win if I throw 7 or 11".

Aha! So our solution space is even wider than we thought. Six ways of throwing 7, plus two ways of throwing 11.

And so on.

In the casino of software development, anything we can do to improve our odds is likely to be a good thing. Widening the solution space - by raising the level of the requirements above designs - can be a powerful aid in this.

October 1, 2015

Peeple: A Clear-Cut Case for When Developers Should Say "No"

Two things happening simultaneously this morning: firstly, I'm trying to get into Python, but strapped for time at the moment, so getting up an hour earlier to go through tutorials. And keeping one eye on this whole Peeple debacle that's exploded on to Twitter.

Putting Python aside - except to say, expect to see some popping up on the blog soon, so the Python gurus among you can have a good laugh - I'm genuinely gobsmacked that two actual human beings dreamed up the idea for Peeple, and that other human beings gave them actual real money to make it happen.

If you haven't heard already, Peeple is arguably either the dumbest, the cruellest or the most cynical start-up idea in Web history. It allows people to rate other people, and leave reviews about them, like they were restaurants or hotels.

Apparently, if you have someone's cell phone number, you can create a profile for them, and there's no way for that person to opt out yet. It's got "dystopia" written all over it.

But what concerns me even more than the fact that human beings came up with the idea, and human beings funded its execution, is that human beings wrote the code that makes it work.

This, to me, has to be one of those situations where developers should just say "no". No, I am not going to create software that turns people into reviewable, rate-able products. Teh Internets are bad enough without bringing such a blindingly obviously abuse-able system into being.

Given the backlash, and the extremely strong and almost universal revulsion that's being expressed on social and in traditional media this morning, one can only hope that purveyors of apps like Apple, Google and Microsoft see sense (or at least see a PR nightmare looming) and refuse to allow Peeple to distribute their app through the official channels. It's so utterly toxic, with such massive potential to cause harm to vulnerable people, that it truly beggars belief that it even exists at all in any shippable form.

And it really, really bugs me that software developers enabled this insanity. They should be thoroughly ashamed of themselves. I'll wager it won't be going on their CVs.

September 22, 2015

Why Tech Entrepreneurs Need To Be Programmers

I worry - I really do - about the trend for the X Factor-ization of software development that start-up culture has encouraged.

Especially troubling is how the media is now attempting to woo impressionable young people into the industry with promises of untold riches, often creating the impression that "no coding is required". No need for skillz: we can use the VC money to pay some code monkey to do all that trivial stuff like actually making ideas happen.

Far from empowering them to take their destinies into their own hands with "tech", this pushes them in the exact opposite direction. If you cannot write the code for your idea, you have to pay someone to do it for you, and that means you have to raise a lot of money just to get to the most basic working prototype.

This means that you will need to go far into the red just to figure out if your idea is feasible. And here's the thing about start-ups: you'll probably need to try many, many ideas before you find The OneTM. If trying one idea comes at such a high cost... well, you do the maths.

Whereas a young person - or an older person, let's not forget - with the right programming skillz, a cheap laptop and a half-decent Internet connection could do it themselves in their own time, as thousands upon thousands of software developers are doing right now.

What makes software so special is that the economic and social barriers to entry are so low. You don't need hundreds of thousands of pounds and special connections from that posh school you went to to start writing programs. Whereas, all the evidence suggests, you do need to be in a priveleged position to get funding to pay someone else to do it. Take a long hard look at our most successful tech entrepreneurs; not many kids from the wrong side of the tracks among that demographic.

Of course, programming is hard. It takes a long time to learn to do it well enough to realise even moderately ambitious ideas. Which is why such a small proportion of the people who try it end up doing it for a living. What makes software so special is that the personal and intellectual barriers to entry are so high. No wonder kids are relieved to hear you can be a tech rockstar without all that fiddly business of learning to play guitar.

But anyone with a programmable computer and Internet access can create applications and have them hosted for a few dollars on cloud services that - should they get lucky - can scale pretty effortlessly with demand. Anyone with a programmable computer can create applications that could end up listed on app stores and let computing giants take care of the retail side at any scale imaginable. It's not like selling widgets: a million orders for a new widget could put a small business in real cashflow trouble. A million sales of your iOS app needs neither extra manufacturing nor storage capacity. That's the beauty of digital.

The reality, though, is that the majority of software start-ups never reach such dizzying heights of commercial success. Which is why the vast majority of professional programmers work for someone else. And in my humble opinion, someone who learns how to make a good living writing point-of-sale systems for a supermaket is every bit as empowered as someone who's trying to get their POS-as-a-Service start-up off the ground.

And that's why I'm worried; for every successful tech entrepreneur, there are thousands more doing just fine thank you very much writing software for a living, and having as much fun and being as much fulfilled by it. By all means, reach for the stars, but let's not lose sight of the much wider set of opportunities young people might be missing if their gaze is 100% focused on The Big Shiny Success.

And even if you harbour such grand ambitions - and someone has to, at the end of the day - your odds of getting an idea off the ground can be massively improved if you can create that all-important working prototype yourself. Because, in software, a working prototype is the real thing. Making shit real is a very undervalued skill in tech.

September 12, 2015

TDD Katas Too Easy For You? Try the Codemanship Team Dojo

One thing I hear regularly is how the kinds of practical exercises we do in training workshops and pair programming interviews are "too trivial" to test real developers.

Curiously, and without any exceptions, it turns out that the people who make such claims are unable to complete the exercises to a high standard in the allotted time; leading me to think that just maybe we overestimate ourselves sometimes. And it's not escaped my attention that those who brag the loudest tend to do them least well.

But if you really want a bigger challenge - one that's more befitting of your programming genius - then there's always my Team Dojo

There are a number of user stories, with executable acceptance tests, for a social network for programmers from which we can explore and build teams based on a number of criteria.

The exercise is undertaken from a standing start. All you get is your computers and a network connection. You'll have to decide what language(s) and platforms you'll be developing for, set up version control if you think you need it (which, of course, you do), build automation, CI, all of that good stuff - none of it is provided.

Once you've got the sausage machine up and running, you then need to work through the user stories, designing and implementing working code in order to have someone outside your team verify that it does indeed pass each acceptance test on a machine that isn't yours.

Give yourself a maximum of a standard working day (8 hours) to complete it. Afterwards, assess the quality of the implementation code for readability, simplicity, lack of duplication etc. Give yourself a percebtage score for Code Cleanliness, and then multiply the points you picked up from passing acceptance tests by that.

Most good developers can do it in under a day. Curiously, teams of 3 or more tend to struggle to compete it in 8 hours. The rare great teams can do it in under 4 hours. Go figure!

You will learn LOTS, though you may well wish for the naïve simplicity of FizzBuzz by the time you get half-way through...

September 11, 2015

Tests Should Test One Thing (?)

The received wisdom - which chimes strongly with my own experience, and what I observe in teams - is that unit tests should have only one reason to fail.

There are several good reasons for this:

1. Small tests tend to be easier to pass, facilitating faster micro-iterations ("baby steps")

2. Small tests tend to be easier to understand, serving as clearer specifications

3. There tends to be less reasons for small tests to fail, making it easier to pinpoint the problem when it does

But, judging by discussions about an example in my previous blog post where I recommended not testing all the rules of FizzBuzz in a single test, some people disagree. Folk argue that single test like:

assertTrue(fizzBuzzer.fizzBuzz().startsWith("1,2,Fizz,4,Buzz,Fizz,7,8,Fizz,Buzz,11,Fizz,13,14,FizzBuzz")); more readable than several individual tests, each tackling speciic rules. Like:

assertEquals("1", fizzBuzzer.fizzBuzz().split(',')[0]);

There's a couple things to note in these exampes. Firstly, they are presented to require minimal context to understand. In reality, I would expect a good developer to refactor the test code to remove duplicate expressions for accessing individual elements in the FizzBuzz string. So tests might read more like:

assertEquals("1", fizzBuzzElementAtIndex(0));

I'd also expect the tests to be parameterised at some point, each test method named to document a specific FizzBuzz rule, like:

@Parameters({"3", "6"})
public void numbersDivisibleByThreeReplacedWithFizz(int index) {
assertEquals("Fizz", fizzBuzzElementAtIndex(index);

Someone looking to understand what FizzBuzz does - not how it works, but what it does - could simply read the test method names and see a list of the rules of FizzBuzz:

  • oneHundredIntegersSeparatedByCommas
  • integersDivisibleByThreeReplacedWithFizz
  • integersDivisibleByFiveReplacedWithBuzz
  • integersDivisibleByThreeAndFiveReplaedWithFizzBuzz
  • remainingNumbersAreUnchanged

  • I don't know about you, but I find that more readily accessible than oneHundredIntegersSeparatedByCommasWithAnyDivisibleByThreeReplacedWithFizzAndAnyDivisibleByFiveWithBuzzAndAnyDivisibleByThreeandFiveWithFizzBuzz, and more meaningful than the time-honoured cop-out: fizzBuzzStringShouldBeCorrect.

    What do you think?