At the beginning of my career, a colleague of mine stated an insightful phrase: “There are two main ways to learn from every work related experience: the best approach of how and what to do any practice, and the exact opposite! You can always learn what NOT to do”. Characterisation of these circumstances are known as anti-design patterns.
An anti-design pattern is distinguished by at least two factors, which may originate from a bad habit, practice or idea. Apart from its origins, this pattern or structure will initially appear as an effective solution to a problem, yet, will also result in a more negative result rather than a good one.
Considering that the digital line of work is highly competitive, one of the most common anti-design patterns is known as gold plating – “We just need to add one more thing...”
This counterproductive behaviour sneaks its way into various stages of the development life cycle and with good intentions to improve products’ look and feel. It could even result in better version of the initial version required at the onset. Primarily, adding more features to a solution, which were not requested to begin with, can lead to a better impression and reputation.
The issue lies in the prioritisation and identification of features that were not requested to begin with. Focusing on these features, which may have little or no use, might cause one to ignore more important ones, or to overlook bugs that could potentially lead to a delay in the deployment requirements in an already stipulated deadline, or worse.
Without early identification of this problem, an anti-design pattern might lead to another, the big ball of mud. Generally speaking, this occurs when a system or software does not provide a structure. From an end user’s perspective, having a system without a noticeable architecture might also result in a lack of trust in the business the software it is representing, apart from the risk of it becoming a disorienting experience.
What can be done to mitigate patterns
The first solution that comes to mind is prevention, which is also a key part of the development life cycle used in Agile methodology.
Agile development, particularly SCRUM, adopts the practice of sprints. These include sequential micro tasks that need to be completed at short intervals. Through this, the whole team can have a top level view of the work being done at the end of sprints, test it and run it by stakeholders for feedback and confirmation.
Although room for extra features might still be available, distinguishing tasks by their importance and planning the time required will mitigate against gold plating, as it will provide a very clear image of what needs to be prioritised.
Having multiple stakeholders involved might also be a risk since requirements could be subject to change according to which stakeholder is involved. This can be mitigated by involving all stakeholders in every meeting to ensure requirements are aligned and subject to less changes during the course of development. Additionally, internal meetings are also important to refresh and reconfirm priorities throughout the team, to enable on track progress. Communication remains key to ensure that all stakeholders are adequately informed of all developments in a timely manner.
Design follows a development cycle and at Deloitte Digital we strive to continuously evolve our capabilities, whilst maintaining a best practice approach to our projects. For example, when it comes to additional features that carry their share of value, it is advisable to always have team leads and stakeholders endorse and encourage with good measure. Acknowledgement to jobs well done help the creativity and creation cycle. Finally, and this cannot be reiterated enough, communication is a crucial element in the design process – clear guidance to clients and qualitative involvement, enables better decisions.
