Due to the amount of important things a software project may have, organisations tend not to pay to much attention to things that are considered less important, like the quality of the software being developed. It is believed that with a good management team, deep hierarchies, micro management, strict process and a large amount of good documentation, the project will succeed.
In a software project, the most important deliverable is the software itself. Anything else is secondary.
Many organisations see software development as a production line where the workers (developers) are viewed as less skilled than their high-qualified and much more well paid managers. Very rarely companies like that will be able to attract or retain good software developers, leaving their entire business on the hands of mediocre professionals.
Look after your garden
Rather than construction, programming is more like gardening. - The Pragmatic Programmer
Code is organic, not mechanical. Like a garden, code needs constant maintenance. For a garden to look nice all year round, you need to look after its soil, constantly remove weeds, regularly water it, remove some dead plants, replant new ones, trim or re-arrange existing ones so they can stay healthy and look nice as whole. With basic regular maintenance, the garden will always look great but if you neglect it, even if for a short period, the effort to make it nice again will be much bigger. The longer you neglect it, the harder it will be to make it look nice again and you may even loose some or all of your plants.
Code is no different. If code quality is not constantly looked after, the code starts to deteriorate. Bad design choices, lack of tests and poor use of languages and tools will make parts of the code to rot. Bit by bit other parts of the code will also be contaminated up to the point that the whole code base is so ill that it becomes extremely painful to change it or add new features to it.
The Invisible Threat
When starting a greenfield project, everything is great. With a non-existent code base, developers can quickly start creating new features without the fear of breaking or changing any existing code. Testers are happy because everything they need to test is new, meaning that they don't need to worry about regression tests. Managers can see a quickly progress in terms of new features added and delivered. What a fantastic first month the team is having.
However, this is not a team of craftsmen. This is a team of average developers structured and treated like unskilled production line workers.
As time goes by, things are getting messier, bugs start to appear (some with no apparent explanation) and features start taking longer and longer to be developed and tested. Very slowly, the time to deliver anything starts to stretch out. But this is a slow process. Slow enough that takes months, sometimes, over a year or two to be noticed by the management.
Some people say that they just don't have time to do it properly but, in general, a lot more time and money is spent later on on tests and bug fixing.
Hostage of your own software
When the code base gets into the situation where changes or additional features take too long to be implemented or worse, developers and managers are scared to touch existing code, an action must be taken immediately. This is a very dangerous situation to be since business progress is being impeded or delayed by the software instead of being helped by it.
To keep business progress, schedule and budget under control, high quality code needs to be maintained at all costs.
Organisations may need to cancel the implementation of some features or postpone changes just because of the amount of time and money that they may cost to be built. Having poor quality of code responsible for it is totally unacceptable.
The biggest problem here is that bad code is invisible to everyone besides developers. Other members of the team will just realise that something is wrong when it is too late. This means that it is the developers responsibility to look after the quality of the code. Some times, developers expose the problem to project managers but the request for having some time to "re-factor" the code is often ignored for various reasons, including a lack of understand of the impacts of bad code and the inability of developers to explain it. On the other hand, when developers come to a point where they need to ask for some formal time to do refactoring, this means that for one reason or another, they neglected the code at some point in the past.
Hire craftsmen not average developers
With the amount of literature, tools, technologies, methodologies and the infinite source of information available on the web, it is just unacceptable to have a team of developers that let the code to rot.
Craftsmen are gardeners and are constantly looking after the code base, quickly refactoring it without fear since they are strongly backed by a good battery of tests that can test the entire application in just a few minutes. Time constraints or change in requirements will never be used as excuses for bad code or lack of tests due to the good design principles and techniques constantly used throughout the application.
Having an empowered team of craftsmen can be the difference between success and failure of any software project.
Quality of code may not guarantee the success of a project but it can definitely be the main invisible cause of its failure.
2 comments:
I love the gardening analogy - very apt. I think it'd be interesting to explain how something that doesn't change (code) can still rot / get out of control in the same way that an organic garden does. It *does*, I struggle to explain *how* - if nothing's changed, how come a year later its a steaming pile?
I keep hearing the phrase "software factory" here - as though our job is to churn out as much code as possible. "Measuring software productivity by lines of code is like measuring aircraft design by weight"
Requesting time to refactor is surely an organisational anti-pattern. The business people here tell me they assume that its just something we do - they assume that we keep the code as clean as it needs to be. I think we should stop surfacing these implementation details. Would we ask for explicit time to write unit tests any more?
Finally, to contradict all of that: clean code can be a business decision. If there is a commercial need to be out fast, whatever the cost, then that is a valid decision. The danger is when companies / projects allow the code to get out of control without really considering the impact it has.
I think this comes back to my first point - it is very difficult, I find, to explain the long term cost code cleanliness has. I have a gut instinct for it, but surfacing that decision to the business always leads to choosing speed over clean code.
Great article.
I think you've hit some crucial points there.
Also, there's a small typo in the text - loose should be lose.
Post a Comment