When Coding, Think Like a Lawyer

Why is so important for a software engineer (and even more for an architect) to have more than just a good grasp of the business domain? More, not having that would ultimately make it a “bad” engineer?

Well, yes.

Software Like Engineering

Since the early days software is often assimilated to engineering because it shares several key characteristics and principles with traditional engineering disciplines.

• Systematic approach
• Design and planning
• Prototyping and testing
• Problem solving
• Documentation and quality assurance

While software development shares several similarities with traditional engineering disciplines, it also has unique characteristics, such as rapid changes, flexibility, and a focus on digital solutions. In particular, the point that over the decades set a relevant difference–the terms software engineering appears in the papers around the late 1960s–is design and planning.

In engineering, nothing is built if not strictly descending from a closed and approved project. In software this translates to Big Upfront Design, which is now largely considered an anti-pattern.

Big Upfront Design (BUD) is a software development approach where the majority of a project’s design work is completed before coding begins. It involves creating comprehensive design documents, architectural plans, and detailed specifications upfront, aiming to minimize changes during development. BUD is associated with a waterfall methodology and is often criticized for its inflexibility in accommodating changing requirements. More modern software development practices, such as Agile, favor instead iterative and incremental design for greater flexibility and responsiveness to evolving project needs.

The application of the terms engineer and architect in software is also influenced by the analogy between software and traditional engineering. Software architects focus on the high-level design of the system and create the architectural blueprints that guide the development process. They make critical decisions about the system’s structure, components, and how they interact. Architects also provide technical leadership and set the design principles, patterns, and best practices that the software engineering team should follow. Risk mitigation is also on architects and it is in their responsibilities to identify potential risks and challenges in the project.

On the other hand, software engineers write code and work on the technical aspects of the project. They are involved in the detailed design and development phases, translating the architectural blueprints into executable code. Software engineers are problem solvers who tackle technical challenges, optimize code for performance, and ensure that software functions correctly.

Is software-to-engineering the ideal analogy?

Software Like Law

In this context, the term law describes the field of work and practice for lawyers, just as engineering describes the field of work and practice for engineers. I do believe that a software engineer should reason more like a lawyer than an engineer. 

Similar to lawyers, software engineers encounter various domains in their careers, and just as you wouldn’t want to be represented by a lawyer who lacks a complete understanding of the case’s context, you wouldn’t want to be the inept engineer in your project who lacks knowledge of the domain. Nothing is sadder than being a developer that every morning picks up an item from the backlog, tries to make sense of it and blindly codes its way out without having the faintest idea of why the item is there and what’s the broader context of it.

Lawyers are not omniscient and resort to experts when they need to delve deep in the intricacies of a case. (BTW, I have been one of those experts involved by lawyers in legal cases). However, good lawyers know which specific, binary questions to ask and do not accept obscure, superficial and aggressive answers.

When coding, thinking like a lawyer more than like an engineer helps.