I have talked about this on the podcast but wanted to break out a list of potential items that cause tech debt and legacy into groups to be used as a reference.
Do you recognise any of these patterns and more importantly? What’s missing?
Breaking down the list
By tackling our list of reasons for having tech debt in the first place, we can approach a situation where we are minimising it every day while we code. To be aware of the limitations and constraints on our time and in our work is to be aware of where we place our systems in the future.
So let’s have a look at a list of factors and see if we can provide guardrails for those activities in order to make our code more future-proof.
These are factors that are entirely outside of our control:
|A deadline with lots of pressure on it (time pressure)||Statement: Quality Release or No Release. Prioritise quality and supportability.|
|Coding standards or house style (there’s only one way of doing things here)||Architecture Decision Records – ADRs. Do you have a defined house style? If not, define it and communicate it. Implement it in tools if possible. Make everyone aware and support it.|
|Costs – we are limited by resources – people, tools, capabilities||Investment in your people – your payroll is undoubtedly your biggest cost. Make sure you have the right team, the right people, the right tools.|
|Poor specifications||Don’t allow them to come through to development. Invest in your process.|
|Lack of support from management||Management should be aware that software making is not a sausage factory.|
|We don’t know any better (understanding or experience either as an individual, pair, mob or organisation)||If you are serious about serving your customers, you will invest in gaining that understanding so that you can serve them better in the future.|
Those factors limit us through technology choice, architectural choice or circumstances related to the way we can work with the code.
|The availability of specific language features||Investigate options and provide guidance on what should be used and when. If necessary write ADRs about the usage of language and features to help narrow your house style.|
|The tooling that we’re using, compilers or editors or test tools can only work in a certain way which limits our ability to express ourselves fully or as we would like||Invest in the right tools.|
|Lack of specific tooling (effective CI, tests, coverage tools, analysis tools)||Invest in the right tools.|
|Constraints in the specification. This could even extend to non-functional requirements that require us to structure the code in a certain way for efficiency.||Make sure that important decisions about tradeoffs between functionality and performance are fully understood at an architectural level. If a compromise is required then flag it as such and make a plan to improve the situation to a better architecture in the future. Compromises are fine as long as they are time-boxed and there is a commitment to revisit them in the future.|
|Unhelpful or unsuitable architecture||If you are continuously forced into making decisions which work against the architecture i.e making too many compromises – then perhaps it’s better to step back and revisit the entire architecture. At least think of some alternatives which can keep you working – short-term and long-term planning should come into play at this point. It is undoubtedly a company-level decision which may take several years to fully execute. Understand the implications and act accordingly. But act, and do so together.|
Those factors that cause tech debt and legacy due to the individual challenges.
|Inexperience (no idea what to do)||Get experienced. Mentor, train, upskill.|
|Wrong Experience (thinking that you know what to do)||Allow failures to happen but catch them with good CI, good tests, and good habits around releasing.|
|Lack of knowledge of technology (thinking you know what to do)||Invest in learning new technologies – reading, podcasts, videos and conferences.|
|Personal style and preference (you’re own personal way of doing things – coding standards)||Provide freedom for individual expression but agree and enforce code and testing standards. Automate as much as possible and regularly integrate (at least once a day)|
|Inability to understand the specification (seniority or inexperience)||Provide a safe environment to ask questions. Encourage stupid questions.|
|Inability to question the specification (seniority)||Provide a safe environment to ask questions. Encourage stupid questions.|
|Approach to coding (good enough for you or good for the rest)||What are the factors contributing to this approach? Lack of team focus? Mixed abilities? Frustration? Other?|
|Mentality (boy scout rule or just get it done rule)||What are the factors contributing to this approach? Lack of team focus? Mixed abilities? Frustration? Other?|
|XP or Agile or Personal Life – Way of Working is not working||What are the factors contributing to this approach? Lack of team focus? Mixed abilities? Frustration? Other?|
|Cry for help||Could be.|
|A place to be alone||Code is not an escape if there are other engineers and also customers relying upon it. Work is a place to put your organisation ahead of yourself in return for pay and benefits.|