In the software development industry over the last few years, there’s been a movement towards ‘craft’. Sadly, though, it’s become a bit of a sweeping statement, offered as a blanket approach to software development – meaning that you're either executing to the highest of your abilities at all times, or doing it wrong.
Obviously, this is not what the craftsmanship manifesto says, nor the impression I get when talking to some of the people active in the movement. But its use as a defensive shield obscures the utilitarian nature of software in favour of skill and finesse, and this is a worrying trend. One that we’ve seen, for example, when interviewing candidates for our development team.
All software has context, and this is what should influence and define your coding practices. I gave a talk recently on this topic, which you can watch here.
Let’s say a client comes to ustwo to build a new email client. It’s a saturated market, and email is such a critical tool these days that getting people to try something new is very difficult. There needs to be a unique selling point that practically glows in their product vision. What is the thing that will make people switch: Is it going to be incredibly beautiful? Is it going to be super fast? Is it going to be extremely secure?
In each of those scenarios, software developers must adapt their practices and their craft to fulfill that vision.
Software development and context
If I had to build the most beautiful email client possible, I'd be using 3rd party motion libraries. Maybe I'd tweak them further so the effects are unique, spending a great deal of time in every single detail of the UI to surprise and delight the users. But one of the trade-offs, for example, would be that it is very difficult to write automated tests for incredibly rich UIs, making it harder and more expensive to assure reliability.
On the other hand, if security is paramount I would limit the amount of 3rd party libraries I use since they are vectors of attack through XBI or through outdated dependencies. For that reason I might hire a security expert to write a bespoke, low-level networking library, something that would be unthinkable in the previous scenario, but justified in areas of extreme security need. I would also strive for 100% test code coverage and very defensive coding.
Same product, different visions, different software development practices.
Consider also Jocelyn Goldfein’s experience about the ‘right’ way of building software while working as VP of engineering at VMWare and as Director of Engineering at Facebook.
When it was a startup, VMware needed to offer predictable dates and high reliability because they had to convince conservative enterprises to buy operating systems from an upstart new vendor.
In Facebook’s startup days, they needed to move quickly because first-mover advantage meant everything for a product based on network effects.
As you can imagine, the software development practices at both places were very different because the business needs were also very different. And both were right.
So how do you know whether a specific practice is adequate for your project or not? To begin with, set it against your product vision, and consider whether it matches:
Mars is 250m miles away, it takes us 5 years and $2.5B to release, should I just force push this little change to the main branch without tests or code review?*
It's also important to consider at what point in its lifetime the product is. Is it already established in the market with a non-negligible user base, or is it such early days that the business plan has yet to be validated? You might be asking yourself something like this:
We need a proof of concept to validate the product, so does this backend at this point really need a micro-services architecture that can scale to 5M concurrent users or can I get away with a Google Spreadsheet behind an API?
At ustwo we love our craft, we really do. But people come to us to solve business and user problems. No one has ever asked us “could you please build me a software?”
So, we must come to terms with the fact that software is a means to an end. Its development practices are not good or bad, in absolute terms: There are only trade-offs. Quality is just not an intrinsic property of software! *Read more about what it takes to put robots on Mars.