I've undertaken a couple of project reviews recently where I've been asked to assess whether the code is "good enough". All software systems have a real-world context and the project has to balance scope, budget and schedule. With this mind, what is "good enough"? Kevin has touched upon this before and I've talked about having just enough quality, but what does having "good enough" code actually mean?
Here are some of the questions that I try to answer.
The last point raises some interesting questions. It's really easy to get carried away when doing code reviews and flag up a large number of points ranging from inconsistent code formatting and lack of comments through to using better APIs and the latest language features to solve problems. Given the real-world context in which the system exists, that piece of software needs to solve a business problem and points like these are fairly minor in nature1. However, an inconsistent codebase can highlight those instances where there is an overall lack of explicit technical leadership.
If you were to look at your own system, how would you decide whether the code was good enough?
1 Although it's arguable that points like these are minor in nature, I still think that it's important to ensure they are raised. Personally, I don't like to see things like this in the codebase for a system that I'm responsible for, but you need to present findings from activities like code reviews as appropriate. These minor points are important for the development team, but not so important if the key project stakeholder is asking you whether the code is good enough.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.