Skip to content
Search
Generic filters
Exact matches only

3 Fundamentals of Better Code

This applies equally to systems as a whole as well as code. If they have been designed and/or built in isolation, by a lone dev, they are not ready for production use on any meaningful scale. The code/system may well function perfectly fine, and sure that’s acceptable for a personal project. But when you work as part of a team, on projects used by thousands or millions of people, just ‘functioning correctly’ is not the measure of production ready.

So what is missing when things are done in isolation? At the very least, outside perspectives, experience, and questions would not be taken into account. The resulting creation is unlikely to be satisfactory to all who have a stake in it. Allowing stakeholders to have a voice and input is essential, whether they be customers of the end product, fellow devs tasked with maintaining and building upon it, business or marketing people focused on ‘selling’ it, or anyone that has to support, use, or ‘stand by’ the creation.

More importantly than this though is that the lone dev would be the sole ‘owner’ of the result, which is a real problem when something goes wrong. When there is a ‘lottery factor’ of one, it is bad for the dev who built it, and the others who have to help deal with it. (Side note: I prefer the term lottery factor to bus factor, as the imagery of a colleague winning the lottery vs being hit by a bus is much nicer. Both essentially represent how many people being no longer available would put a project in jeopardy.) A low lottery factor is also bad for the velocity of future improvements to a project. Having a variety of people who understand how something was built and how it works means they can all help move it forward, as well as help share the knowledge to others.