The Original Diagnosis: Software as Art
Two and a half years ago, an article titled "Less Art, More Engineering" argued that software development, despite calling itself engineering, largely operates on subjective criteria. It lacked verifiable definitions for concepts like readability, contradictory best practices, and design methods that offered no way to confirm correctness. The author promised a follow-up: converting this understanding into a set of clearly defined, well-grounded rules and criteria, ideally measurable but at least easily verifiable.
The author now reports back, acknowledging the initial diagnosis was correct, but the proposed cure was flawed. The original goal was modest: to organize code so its structure would be recognizable. This initial thought process, however, led to a deeper realization about the nature of software quality and how it can be objectively assessed.
The core issue, as identified in the original piece and reiterated here, is the reliance on subjective judgments. Terms like "readable code" or "good design" are often used without a concrete, universally agreed-upon definition. This subjectivity makes it difficult to objectively evaluate code quality, leading to inconsistent development practices and a lack of true engineering rigor. This is akin to a sculptor claiming their work is "good" based on personal aesthetic preference, rather than adhering to principles of form, balance, and material integrity that can be objectively analyzed.
The Flawed Cure: Measurement as the Solution
The initial approach to rectifying this subjectivity was to seek measurable metrics. The idea was that if we could quantify aspects of code, such as lines of code, cyclomatic complexity, or function length, we could move closer to objective evaluation. However, this proved to be an incomplete solution. While metrics can provide some insights, they often fail to capture the nuances of code quality. For instance, code with low complexity might still be poorly structured or difficult to understand due to a lack of clear intent or naming conventions. Conversely, code that is slightly more complex might be exceptionally well-designed and maintainable because its structure clearly reflects the problem it solves.
The author discovered that simply applying numerical metrics was insufficient. These metrics, while objective in their calculation, did not necessarily correlate with what makes code truly "good" from an engineering perspective. They could be gamed, or they could point to issues that were not the root cause of poor software quality. The pursuit of purely quantitative measures missed the qualitative aspects that truly define effective software development.
This realization is critical. It highlights a common pitfall in attempting to bring scientific rigor to inherently complex domains: mistaking easily quantifiable proxies for the actual underlying quality. It's like trying to measure the success of a novel solely by word count or sentence length, ignoring plot, character development, and thematic depth. The early attempts to fix the "art" problem with a simple "measurement" tool were akin to trying to measure the beauty of a painting with a ruler.
The Revised Approach: Verifiable Rules and Criteria
The pivot in thinking has led to a new, more promising direction: focusing on verifiable rules and criteria, rather than solely on measurement. The key insight is that while perfect measurement might be elusive, verifiability is achievable. This means establishing rules that developers can check and agree upon, even if those rules aren't expressed as simple numbers.
Consider the difference between saying "this code has a cyclomatic complexity of 7" (a measurement) and saying "this function performs a single, well-defined task, and its name accurately describes that task, and all variables within it are clearly scoped and named" (verifiable criteria). The latter, while not a single number, provides a much clearer path to assessing code quality. It requires human judgment, yes, but it's a judgment guided by explicit, checkable conditions.
This shift moves the focus from abstract, potentially misleading metrics to concrete, actionable principles. It’s about defining what good looks like in practice, in a way that can be audited. This could involve rules around naming conventions, function signatures, module cohesion, and dependency management. The goal is to create a shared understanding and a common language for evaluating software design and structure.
The author suggests that this approach is more robust because it acknowledges the inherent complexity of software. Instead of trying to reduce everything to numbers, it builds a framework of verifiable assertions. This is less about finding a single "score" for code quality and more about building a system where the quality can be confidently assessed through a series of checks. This approach doesn't discard metrics entirely but places them in context, as one tool among many for verification.
The Path Forward: From Subjectivity to Objective Assessment
The journey from the initial "Less Art, More Engineering" article to the current understanding has been one of refinement. The initial diagnosis of subjectivity remains valid. The initial proposed cure of pure measurement, however, was found wanting. The refined approach, centered on verifiable rules and criteria, offers a more practical and effective way to introduce engineering rigor into software development.
This evolution is significant. It means that the path to more professionalized software development isn't necessarily paved with more complex algorithms for code analysis, but with clearer, more explicit standards that teams can adopt and verify. It’s about creating a common ground where subjective opinions are replaced by objective checks, leading to more predictable, maintainable, and robust software.
The challenge now is to translate these verifiable criteria into practical tools and methodologies that development teams can readily adopt. This might involve new linters, static analysis tools that go beyond simple metrics, or even new approaches to code reviews that focus on these verifiable principles. The ultimate aim is to make software development a discipline where quality is not a matter of opinion or art, but a demonstrable outcome of sound engineering practice.