March 22, 2017
Digital Strategy: Why Are Software Developers Excluded From The Conversation?I'm running another Twitter poll - yes, me and my polls! - spurred on by a conversation I had with a non-technical digital expert (not sure how you can be a non-technical digital expert, but bear with me) in which I asked if there were any software developers attending the government's TechNation report launch today.
As a software developer, do you feel your work and status as a professional is valued?— Codemanship (@codemanship) March 22, 2017
This has been a running bugbear for me; the apparent unwillingness to include the people who create the tech in discussions about creating tech. Imagine a 'HealthNation' event where doctors weren't invited...
The response spoke volumes about how our profession is viewed by the managers, marketers, recruiters, politicians and other folk sticking their oars into our industry. Basically, strategy is non of our beeswax. We just write the code. Other geniuses come up with the ideas and make all the important stuff happen.
I don't think we're alone in this predicament. Teachers tell me that there are many events about education strategy where you'll struggle to find an actual educator. Doctors tell me likewise that they're often excluded from the discussion about healthcare. Professionals are just there to do as we're told, it seems. Often by people with no in-depth understanding of what it is they're telling us to do.
This particular person asserted that software development isn't really that important to the economy. This flies in the face of newspaper story after newspaper story about just how critical it is to the functioning of our modern economy. The very same people who see no reason to include developers in the debate also tell us that in decades to come, all businesses will be digital businesses.
So which is it? Is digital technology - that's computers and software to you and me - now so central to modern life that our profession is as critical today as masons were in medieval times? Or can any fool 'code' software, and what's really needed is better PR people?
What's clear is that highly skilled professions like software development - and teaching, and medicine - have had their status undermined to the point where nobody cares what the practitioner thinks any more. Except other practitioners, perhaps.
This runs hand-in-hand with a gradual erosion in real terms of earnings. A developer today, on average, earns 25% less then she did 10 years ago. This trend plains against the grain of the "skills crisis" narrative, and more accurately portrays the real picture where developers are seen as cogs in the machine.
If we're not careful, and this trend continues, software development could become such a low-status profession in the UK that the smartest people will avoid it. This, coupled with a likely brain drain after Brexit, will have the reverse effect to what initiatives like TechNation are aiming for. Despite managers and marketers seeing no great value in software developers, where the rubber meets the road, and some software has to be created, we need good ones. Banks need them. Supermarkets need them. The NHS needs them. The Ministry of Defence needs them. Society needs them.
But I'm not sure they're going about the right way of getting them. Certainly, ignoring the 400,000 people in the UK who currently do it doesn't send the best message to smart young people who might be considering it. They could be more attracted to working in tech marketing, or for a VC firm, or in the Dept of Trade & Industry formulating tech policy.
But if we lack the people to actually make the technology work, what will they be marketing, funding and formulating policy about? They'd be a record industry without any music.
Now, that's not to say that marketing and funding and government policy don't matter. It's all important. But if it's all important, why are the people who really make the technology excluded from the conversation?
March 21, 2017
Poll Indicates Possibly Epic Brexit Brain DrainA small poll I ran on the Codemanship Twitter account paints a pretty grim picture for software development in the UK after Brexit.
Of the 265 people who responded, 12% said they had already left the UK. 10% had plans to leave. And a very worrying 26% were considering leaving.
These numbers aren't entirely surprising, when you consider an earlier poll showed about 80% of developers opposed Brexit, and nearly half of devs working in Britain are immigrants, many of whom suddenly don't feel very welcome and are struggling to live with the uncertainty about whether or not they'll be allowed to stay.
The Codemanship take on this is we shouldn't be surprised that necessarily very international professions like ours suffer under nationalism. It simply isn't possible for any nation to go it alone in computing.
But my fears are worse for the potential knock-on effects on the wider economy of a major brain drain. Think of all the investment projects - both in the private and public sectors - that have a significant computing component.
The short-termist may think "hoorah, less foreign devs = more work and higher pay for me!", but I fear they're just not thinking it through. If projects are too difficult to staff - and building good dev teams is already hard enough - then the natural (and perfectly legal) response from investors will be to take those projects elsewhere.
Government is finally catching on to just how reliant UK plc is on IT, but has yet to make the leap to recognising just how reliant UK plc is on people who write software. Even a brain drain of 10% would be likely to hurt economic performance. 25%+ is likely to be a disaster. And as more of the better devs leave, more good devs will be encouraged to follow.
They'll say, of course, that they're investing in addressing the skills shortage. But when you look at how much is being invested, you realise it's just a bit of PR, really. That budget needs several extra zeros adding to it to have any noticeable impact. And even when it does, the gap won't be filled overnight. It takes many years to grow a software developer. Increasingly, 2019 looks like a cliff edge.
The obvious solution, of course, is to remain in the single market and continue to accept freedom of movement. But this is looking unlikely now.
What are we to do?
I believe there could be a way forward, but it would require us to jump some hurdles that software managers have traditionally balked at. In particular, it will require us to favour smaller teams of better developers. And we know that most dev teams could be working smarter, paying more attention to quality, doing smaller releases more often, and so on. In other words, we might be able to ride out the brain drain by getting better at software development.
March 12, 2017
Why Products Don't Matter To Tech Investors, But Hype Does
They say 'you get what you measure', and in the world of tech start-ups this is especially true.
Having lived and worked through several tech bubbles, I've seen how the promise of winning mind-bogglingly big ("boggly"?) has totally skewed business models beyond the point where many tech start-ups are even recognisable as businesses.
The old notion of a business - where the aim is to make more money than you spend - seems hopelessly old-fashioned now. Get with it Granddad! It's not about profit any more, it's about share prices and exit strategies.
If your tech start-up looks valuable, then it's valuable. It matters not a jot that you might be losing money hand-over-fist. As long as investors believe it's worth a gazillion dollars, then it's worth a gazillion dollars.
For those of us who create the technologies that these start-ups are built on, this translates into a very distorted idea of what constitutes a 'successful product'. I have, alas, heard many founders state quite openly that it doesn't much matter if the technology really works, or if the underlying code has any long-term future, What matters is that, when it comes time to sell, someone buys it.
Ethically, this is very problematic. It's like a property developer saying 'it doesn't matter if the house is still standing 10 years from now, just as long as it's standing when someone buys it'.
Incredibly, very few tech start-up investors do any technical due diligence at all. Again, I suspect this is because you get what you measure. They're not buying it because it works, or because the technology has a future. They're buying it so that they, too, can sell it on for an inflated price. It could be a brick with "tech" painted on it, and - as long as the valuation keeps going up - they'll buy it.
You see, investors want returns. And that's pretty much all they want. They want returns from tech businesses. They don't care if the tech works, or if the business is viable in the long term. Just like they want returns from luxury waterside apartments that no ordinary person could afford to live in. They don't care if nobody lives in them, just as long as they keep going up in value.
Just like the property bubble, the tech bubble runs chiefly on hype. A £1,000,000 2-bed apartment is worth £1,000,000 because an estate agent or someone in a glossy colour supplement said so. An expectation of value is set. Similarly, Facebook is worth twelvety gazillions because the financial papers say it is. That is the expectation for tech start-ups. They can be valued at billions of dollars with a turnover of peanuts by comparison.
What makes tech businesses worth so much is their potential for expansion. Expanding your chain of coffeeshops requires you to overcome real physical barriers like finding premises and staff and buying more coffee machines and so on. Cost-wise, for a software business, there's not a huge difference in outlay between 1,000 users and 1,000,000 users. If only Costa could host their shops on the cloud!
Tech start-ups are just lottery tickets, where the jackpot can be truly astronomical. And what matters most in this equation is that the technology sounds good.
Exhibit A: the recent Articificial Intelligence bubble. News journalists have latched on to this idea - carefully crafted and lovingly packaged by tech industry PR - that real AI, the kind we saw in the movies, is just around the corner. What, again?
The true promise of AI has been 30 years away for the last 50 years. In reality, chatbot sales support sucks, websites designed by AI are crummy, and recommendations made by ad taregting engines are as asanine as they always were ("we see you bought a lawnmower; would you like to buy another lawnmower?") And as for self-driving cars...
But it doesn't matter that AI isn't as far advanced as they'd have us believe, just as long as we do believe it - for long enough to dip our hands in our pockets and buy some shares in the companies hyping it. And we'll do it, because there's a good chance those shares will go up in value and we'll be able to sell them for a profit. This is why few people are willing to say that the Emperor has no clothes. Too many own shares in the company that manufactured those clothes.
As a software developer, though, I struggle to find job satisfaction or to find any professional pride in making invisible clothes for silly Emperors. Yes, there are those of us - sadly, too plentiful - who'll apparently do anything as long as the money's right. But I'd like to think that's a different profession to the one I'm in.
March 6, 2017
Start With A Goal. The Backlog Will Follow.The little pairing project I'm doing with my 'apprentice' Will at the moment started with a useful reminder of just how powerful it can be to start development with goals, instead of asking for a list of features.
As usual, it was going to be some kind of community video library (it's always a community video library, when will you learn!!!), and - with my customer role-playing hat on - I envisaged the usual video library-ish features: borrowing videos, returning videos, donating videos, and so on.
But, at this point in my mentoring, I'm keen for Will to get some experience working in a wider perspective, so I insisted we started with a business goal.
I stipulated that the aim of the video library was to enable cash-strapped movie lovers to watch a different movie every day for a total cost of less than £100 a year. We fired up Excel and ran some numbers, and figured out that - in a group with similar tastes (e.g,, sci-fi, romantic comedies, etc) - you might need only 40 people to club together to achieve this.
This reframed the whole exercise. A movie club with 40 members could run their library out of a garden shed, using pencil and paper to keep basic records of who has what on loan. They could run an online poll to decide what titles to buy each month. They didn't really need software tools for managing their library.
The hard part, it seemed to us, would be finding people in your local area with similar tastes in movies. So the focus of our project shifted from managing a collection of DVDs to connecting with other movie lovers to form local clubs.
Out of that goal, a small feature list almost wrote itself. This is how planning should work; not with backlogs of feature requests, but with customers and developers closely collaborating to achieve goals.
It's similar in many ways to how TDD should work - in fact, arguably, it is TDD (except we start with business tests). When I'm showing teams how to do TDD, I advise them not to think of a design and then start writing unit tests for all the classes and methods and getters and setters they think they're gloing to need. Start with a customer test, and drive your internal design directly from that. Classes and methods and getters and setters will naturally emerge as and when they're needed.
When I run the Codemanship Agile Software Development workshop, we do it backwards to illustrate this point. Teams are tasked with coming up with internal designs, and then I ask them to write some customer tests afterwards. Inevitably, they realise their internal design isn't what they really needed. Stepping further back, I ask them to describe the business goals of their software, and at least half the teams realise they're building the wrong thing.
So, my advice... Ditch the backlog and start with a goal. The rest will follow.
March 2, 2017
101 TDD Tips - Complete SeriesFor the last 3 months, I've been posting tips for doing Test-Driven Development for effectively and sustainably to the Codemanship Twitter feed.
The series is now complete, and you can read all 101 TDD tips in this handy PDF
February 3, 2017
Will The Travel Ban Hurt US Tech Conferences?Recent worrying developments in US politics could have a significant impact on the country's standing in the tech industry.
The lightning-speed changes to immigration policy (and, yes, I did choose that phrase carefully) mean that a significant number of our peers are excluded from entering the country, and many more are afraid to leave in case they're not allowed back in.
Believable reports of all non-citizens facing stringent checks - e.g., of their social media accounts - when trying to enter the US mean that many more in our (mostly progressive and liberal) profession could face difficulties at passport control.
I've been seeing more and more tweets from people saying they won't be attending certain US tech events as a result of all this: either because they're worried they will be given a hard time getting there, or in solidarity with those who are banned.
So I ran a straw poll on Twitter, and the results suggest that - in fact - the majority of us feel the same way. 70% of the 160+ respondants said recent events had caused them to reconsider attending a tech event in the US.
We shall have to see how this plays out. But if this change of tone in immigration policy is going to be long-term, then I fear it could significantly damage the country's world-class reputation in the tech industry. To think that any nation can achieve technology - and therefore economic - success without international cooperation is sheer folly. But, as we've been seeing, the new administration is not immune to the odd bit of folly...
February 2, 2017
101 TDD Tips - #1-#80
We're now up to number 81 in my 101 TDD Tips series on Twitter, and I've pasted numbers 1-80 into a handy PDF for your convenience.
January 20, 2017
TDD 2.0 - London, May 10thAfter the success of last week's TDD 2.0 training workshop, I've immediately scheduled another one for the Spring.
It's 3-days jam-packed with hands-on learning and practice, covering everything from TDD basics and customer-driven TDD/BDD, all the way to advanced topics other courses and books don't touch on like mutation testing and non-functional TDD.
And it comes with my new TDD book, exclusive to attendees.
If you fancy a code craft skills boost, twist the boss's arm and join us on May 10th.
January 18, 2017
How Long Would Your Organisation Last Without Programmers?A little straw poll I did recently on Twitter has proved to be especially timely after a visit to the accident & emergency ward at my local hospital (don't worry - I'm fine).
It struck me just how reliant hospitals have become on largely bespoke IT systems (that's "software" to me and you). From the moment you walk in to see the triage nurse, there's software - you're surrounded by it. The workflow of A&E is carefully controlled via a system they all access. There are computerised machines that take your blood pressure, monitor your heart, peer into your brain and build detailed 3D models, and access your patient records so they don't accidentally cut off the wrong leg.
From printing out prescriptions to writing notes to your family doctor, it all involves computers now.
What happens if all the software developers mysteriously disappeared overnight? There'd be nobody to fix urgent bugs. Would the show-stoppers literally stop the show?
I can certainly see how that would happen in, say, a bank. And I've worked in places where - without 24/7 bug-fixing support - they'd be completely incapable of processing their overnight orders, creating a massive and potentially un-shiftable backlog that could crush their business in a few weeks.
Ultimately, DR is all about coping in the short term, and getting business-as-usual (or some semblance of it) up and running as quickly as possible. It can delay, but not avoid, the effects of having nobody who can write or fix code.
And I'm aware that big organisations have "disaster recovery" plans. I've been privy to quite a few in my lofty position as Chief Technical Arguer in some very large businesses. But all the DR plans I've seen have never asked "what happens if there's nobody to fix it?"
Smart deployers, of course, can just roll back a bad release to the last one that worked, ensuring continuity... for a while. But I know business code: even when it's working, it's often riddled with unknown bugs, waiting to go off, like little business-killing landmines. I've fixed bugs in COBOL that were written in the 1960s.
Realistically, rolling back your systems by potentially decades is not an option. You probably don't even have access to that old code. Or, if you do, someone will have to re-type it all in from code listings kept in cupboards.
And even if you could revert your way back to a reliable system with potential longevity, without the ability to change and adapt those systems to meet future needs will soon start to eat away at your organisation from the inside.
It's food for thought.
January 14, 2017
Codemanship Alumni - LinkedIn Group
Just a quick note to mention that there's a special LinkedIn group for folk who've attended Codemanship training workshops*.
With demand for skills like TDD and refactoring rising rapidly, membership is something you can display proudly for interested hirers.
* You'll need to list details of Codemanship training courses you've attended (what, when, where) on your LinkedIn profile so I can check against our training records.