The Shopify Builder development team has come a long way since we first started building stores in 2012. We’ve improved our processes exponentially and, in our view, we’ve reaped the rewards in our results.
While we’re learning new tricks, perspectives and methods every single day, there have been a few real lightbulb moments that have helped us to deliver a better product – and deliver it in a better way.
Here are our top three from the last three years that we believe apply in every web development scenario:
The Last 20% of the Work Will Take 80% of the Time. Plan for it
If you’ve ever moved house after a long time somewhere, you’ll have noticed something about packing – those final bits and bobs. The spare parts that you’re sure are totally essential for some expensive piece of machinery (if only you could remember what), the seemingly endless stationery drawer and those mysterious wires, are in fact not the last ten or twenty per cent of the work; they constitute well over half of it.
The macro stuff has high apparent impact (all your clothes in bags, just like that!) but it’s the so-called “finishing touches” that will leave you wailing, clutching a miscellaneous piece of plastic in each hand, the night before moving day. This is one version of the ‘Pareto’ 80:20 Principle and it has very real consequences for almost any web development project.
What seems like the bulk of the work, namely coding templates up to create a website that resembles the design concepts, will happen incredibly quickly. “Great,” you’ll think. “Basically done, and so much quicker than we expected!”. However, through working on over three hundred development projects, we’ve learnt that a serious chunk of time needs to be allotted to tie up those loose ends – up to four times that for the bulky stuff.
What constitutes this final twenty per cent? Bugs, exceptions to the rule, performance, scalability, knitting functionalities together, administrative setup… All of this tends to take more time than you imagine (a few minutes may actually be twenty, or forty, or sixty) and is more likely to contain niggly little problems that were not foreseen, taken into account in the developers’ estimates or worked through in the planning stage.
When we schedule a project, we work as a team to estimate the time required to get the first eighty per cent of the code in place. Then, depending on the particularities of the build, we multiply that figure by two, three, four or even five. And time is not the only variable; sometimes the entire development team will work together on the final twenty per cent of the work – we will not be beaten by the Pareto Principle!
The developer stereotype is of a solitary worker, coding late into the night with only fast food for company and other people only an irritating distraction.
But a pattern of working we see daily in the office suggests quite the opposite. Our developers solve problems by sharing and discussing them with the rest of the team. This is not just a case of more brains but of synergy: the solution is not just the sum of individuals’ ideas but a product of their comparison and juxtaposition.
This process is not only about getting other people’s perspectives but is well recognised in educational studies as helping solidify understanding through teaching. The teacher cannot gloss over links or make assumptions; they are forced to really inspect and work through them. The teacher shifts their perspective to that of somebody new to the situation, perhaps seeing the problem with fresh eyes or, for the first time, in its entirety rather than its details.
If you’re a manager, nurture an office environment that encourages your team to work and problem-solve collaboratively. This could mean regular trouble-shooting meetings, a dedicated online discussion platform or simply arranging workstations more communally. If you’re a developer, be vocal about your work – even if it means interrupting your co-worker. Your time to be pestered will come.
With self-help professionals constantly telling us about the power of positive thinking, especially when it comes to success in business, it’s not very fashionable to be an Eeyore or a worrier. But, harnessed constructively, worry can be a very powerful tool in spotting and assessing risks so that they can be dealt with effectively and efficiently.
This is one iteration of the concept of spending more time planning to spend less time doing. Although it is always tempting to get stuck in and relish the comfort of some concrete work under your belt, taking some time to plan your strategy can reduce the chance of dithering or having to double-back further down the road.
A key part of this planning is risk assessment – allow time in the schedule to ponder and discuss your biggest fears for a project. Worried that two apps could clash with one another? Run some tests, do some research or contact the app developers. Worried about how exactly some custom functionality will play out? Take time to write step-by-step development notes or sketches.
It’s easy to avoid facing a lurking worry until you absolutely have to, but identifying the precise cause of that knot in the pit of your stomach, and then facing it head on, will do wonders for your project – and your stress levels.
If you’re looking to get in contact with us about a development project, please get in touch with our New Business Manager, Dan: [email protected].