“Move fast and break things”.
In the years since these words were first uttered by Facebook founder Mark Zuckerberg, the motto has become somewhat of a mantra among tech entrepreneurs, product builders and developers.
Zuckerberg, like many of his peers, believe that features - and software more generally - should be built and launched as quickly as possible, even if this focus on speed results in messy code, is disruptive to an industry, or goes against existing legal regulation.
To some, this is an attitude that allows developers to take products to market quickly, and with the greatest impact. To others, this approach undermines the tried and tested processes put in place by larger organisations to ensure code is clean and maintainable, security vulnerabilities are mitigated, legal requirements have been met, and tasks have been methodically managed, monitored, tackled and completed.
Here lies the issue.
The tech industry moves incredibly fast, and developers - and tech software companies in general - are challenged with finding the balance between quality and velocity; methodically building features and definitively marking tasks as complete, or focusing on speed and accepting that completeness is a state that simply does not exist and so is futile to pursue.
In this article, we’ll consider whether projects - or features - are ever actually done, and the impact of mindset around this issue on the software that developers build.
The "Not Done" Philosophy
At first glance, leaving projects incomplete might sound counterproductive.
Tasks are set in order to be completed, right? Well.. sort of.
For a long time now, the software industry has been dominated by the agile philosophy, which breaks down large tasks into smaller, more manageable ones, and gives teams a framework by which they can plan features, sprint to deliver them, reflect on their strengths and weaknesses, before iterating on them to improve them.
When that first cycle ended, was the first version complete? Or was the feature a long way from completion, when we consider what it will likely look a year from now.
In this context, projects are never complete, and represent ongoing opportunities for enhancement and innovation. They celebrate the process of constant learning and refinement, much like agile development.
It’s Done… But is it Done Right?
The agile methodology might frustrate some who strive for the feeling of satisfaction that you get when a task is complete, and can be left behind. However, if we were to work in a way that prioritises giving developers - or team members - this emotional pay-off, the chances are they would rarely get it.
Agile allows teams to assess their product at certain milestones, and adapt, rather than following a fixed plan and ignoring signs that change is needed. Sure, it would be easier to check tasks off as complete, but they’re likely of very limited value compared to what was expected when the plan was first hatched. So change is good, right?
The Benefits of "Not Done" for Developers
Adopting this mindset holds particular benefits for computer programmers and developers, many of whom are familiar with the notion of incomplete projects and iterations.
Enhanced Creativity and Innovation
Accepting that a project is never finished opens the door for ongoing creativity. Developers can continuously improve and ideate, leading to more innovative solutions. In this sense, creativity doesn’t stop when the plan is locked in.
Improved Problem-Solving
Recognising what remains "not done" helps developers focus on real issues rather than getting sidetracked by secondary concerns. This clarity leads to more effective problem-solving.
Holistic Growth
For many developers, it's not just about writing code but understanding the broader impact of their work. The "not done" mindset fosters a more comprehensive perspective, enhancing both technical and soft skills, meaning developers are less likely to be measured by the number of lines of code they wrote, or the tickets they checked off.
Increased Satisfaction
Seeing work as a continuous journey rather than a destination reduces the pressure for perfection. Developers often find greater satisfaction in the iterative process, celebrating small victories as they come.
Conclusion
For programmers and developers, embracing what is "not done" can be transformative, introducing new levels of flexibility, insight, and innovation into their work. This mindset not only complements agile development but also enriches the overall process, ultimately leading to products that better meet user needs.
To explore this philosophy further and see it in action, consider watching Vladimir Chernikov's intriguing talk, "The Importance of Not Done," where he dives into how not completing tasks might actually help you get promoted.
