| « The myth of the untestable controller | If PHP ends up dead, it will be us who killed it » |
Bad code. Most of us have seen it before. And most of us are aware of concepts like “technical debt” as it relates to software development practices. But what most of us never actually think about are the specific business challenges posed by code that is loaded with technical debt and difficult to maintain.
Refactoring code is often at the bottom of a business’ to-do list. Features, deadlines, goals and moving the project forward are crucial things that businesses are focused on. There’s a good reason for that: customers don’t buy software because it’s easy to maintain, they buy software because it solves their problem. And thus, refactoring doesn’t seem to have inherent business value.
In truth, refactoring and creating good code do have business value, but a value that’s harder to see than new features and faster processing time.
Imagine that you have a team of eight developers. Each developer is working on new features and bug fixes in a huge legacy code base that has over 1 million lines of code. A code base that large is sure to have bugs in many different places, and it’s unlikely that each developer has the capacity to fully know and recall the intricacies of the code. Thus, each developer must spend time remembering how the code works each and every time they work on it.
In a well-written but large code base, developers can focus on small sections to solve their problems. But in a monolithic, poorly written code base (see WordPress), developers have to spend time remembering how the code works, tracing code paths through various aspects of the application, and generally learning the code over and over again.
If each developer on the team spends an hour each day doing this, then your team of eight developers is spending 40 hours a week just remembering how the code works.
In other words, your development team of eight is really a development team of seven in terms of productivity.
Now, it’s true that having a well-written code base will never completely eliminate debugging time. Of course, it can help dramatically reduce it (if you can reduce debugging time by 50% then you’ve increased productivity by one half of an engineer in this example). In other words, well-written code that takes less time to debug saves your company money in the long run by increasing engineer output and decreasing the cost of fixing bugs in the code (and probably decreases bugs themselves!).
Additionally, well-written code has other advantages like being testable. If you have a monolithic code base with no real tests, then developers have to either manually test all paths through the system or you run the risk of putting out something that has new bugs in it (or you can be like one company I worked for and hire six people to manually test the code for each release). This takes additional time and costs additional productivity.
Automated test suites won’t catch everything; the things that they catch, though, can be instructive to your developers about problems they may have introduced. But only well-written code can be properly tested. At Mozilla, the Socorro project has one QA person, and plenty of automated tests. We use these two things together to increase productivity and decrease the liklihood that we’ll ship a release with horribly broken features. This is only possible because we work hard at writing really good code.
One of the benefits of truly object oriented code is the fact that repeating yourself is strongly frowned upon. Well-written code, especially well-written object oriented code will reduce or eliminate duplication, reducing the overall cost of maintaining features. Having to change the same thing in several places when making a small feature change? This costs time, effort, energy, quality assurance resources, testing resources and developer productivity.
Writing quality code, and refactoring bad code into good code, is about more than style. The substance, cost savings, improvement in productivity, reduction in quality assurance costs and gains in customer happiness (at the lower number of bugs they find) are all valuable. Developers should be permitted, nay encouraged to refactor code when necessary and spend time making those performance and productivity gains for the good of the company. It’s well worth it in the end.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 9/17/2013 at 9:00 am
There are currently no comments.
| « The myth of the untestable controller | If PHP ends up dead, it will be us who killed it » |