Softwire Blog

Why enterprises can be disrupted

25 May 2017, by


Software engineering is the foundation that allows new consumer services, efficient back-office systems, and market-disrupting products to be created. As with all foundations, it’s important to get the basic principles correct, and we believe that these principals are not only technical but creative. There are so many possible implementations of software applications that an environment which stimulates creative and innovative solutions will deliver the best results.


If we start with the humble software engineer, we can look at what motivates them to do their job effectively and create software to make a difference. A large body of research exists (summarised neatly in Drive[2]) to demonstrate that extrinsic motivators (reward and punishment) work well for simple rule-based tasks, but work very poorly for creative or complex tasks. For these types of task, we can measure the presence (or lack of) three types of intrinsic motivation:


  • Autonomy: the urge and capability to direct our own work and make our own decisions
  • Mastery: the desire to master our tools and improve our skills
  • Purpose: the need to do something with meaning, and with clear direction


These motivators provide us with a language to discuss how to create an environment that is productive and efficient, producing brilliant software; conversely, it provides terms to explain why companies can have environments that are stagnant and inefficient, leading to software that no one wants to use.



We start with the hardest motivator: autonomy. It might seem confusing that autonomy is important – isn’t the job of a software engineer to implement something that the business has decided is necessary? Allowing engineers to dictate their own workloads is only a single example of autonomy (and, incidentally, one that Google and others have used to great effect[3]). Indeed, most engineers are happy to admit that UX or business analysis are not their areas of expertise. However, autonomy is much deeper than this – it’s about giving engineer the freedom to decide how to implement what’s required (what processes or frameworks to use), and the responsibility for delivering working software to end users. Teams with high autonomy are more efficient, as they’re empowered to remove processes that slow development effort down, and free to adopt better tools or frameworks as they become available.


One of the reasons that agile practices (and by extension, practices like Continuous Delivery and DevOps) have been so successful is that they push autonomy down to the team level, focus on cross-functional teams, and encourage continuous change. This isn’t to say that agile methods such as scrum or kanban are the only methods for achieving autonomy: they’re just a particularly well-known and effective one.



For software engineers, mastery of a toolset, skill, or framework is immensely satisfying. However, Mastery is more than perfecting one skill: it’s heavily reliant on continuous improvement. It should be obvious that technology is a rapidly-changing industry, and that adopting new tools and skills as they become available is the key to success.


Mastery of technical improvements

By now, the analogy of technical debt[4] is well known and addresses one aspect of mastery (the desire to improve the code being worked on). Long-running codebases with low technical debt are strongly correlated with products that are reliable, high-quality, and respond predictably to change requests – Google is an excellent example of a company that invests heavily in reducing debt[5]. However, technical debt is an imperfect analogy as it is unquantifiable, and must be measured by its side effects: slow, unreliable delivery, and disenfranchised, unmotivated developers. Business that focus solely on putting features in front of customers win in the short term, but over the long term incur sufficient debt that delivering even simple features takes a huge effort.


Mastery of personal development

While developers will generally self-improve over time, this can be greatly accelerated with the right support and processes, including formal and informal training. These two approaches differ in what they aim to achieve, and personal development is normally most effective when they’re combined. Training courses and conferences aim to teach a specific skill, or give a breadth of knowledge about the industry. They also provide opportunities to network and engage with companies working on similar problems. By contrast, coaching and mentoring are much more individual, helping developers improve their strengths and mitigate weaknesses. These approaches can deliver huge benefits to teams and organisations:


  • Ensuring that knowledge is spread across the team, removing single points of failure and improving consistency
  • Improving skills and abilities
  • Allowing individuals to take on more responsibility, resulting in more capable teams


The rate at which software development changes is phenomenal; the tools and technologies for most new projects have changed in the last 5 years, and are radically different to those 10 years ago. The NodeJs ecosystem is the canonical example; just over 5 years old, NodeJs and npm now have over 4 million active developers, and are used by thousands of companies.


Mastery deals less with each individual change, and is more concerned with the process of adapting to changes over time. It’s important to determine where best to invest in changing technology, but as we saw from autonomy, the correct place to make this decision is within an engineering team.



Given that most software engineering is product or service-focussed, providing a clear backlog and direction of work gives a purpose to both individual and team efforts. In addition, a frequent and well-defined release schedule provides a visible goal to focus on. A purpose can be highly effective when combined with the goals of Mastery; to not only deliver software, but to get better at the process of delivering software. Teams with a strong sense of purpose are more likely to succeed, and less likely to get distracted and solve unrelated problems.


Scaling and disruption

Autonomy, mastery, and purpose are useful tools as they allow us to examine teams (or individuals) separately, and suggest targeted improvements. Some teams may have a strong sense of purpose, but are held back by poor tooling, whereas other teams may be able to make wide-reaching decisions but lack a clear goal. The ability to address the needs of each team in isolation allows this approach to scale. There are obvious technical challenges with scaling development work across multiple teams (particularly communication overhead made famous by the Mythical Man Month), but teams that are motivated to succeed will overcome these problems for themselves.


Looking at the world through the lens of intrinsic motivation it’s possible to see why a startup can deliver a disruptive product, but an industry behemoth can struggle to update its flagship products and services. The startup’s developers have autonomy (freedom from constraining structure and processes), mastery (time and money to improve skills and tooling), and purpose (the vision of the startup). Large organisations can be disruptive – Apple, Amazon, and Google regularly deliver ground-breaking products – but to do so requires continual effort and focus.


[1] The perils of ignoring software development:


[2] Drive: the surprising truth about what motivates us:


[3] Google’s “20 percent time” in action:

[4] TechnicalDebt:

[5] Searching for Build Debt

Alexa is the new command line

19 May 2017, by


In the beginning, man created the command line interface, and lo! There were commands that no-one could remember, and syntax designed by Satan himself.


User interface experts call this problem discoverability; given that you’re at a particular point in an application, how do you find where you can go next, or what you can do? The early graphical user interfaces beat the more-powerful command line because they allowed users to discover features without needing to remember that a feature was there. This property turns out to be so compelling that command lines were relegated to, well, somewhere that you can discover with a bit of digging.


The unchallenged dominance of the graphical user interface is facing a new contender: voice-activated assistants, such as Siri, Alexa, and Google Assistant. These ever-listening devices attack the soft underbelly of the graphical user interface; the (non-alternative) fact that you need a graphical screen to interact with them, and you need to be within touching distance of that screen. With voice-activated assistants, you only need to be in yelling distance (or have your phone nearby).


Once you’ve vocally activated your assistant, you need to give it commands. One of the hard problems with this, and with life in general, is that different people ask questions in different ways. Where you’ll say “Alexa, what time is it?”, I’ll proclaim “Alexa, what be the hour?”. Internally, the servers powering Alexa need to figure out that we’re asking the same question, which we call disambiguation. One of the strengths of command and graphical interfaces is that input is unambiguous (yes, you really did click the “delete all my files” button). Unfortunately, disambiguation is a hard problem, even for relatively simple commands. Try adding “fork handles” to your shopping list to discover this for yourself.


If we can make the simplifying assumption that we’ve solved the above problem, we’ve just discovered a deeper problem; how do you do discoverability on a voice assistant? “Siri, tell me everything you can do” is likely to flatten your phone battery pretty quickly (which I don’t believe is an intended feature of Siri), nor does it help you decide if Siri can order you a late-night Chimichanga delivery. At the moment, this isn’t really a problem because voice assistants are very limited in what they can achieve. Alexa is about to run face-first into this problem with the addition of Traits. Given two Alexa devices with Traits, there’s no way to tell which Traits are available. Without a good solution to the discoverability problem (wait, you were expecting me to have one?), voice assistants will be limited to simple commands and instructions.


An interesting property of command lines that hasn’t featured in voice assistants yet is that of composition (i.e. can I chain the output of multiple commands together?). We even have this concept in the graphical world – the humble copy-paste allows us to move data from one program to another with only a modicum of mouse-pointer shuffling. Telling Siri to “email the news story about the giraffe to my mother” could lead to some unexpected (but possibly hilarious) results. Which is a pity, because composition is incredibly powerful, and we really ought to continue making it available.


Is the end nigh for our mellifluous Alexa? It seems unlikely; convenience outweighs theoretical concerns, and there are some genuine good uses as well as novelties and party tricks. Only time will tell. If we can figure out how to ask for it, anyway.

Being a good ally

10 May 2017, by

The technology industry is notoriously bad at embracing diversity. Almost everyone acknowledges the problem, but a lot of folks don’t know where to start. As a non-binary person of colour who’s worked in technology for their entire career, I’ve seen and experienced a lot of things that I think could be better. Here at Softwire, my colleagues often ask me what they can do to help. This is where allyship becomes important – to amplify our voices and help make the technology industry (and the world!) a more equal place.

Who can be an ally?

Anyone can be an ally! It doesn’t matter what your own background is, or how you identify. Even if you’re going through your own struggle, you can still be an ally to someone whose struggle may be slightly different than yours. If you don’t think that applies to you, that’s ok too – there’s no need to feel guilty about privilege. What we call privilege may just mean that there are more ways that you can help out.

A good ally isn’t a perfect human being either – we’re all flawed, and we all carry our own biases. Part of allyship is educating yourself and working to overcome yours.

What do I have to do?

I can’t speak for all marginalised folks (nor would I want to!) but here are three steps that I’d suggest to get you started.

Step 1: Talk to us

Ask your friends and colleagues what it’s like for them (understand, though, that sometimes talking about it is hard, so be patient). You may already have done some reading up, which is awesome, but don’t assume that you already know what your friend’s or colleague’s experience is like. Everyone’s experience is different. Your friend may have a very different experience from someone you’ve read about, or someone you’ve talked to in the past. The more you talk to us, and listen with humility and an open mind, the more you learn about us as individuals and as a group.

Step 2: Believe us

When you talk to us, some of what you hear may surprise you! It’s easy to imagine that our negative experiences are rare, not only because you may not experience them yourself, but also because you may not hear about them. For a person who feels marginalised, it can be embarrassing, or worse, frightening, to face the prospect of coming forward. In some cases, they may feel personally threatened.

Those who do speak out usually feel more comfortable doing so among other members of their group – they know these are people who will understand. If you’re not a member of that particular group, you may never get to hear those stories. That makes it all the more important, when someone does make the leap of faith to confide in you, that you believe everything they say. By believing them, you demonstrate that it’s safe to come talk to you about their experiences.

Step 3: Support us

Get involved! There are loads of ways to help support marginalised and underrepresented folks in the technology industry. You can lend your skills at events like codebar, support inclusive events like AlterConf or Diversity in Tech, sign the Minimum Viable Diversity Pledge, or do lots more stuff like those.

Don’t neglect the people you already know, as well. If you’re managing someone who may be from a marginalised group, check in on them. If there’s something they’ve asked for in your 1:1s, make sure you follow through.

Most of all, make sure you give us space to be heard, and back us up when we need it.

What’s next?

Remember that “ally” is not just a noun, it’s also a verb, so make sure you do the work to help out. This article is just a starting point; there are a lot more useful resources out there when you’re ready to take your journey as an ally further. The job is never done – there’s always more to learn, and more to do, so keep working at it!

What’s keeping voting from moving online?

6 May 2017, by

With the general election swiftly approaching, conversation in the office this week turned to why we’re still unable to vote online and what might have to change in order to make voting online a possibility.

The first and probably most obvious argument against online voting is security of the system. In a year of particularly prominent news relating to online security breaches and cyber-attacks, such as the recent attack on the NHS, it’s only too clear that the internet isn’t exactly the safest of places. Moving voting online opens it up to many potential problems, not least from external groups but even from the people who might take responsibility for building the systems by which we could vote online. Simply, it would be too difficult to find a totally impartial party to create a voting system. Regardless of whether a company had any political affiliations or motivations, it would be nigh on impossible to put together a team of developers who had no political leanings of their own.

And if it’s not possible to impartially build a voting system then, it’s difficult to expect the public to put their trust in the system and believe that their vote will be accurately counted and untampered with. Trials of electronic voting machines in the past have already flagged various problems, including demonstrations of the ability to alter the software they run on with just 60 seconds and a USB stick. Creating a voting system where anyone could simply vote from their desk at work or their smartphone would throw the net wide open to all manner of threats. There’s no simple way that the public could be shown that their votes had been counted and communicated accurately.

Convenience would be the most cited reason for allowing voting to take place over the internet, but one could argue that the fact that people have to make the effort to go and vote means that only those that have a real interest in the outcome of the election are likely to bother voting. Online voting would be open to manipulation on a large scale, but also due to convenience, it could be quite easy to persuade someone who wasn’t planning to vote to let someone else use their vote. By making voting so convenient, votes could end up being traded for something so minimal as a cup of coffee or a sandwich. Postal voting lessens the likelihood of such simple manipulation taking place.

It doesn’t seem that online voting is something that will happen anytime in the foreseeable future and with the majority of the kinks having been ironed out of the current paper voting system, other than convenience for both the voter and the people responsible for counting the votes, there’s no great argument that online voting would improve anything other than voter turnout. It would however be interesting to see online voting tested parallel to a paper vote to test the increase in turnout, but until an online vote is counted as relevant it wouldn’t be open to the genuine threats that online voting is so exposed to. Essentially, even testing an electronic system alongside the current system would simply be likened to an elaborate exit poll at best. So for now at least, it looks like we’ll be sticking to paper and pencil.