Patterns of Agile success – Part 6 of 6
You’ll notice that it is only in our final mini-blog that we mention anything specifically to do with software development as opposed to any other area of the business. It’s a sign that the problems with IT are often more about the organization, culture, and methods of working than about the work itself. Yet we have noticed that one of the clearest patterns of successful Agile implementations is when code is treated as an asset.
This final part in our series on Patterns of Agile Success is taken from our session Adapting Agile, which forms part of our Agile Practitioner Pathway – find out more here.
Code is treated as an asset
Whether a business creating a software product or an organization that relies on software to carry out its operations, when IT is treated as an integral part of the business it becomes an asset. A rolling maintenance and upgrade program exists, which is planned and budgeted for in order to change or support legacy systems. New features are added, but changes are also regularly made to maintain existing code. Occasionally the decision is taken not to maintain a particular piece of software but rather to run it down, knowing that a planned replacement or upgrade is due to occur. This is done in exactly the same way that a vehicle operator might decide not to service an old truck, but wait until it breaks down and then replace it.
Risks of ignoring the pattern
Code that is not treated as an asset often turns out to be a liability. It should be completely obvious. If you spend $10 million acquiring a Picasso you will treat it as an important asset – you will guard it with an expensive alarm system, register it on international lists, insure it against fire, accidental damage and theft. Not doing so, risks losing your investment. Indeed, should you not pay for an alarm, your insurer will probably refuse to cover you – calling your behavior wilful negligence.
As businesses, we regularly spend more than $10 million on developing software, but instead of treating it as a valuable asset, we focus on short-term expediency. Sometimes we don’t even create a decent asset in the first place. Instead, we push out something that works without any thought to its complexity, ability for change or future use.
Now, it’s true that we should focus on delivering a working solution, however wobbly, as a way of testing the bones of an idea. But if this turns out to be the correct idea, then we should spend some time making it less wobbly, more permanent and stable, before we simply move on to the next thing.
Signs to watch out for:
What investment do you put into the way you build your code?
Is there a single standard of hardware for all employees, or can developers have a second monitor, a larger desk to permit pair programming? If a developer asks for a new tool can it be approved by the team or is it sent over to a central procurement purchasing hub?
Do you invest in new training or processes? Dojos? Coding Game wars? Tech talks? Or are these viewed as perks?
When hiring developers do you check how they code? If outsourcing development, do you look for practical demonstrations of the type of product, or do you select the lowest cost and add heavy penalties for non-delivery?
Companies that treat code as an asset appreciate that a low cost for the initial delivery of code may not outweigh the total lifetime cost of poor-quality code.
How do you treat code as it is being built?
Are you prepared to change your standards or languages depending on the need of the product? Do you refactor regularly? Do you have a suite of tests around the code that gives you confidence in making changes? How do you maintain code (if you do at all)? Is there time for clean-up, maintenance and improvement built into the team’s workload and productivity assessment, or does it need to be squeezed into slack times?
What confidence do you have in your code?
Do your developers understand the codebase? Are there whole areas of your code base that no one dares touch in case they break it? If you bring a new developer in can he or she read it and know what’s going on? If your code has declined beyond where anyone can understand it or only minor changes can be made to it, would you throw it away and start again (even if it’s still working)? Is there a plan for upgrading or changing the system? Is there a contingency in place for what happens if anything goes wrong?
These are crucial tests. Legacy systems filled with highly idiosyncratic code become dangerous because only a few people understand them. The risk to the company of these people leaving becomes increasingly severe – without their specialist knowledge, it’s impossible to do business. Asking yourself about what happens if code collapses is a way to help build support for necessary investment and to force others to take the issue seriously.
If you have never even considered such issues, then it is almost certain that your code is not being treated as an asset, but is well on its way to being a liability. It does not have to mean panic stations, however. In fact, if you’re really worried about a particular project or about your technical risk, then an audit can help you find firmer ground.
I hope you’ve enjoyed this series and found it helpful. Please post any comments on our blog here or contact us to discuss any ideas the blogs have sparked.
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
