Keep your code clean and success will take care of its self
“So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Software development is hard. There are so many competing challenges – the phrase burning the candle at both ends is very applicable in business critical software projects. On the one end of the candle you have management wanting features out yesterday and on the other the developers pushing out these features as fast as possible with hardly any testing, adopting an unwittingly just in time – just about works philosophy. Code is often duplicated, controllers are fat and bloated with no clear indication of what is redundant code and what is live. We’ve all been there – we’ve all done it – but STOP – it doesn’t have to be like this!
But – hey, it works!(?)
“…developers spend about 50 percent of development costs on identifying and correcting defects.”
Source: Seapine Software, Identifying the Cost of Poor Quality white paper, date accessed 03 September 2017.
Cited in a recent white paper by Seapine Software Identifying the Cost of Poor Quality, the paper states according to the National Institute of Standards and Technology (NIST), developers spend about 50 percent of development costs on identifying and correcting defects. The white paper continues stating, NIST also found that over 80 percent of errors are introduced during coding, but well over half of these errors are not found until later in the development process.
Pushing code out that works is one thing but maintaining it is quite another. Once you get in the habit of not cleaning up properly mistakes and bugs start to creep in. The bugs become harder to solve because you don’t know what code is responsible for which chunk of data. This slows development down, creates more bugs and adds cost to the project. Deadlines are shot through and eventually never met. Customers lose confidence in your product, the management says what you need is more developers. You hire more developers but they don’t know your framework or just how big the mess is – soon they end up picking up the same bad habits your existing team adopted because they don’t know or have time to fix the mess. Result – product dies and may be the business – time to dust off your CV.
How do you stop the rot?
Use Agile methodologies where ever possible.
- There has to be a meeting of minds between management and the developers- identify a set of principles that you can all share and agree on.
- Set realistic goals, easily achievable to begin with and factor into every sprint at least a third of development time to testing.
- Adopt a coding practice that all of the development team sign up to without fail.
- For every sprint ensure that all classes have a corresponding unit test
- Implement Behavioral Driven Development (BDD) at the beginning of your sprints
- Use Test Driven Development (TDD) during development
- Run automated tests on a staging environment before pushing to production and final release
The list above is not an exhaustive one and neither is it a silver bullet. Each item takes skill and time to master. Study each item to its nth degree. If you are working on an existing project produce a plan to refactor your code base over a period of time that allows you to realistically continue to push out new features. In so doing you gradually regain control of your product, the trust of your customers and a sympathetic, happy management structure.