March 22, 2017

Learn TDD with Codemanship

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.




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

Learn TDD with Codemanship

Poll Indicates Possibly Epic Brexit Brain Drain

A 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

Learn TDD with Codemanship

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.




February 3, 2017

Learn TDD with Codemanship

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...



September 29, 2016

Learn TDD with Codemanship

The Afternoon I Learned to Fly a Plane

When I was younger, my Dad was an amateur pilot. One time, he took us up for a flight, and when he'd got us up in the air and on our way - on a lovely calm and clear day - he let me take the controls for a little while. I remember after we landed being cockahoop that I'd learned how to "fly a plane".

Imagine, now, that I harboured ambitions to start my own airline. The only barrier to this plan is that I'm not a pilot, and hiring pilots is expensive. But, fear not, because - remember - on that calm and clear summer afternoon I learned how to "fly a plane".

Sure, I didn't learn how to take off. Or how to land. Or how to navigate. Or what to do when visibility is poor, or when the skies are choppy. And I didn't learn what all the knobs and dials and switches do, or what it means when that particular red light is blinking and what I should do in response. I didn't learn about basic aerodynamics, or how aeroplanes work or which bits of the plane do what, and how to check that everything's working before I take off. I didn't learn about the fuel the plane uses, where to get some, and how to calculate how much fuel I might need for my journey. I didn't learn how to land in an emergency. I didn't learn about speaking to air traffic control, nor how to use the radio for any purpose. I didn't learn about flight plans, or how to read aviation charts. I didn't learn about "air corridors", or about CAA rules.

But I had flown a plane, and was therefore surely only a couple more lessons away from being a pilot. I mean, it's easy. You just hold the steering wheel and keep the nose of the plane pointing to where you want to go. Right? What's that? It's called a "yoke"? Okay, I didn't learn that either.

This is all absurd, of course. It takes many hours of experience, and much study, before you're safe to be in charge of an aeroplane. There's so much that can go wrong, and you can't just pull over on to the hard shoulder when it does. when I had control, there was a qualified, experienced pilot sitting right next to me, and - in reality - he was in control. He talked me through it all the way, and if necessary could take over at a second's notice. I just did exactly what he told me to do.

But if I were a cynical opportunist, I might exploit this initial moment of euphoria that I experienced to make me believe that I can fly a plane. I can see the ads now: "Thinking of starting an airline? Why pay for expensive so-called 'pilots' when anyone can learn to fly on our 1-day course." This would be an exemplary commercialisation of the Dunning-Kruger effect: they don't know that they haven't learned to fly a plane, and we ain't about to tell them.

What that short flight with Dad did do, though, was get us excited about learning to fly. So much so, that for a good few years it was my brother's primary ambition to be a pilot.

A course claiming to teach you to fly in a day - or even an hour - would end up in court, of course. Grown-ups know it just isn't as simple as holding the stick and going in a straight line for 5 minutes.

So, why don't grown-ups know this about writing software?







July 6, 2016

Learn TDD with Codemanship

After Brexit, the UK Could Lose 1 in 3 Software Developers

One thing that has largely gone unreported in the mainstream media is the potential - and already very real - impact of Brexit on software development in the UK.

Our membership of the EU plays a big role in Britain's software development community. According to a poll I conducted on Twitter, roughly 1 in 3 developers working in the UK is an EU migrant. The sample size of 850 suggests this figure has to be at least in the ballpark of reality, and it chimes with my experiences training and coaching teams across the country.




1 in 3 software developers adds up to about 130,000 highly educated, highly skilled people helping to build UK plc's digital infrastructure. Hotly tipped to be the new Prime Minister, Theresa May has refused to give any assurances about their right to remain in the UK. So, right now, about 130,000 software developers, and the organisations they work for, have a sword of Damocles hanging over their futures. Nobody knows if they'll still be here in 2-3 years' time.

130,000 is a lot of developers to lose. Some of us might say "Excellent - higher pay for us locals!" But the reality is likely to play out differently. We're already hearing about IT projects being shelved indefinitely, as well as tech businesses who have either resolved to, or are in the process of deciding, to move out of the UK to where there's a bigger pool of available talent in the EU.

Imagine if the UK's construction industry lost 1 in 3 tradespeople. Indeed, construction in the UK is already taking a big knock from the Brexit vote. Without skilled EU workers, a heck of a lot of stuff here would not have been built in the last decade. International employers have the choice to go elsewhere. And they are choosing, it would seem.

But an office complex in London has to be built in London. Not so for software. There's really nothing stopping our biggest IT spenders moving IT to places like Paris, Brussels or Berlin. We've spent the last 25 years turning IT into a moveable feast. Now, it would appear, the feast is moving.

What worries me most, though, is less the loss of IT projects and jobs, more the loss of economic growth attached to these projects in the wider world. IT projects aren't being shelved in isolation. They usually exist for a purpose, and the much bigger business investment projects they're part of are being put on ice, too. The likely result is a cooling effect on the entire British economy.

Software developers - along with every other person in the UK - woke up to a hefty overnight pay cut on June 25th, thanks to the devalued pound. A Brexit-fuelled brain drain is going to hit software development hard. We can't just magic 130,000 developers out of thin air, and every non-EU country we might look to to bridge the gap has their own chronic shortages to deal with.

Of course, with tit-for-tat, there'll be a lot of British developers moving back to the UK. But nothing like 130,000.

I'm very much hoping that sanity will be restored, and both Right To Remain and freedom of movement will form a core part of any deal the Brexit negotiators do with the EU. But the hardened rhetoric from the likes of May, Leadsom and other prospective PMs makes me fearful that it's going to be a messy and acrimonious divorce, and that - as always - the children, including our young industry, will suffer most.

UPDATE: Yesterday, a motion proposed by Labour in the House of Commons that EU citizens currently living in the UK should be given the right to remain was passed by an overwhelming majority. It's not legally binding and has no direct impact on government policy, but it least shows that the will is there to resolve this problem. We must hope that the government realises the damage being done by prolonging the uncertainty and takes decisive action soon. This will be politically very difficult for them, though. The Leave campaign very strongly implied that immigrants would be leaving, even if they've rowed back on that since the referendum.







July 2, 2016

Learn TDD with Codemanship

What Does Brexit Mean for UK Software Development?

The effects of last week's momentous referendum result that has set the UK (well, England and Wales, at any rate) on a path to exiting the EU are already being felt in British software development.

For several months now, as Leavers and Remainers campaigned, the uncertainty created by the referendum about Britain's economic future has seen many employers put a freeze on unnecessary spending.

Anecdotally, I've been hearing since January about IT projects that have been put on ice, recruitment drives shelved, and - most pertinently to my business - training and mentoring deprioritised, as companies seek to reduced spending in case the unthinkable happened.

Now that the unthinkable has happened, what will it mean for the medium and long-term future of British software development?

Undoubtedly, we've relied on our EU membership to staff teams. Good developers are hard to find. It just got a lot harder. Since last Friday, I've seen several European developers I follow on Twitter say they'll be leaving the UK. This is not good. Indeed, there are entire companies here that have been started by EU migrants. The British economy has benefitted from their brains and their hard work. I quite understand why they might now be thinking "Why should I stay if I'm obviously not wanted?" The effect of a brain drain back to the EU will be noticeable.

And while many of us are calling for the status of existing EU migrants to be guaranteed, we may not know for quite some time if that's actually possible. It's likely to generate a lot of anger among Leave voters who thought they were voting to "send them home". And even if their status could be protected, the rise in anti-immigrant rhetoric, including a step-change in attacks and abuse in the streets, is unlikely to have no effect on choices to stay.

Some of our biggest employers have already made it clear that they are looking into potential other locations for their businesses. If banking, in particular, decides London is no longer the place to be, that will put an end to the largest concentration of software developers in Europe - the City of London. "Tech City", just up the road, would be likely to feel the shock waves.

And being out of the EU is likely to have an impact on investment for tech start-ups, too. For years, the UK was considered to be one of the best places to start a software company. Being in the EU was part of the attraction.

Meanwhile, UK citizens - born and educated here - are investigating other possibilities, like Scotland (if it becomes independent), Ireland and Canada. Before our final exit from the EU, we can probably expect a further brain drain, losing thousands of great software developers who have stronger liberal and internationalist leanings.

But, with no signs of a social democrat resurgence on the horizon (with the main opposition doing their level-best to ensure we don't get that choice), the writing's on the wall for a future Britain that's both much diminished economically, and farther to the right politically than the average software developer may be comfortable with.

Software developers understand that you can't run a high-tech 21st century economy on industrial 19th century principles. Evidently, our political class - for all their talk of "high-tech, high-wage" economics - are stuck in the past. Few if any of them know what it means, and right now none of them seem to appreciate what damage has been done to this vision for Britain's future.

For decades, Britain has punched above her weight. But after several years of clamouring to "get kids coding", the EU referendum may just have closed the door on Britain as a software development powerhouse.

Most worrying of all is the failure of politicians to appreciate that our ability to create and adapt software is now a very significant limiting factor on our entire economy. Just ask how many developers working on big government projects at the moment are EU migrants, for example.


Software development in the UK will limp on, no doubt. But, the way things are shaping up, it could be much diminished, and the UK economy with it.

May 4, 2016

Learn TDD with Codemanship

Scaling Kochō for the Enterprise



Unless you've been living under a rock, you'll no doubt have heard about Kochō. It's the new management technique that's been setting the tech world on fire.

Many books, blogs and Hip Hop ballets have been written about the details of Kochō, so it's suffice for me to just quickly summarise it here for anyone who needs their memory refreshing.

Kochō is an advanced technique for scheduling and tracking work that utilises hedgehogs and a complex network of PVC tubes. Task cards are attached to the hedgehogs - by the obvious means - and then they're released into the network to search for cheese or whatever it is that hedgehogs eat. The tubes have random holes cut out above people's desks. When a hedgehog falls through one of these holes, the person at that desk removes the task card and begins work. Progress is measured by asking the hedgehogs.

So far, we've mainly seen Kochō used successfully on small teams. But the big question now is does it scale?

There are many practical barriers to scaling Kochō to the whole enterprise, including:

* Availability of hedgehogs
* Structural weakness of large PVC tube networks
* Infiltration of Kochō networks by badgers
* Shortage of Certified Kochō Tubemasters

In this blog post, I will outline how you can overcome these hurdles and scale Kochō to any size of organisation.

Availability of hedgehogs


As Kochō has become more and more popular, teams have been hit by chronic hedgehog shortages. This is why smart organisations are now setting up their own hedgehog farms. Thankfully, it doesn't take long to produce a fully-grown, Kochō-ready hedgehog. In fact, it can be done in just one hour. We know it's true, because the organiser of the Year Of Hedgehogs said so on TV.

Structural weaknesses of large PVC tube networks


Steel-reinforce them.

Infiltration of Kochō networks by badgers


Regrettably, some managers have trouble telling a badger from a hedgehog. Well, one mammal is pretty much the same as another, right? Weeding out the badgers on small Kochō teams is straightforward. But as team sizes grow, it becomes harder and harder to pay enough attention to each individual "hedgehog" to easily spot imposters.

Worry not, though. If you make the holes bigger, badgers can work just as well.

Carry on. As you were.

Shortage of Certified Kochō Tubemasters



Many teams employ CKTs to keep an eye on things and ensure the badgers - sorry, "hedgehogs" - are following the process correctly. But, if hedgehogs are in short supply these days, CKTs are like proverbial hen's teeth.

Only a few teams dare try Kochō without a CKT. And they have learned that you don't actually need one... not really.

In fact, Kochō can work perfectly well without CKTs, tube networks, hedgehogs, or Kochō. Indeed, we're discovering that not doing Kochō scales best of all.





April 23, 2016

Learn TDD with Codemanship

Does Your Tech Idea Pass The Future Dystopia Test?

One thing that at times fascinates and at times appals me is the social effect that web applications can have on us.

Human beings learn fast, but evolve slowly. Hence we can learn to program a video recorder, but living a life that revolves around video recorders can be toxic to us. For all our high-tech savvy, we are still basically hominids, adapted to run from predators and pick fleas off of each other, but not adapted for Facebook or Instagram or Soundcloud.

But the effects of online socialisation are now felt in the Real World - you know, the one we used to live in? People who, just 3-4 years ago, were confined to expressing their opinions on YouTube are now expressing them on my television and making pots of real money.

Tweets are building (and ending) careers. Soundcloud tracks are selling out tours. Facebook viral posts are winning elections. MySpace users are... well, okay, maybe not MySpace users.

For decades, architects and planners obsessed over the design of the physical spaces we live and work in. The design of a school building, they theorise, can make a difference to the life chances of the students who learn in it. The design of a public park can increase or decrease the chances of being attacked in it. Pedestrianisation of a high street can breath new life into local shops, and an out-of-town shopping mall can suck the life out of a town centre.

Architects must actively consider the impact of buildings on residents, on surrounding communities, on businesses, on the environment, when they create and test their designs. Be it for a 1-bed starter home, or for a giant office complex, they have to think about these things. It's the law.

What thought, then, do software developers give to the social, economic and environmental impact of their application designs?

With a billion users, a site like Facebook can impact so many lives just by adding a new button or changing their privacy policy.

Having worked on "Web 2.0" sites of all shapes and sizes, I have yet to see teams and management go out of their way to consider such things. Indeed, I've seen many occasions when management have proposed features of such breath-taking insensitivity to wider issues, that it's easy to believe that we don't really think much about it at all. That is, until it all goes wrong, and the media are baying for our blood, and we're forced to change to keep our share price from crashing.

This is about more than reliability (though reliability would be a start).

Half-jokingly, I've suggested that teams put feature requests through a Future Dystopia Test; can we imagine a dark, dystopian, Philip K Dick-style future in which our feature has caused immense harm to society? Indeed, whole start-up premises fail this test sometimes. Just hearing some elevator pitches conjures up Blade Runner-esque and Logan's Run-ish images.

I do think, though, that we might all benefit from devoting a little time to considering the potential negative effects of what we're creating before we create it, as well as closely monitoring those effects once it's out there. Don't wait for that hysterical headline "AcmeChat Ate My Hamster" to appear before asking yourself if the fun hamster-swallowing feature the product owner suggested might not be such a good thing after all.


This blog post is gluten free and was not tested on animals






March 24, 2016

Learn TDD with Codemanship

The NPM Debacle: Programmers Don't Know Their Own Strength

This NPM debacle has reminded me of a couple of issues in software development that I think maybe we all need regularly reminding of.

Most importantly, they collectively broke the First Law of Software Development - thou shalt not break shit that was working.

The programmer in question broke it by withdrawing all his packages. The guardians of NPM broke it by making it possible to actually do that at all.

It's shocking, of course, that a single developer can so easily shit on the duvets of literally millions of code bases. And we can point and gasp and say "well I never!" and roll our eyes. But, hey, it's not like almost every open source software development team does this on a regular basis, is it?

It turns out that breaking code that was working, by changing APIs and removing stuff folk were using and arbitrarily renaming things and so on, is pretty common on many open source libraries and frameworks, as well as web APIs, that gazillions of lines of code have been built on.

One shudders to think just how much time and money we're wasting every year fixing stuff that was working just because of this. My guess would be in the many billions of dollars.

Here's the thing, when we write reusable code, presumably in the hope that people will reuse it, we take on a responsibility. The more people reuse our code, the greater that responsibility. Whether you realise it or not, if you write a function that left-pads a string and everybody uses it, then you have the weight of billions of dollars invested in code on your shoulders. It beggars belief that a temper tantrum can end with an entire development community coming into work the next day to find their software mysteriously broken. How many hundreds of thousands of hours did it take them to fix that collectively? How many millions, or tens of millions of dollars was wasted because of that temper tantrum?

This is something as a society we're going to have to get used to. The incalculable impact of a single person over just a few lines of code has no direct comparison in any other industry. No other kind of professional can wreak that kind of havoc and cause that amount of damage with so little time and effort. 50 years ago, it would be extremely difficult for, say a disgruntled car factory worker to break every single car they've sold. Now, a pissed-off software developer could potentially do it with a single Git commit. Look at how many major car recalls recently have been software-related.

We don't know our own strength. When society remodels itself on software foundations, and someone's little string formatting function ends up in a billion devices, our technological civilisation becomes a house of cards.

So, in summary on that issue: we need to get our shit together before legislators get it together for us. It's only a matter of time before a VIP non-programmer notices just how much these things can cost and how much damage they can do.

The second issue the NPM-string-padding hoohah raises is should programmers create big dependencies on 3rd party libraries just to left-pad strings? This is like buying a Mercedes because you need the cigarette lighter.

I recall meeting a team who had a need to sort of a list of strings in a programming language that didn't have sorting built in to the core libraries, and decided the best solution was to do it using SQL Server.

I see developers being a little too eager to add more and more external dependencies to their projects, often to solve little problems like sorting a list or padding a string. As we're seeing - on a galactic scale - dependencies can hurt us. There's a balance to be struck here between not unnecessarily reinventing the wheel when a solution exists, and strapping our code to some giant - poorly managed - framework or library when it would actually be simpler to roll our own.

Open source dependencies, in particular, tend to get added with less thought and oversight - probably because they're free and developers don't need to go through a procurement process to get them. We can add this to the growing list of things that developers can do with little thought, that can have a potentially huge impact. I see developers occasionally making $multi-million decisions, blissfully unaware that they're making $multi-million decisions.

A bit more thought is required, please.