Measuring code quality, productivity, technical debt is difficult.
Measuring number of lines of code; speed of delivering code; completed stories, features, epics is easy.
Do not trade quality away for comfort.
Categories
Technical debt sneaks up on organisations and their systems. It is inevitable.
The ability of dealing with, managing, remediating it differentiates successful businesses from the rest.
Technical debt builds up over time. It could take years for it to amount to significance. If unattended, it reaches a time when the fixing costs are higher than the return from it.
The system still produces value at this point, it has not gone bankrupt. There are even workarounds to some of the issues.
However, innovation, new feature and product introduction is not sustainable anymore – nobody wants to touch a house of cards system, or pay the premium for the overhead of dealing with the mess.
The system enters the zone of – kicking the can down the road.
Occasionally, a large(ish) investment into the existing system might be justified if it generates enough value – as opposed to replacing it entirely, which would be too expensive.
In most cases, just enough fixes are applied to keep the lights on and to keep sweating the asset for the rest of its operational life.
Minimise the effect of bad debt and extend the productive lifespan of a system by
- Looking out for the technical debt indicators
- Putting strategies in place for managing technical debt
Categories
Is it Serious?
Transpiling a good doctor-patient joke to techie-CEO:
- CEO says to one of his techie “Is it serious? How long do we have until we go offline?”
- Techie says “5”
- CEO says “5 what? 5 days? 5 weeks? 5 months?”
- Techie says “4…”
You do not get to call your product a Software as a Service (SaaS) if it does not support webhooks or REST hooks in addition to a decent collection of APIs.
Your product is just web application.
So much focus is lost on asking – What are the blockers? – that the organisation forgets to enable its people to do the work.
Failing to enable those that do the work is the biggest blocker in an organisation.
Categories
4 Signs Your Business Needs a CTO
If your business involves technology and you find yourself thinking along any of the following…
- Let’s get a developer to do “the tech”
- Let’s outsource “the tech”
- Let’s get some software off the shelf for “the tech”
- Let’s get started and sort out “the tech” once we start growing
…then it is a sign that you should think about having a your business might need a CTO.
Whatever can go wrong, will go wrong
Murphy
Let’s see what can go wrong with each of the four points.
The Technical Talent
Good technical people in your network that you can rely on is the best thing to have for your business. Otherwise, finding technical talent can be exciting if “looking for co-founder speed-dating” is your thing.
Your next best option is to get guidance from a technical lead who has been there, done that; and will
- help making early technology decisions that fits your bill;
- align product features or project scope with schedule and budget.
The Outsourcing Shop
Getting somebody external to build your tech – outsourcing – is a frequently favoured approach. It promises to deliver a bespoke solution, tailored to your needs, often advertised at a low cost. If you have not worked with outsourcing companies before, or if you have not managed product development with a partner before, this could be a bumpy and costly ride.
Delivering a successful project with external partners requires a great deal of preparation and dedication during the execution from your side, including
- interview, evaluate and select partners, suppliers;
- oversee delivery from start to finish.
The Off-the-shelf Product
Finding a suitable and affordable off the shelf product, commercial or free open source, is a great way to get started. If you have the luxury of choice, then a thorough, objective analysis of options should reveal the most fitting one.
A single package rarely meets all needs. A new set of challenges will rise from customising it, or from integrating it with additional solutions.
Circumstances could lead to considering building your own tech. It is a decision not to be taken lightly.
Mitigate the risks by getting help for
- vendor and product selection;
- buy versus build analysis.
The Postponed Tech
Kicking the tech decision tin can down the proverbial road tends to build up technology debt. It risks future development, innovation and growth by increasing cost, timeline and limiting scope.
Think about tech strategically, make it part of your roadmap to address technology debt.
Addressing tech at the growth stage will throw up more of the same issues described earlier with the added twist of dealing with legacy.
Avoid being limited by tech at this stage by
- devising strategy and roadmapping early;
- performing regular technology audits.
Making technology work to create value for your business is often not a trivial task. The runaway costs, scope creeps, schedule overruns together with unnecessary complications and complexity can be overwhelming.
If still not convinced, or cannot commit to getting a CTO on board, perhaps consider working with an interim or part-time CTO.
Early stage technology decisions will have a profound impact on your business for a long time.
The common metaphor for multi-tenant systems is the block of flats where tenants share the building and its services (water, gar, electricity, security, etc) but each tenant may organise and furnish their flat differently.
The part – that is often left out – is where the landlord limits each tenant how much change they can make to the flats, how many guests they can invite, how much of the services they can use. These limits what make multi-tenant buildings viable by protecting the infrastructure for everyone’s benefit.
SaaS and PaaS and IaaS are good examples of shared environments where the multi-tenancy metaphor works well.
The service providers – landlords – manage these environments closely, and enforce the limits strongly. This way everybody benefits the same way and providers can maintain their service levels (SLAs).
This metaphor struggles when transitioning to the next level of abstraction – sharing resources within one tenancy.
Multiple projects, new features, updates, fixes from multiple sources draining resources within the same tenancy.
The river metaphor for a shared environment is more suitable1
Each project and feature is an industrial installation – a factory plant, a power station, or any other build directly connected to the water ways.
Well behaving projects will keep the environment clean and liveable for everybody.
Projects with weak or no governance will pollute the waterways and ruin it for themselves and everybody else. Those downstream will have to work extra hard to clean up and maintain it for the rest.
Why does the river metaphor work better?
Because the societal and policy issues better resonate with the equivalent governance issues. It emphasises the negative effects of badly managed changes as opposed to showcasing the positive effects of a well managed environment.
It highlights the need for better and stronger governance in the absence of hard limits.
1Inspired by Seth Godin’s podcast episode: The river of time