Applying software engineering principles to our laws

  • Separation of concern: The code should be divided in well-designed modules that have only one purpose. Each module has publicly visible interfaces that can be used by other modules, describing its features/functionalities, and thus, a contract that they agree to fulfil towards these modules.
  • Modularity; each file defines a module that relies on other modules. Each module can be implemented in various ways, as long as it respects it’s interfaces with other modules.
  • Versionning: If an interface is to be changed, the codebase’s version increases. It should be easy to visualize differences between two versions, and to revert back to a previous version, if a later version does not work as expected.
  • Readability: each file should be less than 200 lines of code. Otherwise, you can probably refactor/redesign your code.
  • Complexity: The more complex the code, the less people will be able to use / exploit it, and the less people will accept to maintain it. And thus, the more bugs will occur from this code.
  • Bug: unexpected behavior of a code base in a specific context/situation. Happens when rules to be implemented were not clear enough, of if the code incorrectly implement these rules.
  • Technical debt: when too many shortcuts and workarounds (a,k,a quick hacks) were made in the source code, the complexity of the code increases, thus its maintainability decreases very quickly. Some time must be planned ahead for regular refactoring, in order to clean and simplify the code.
  • Automated testing consists of a list of scenarios with an expected outcome (or behavior) that can be used to check that the source code behaves as expected, even after changes. If expected outcomes change, it means that rules have changed.
  • Test-driven development consists of writing tests (rules) first, and then writing the code that complies to these tests. It ensures that rules prevail, and that implementation can change safely over time.
  • Legacy code: code on which expected behaviors (i.e. rules) can not be tested automatically, and thus, has become too complex to understand and maintain. At some point, even refactoring can not be applied without the risk of breaking expected behaviors of the new implementation, because these expected behaviors (rules) were not defined in the first place.
  • Open-source collaboration: consists of sharing the source code freely with the world, so that anyone can read, copy, and propose contributions by creating an alternative version out of the original source code: a “fork”.
  • Pull request: If the changes proposed by a contributor in their alternative version (the “fork”) benefit to the users of the original source code, they can request to integrate them back into the original source code. So-called “Pull requests” can be refused or approved by the trusted maintainers of the original source code, after they typically check that this contribution complies to expected behaviors (rules, or “automated tests”).




Web software development × personal development. 🚀

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adrien Joly

Adrien Joly

Web software development × personal development. 🚀

More from Medium

Relentless Solution Focus — or, How To Make Your Team (and boss) Love You

What it means to me, being a developer at Street Group

The writer of the blog, Steven Weir, stands holding the horn of a large, bronze sculpture of a charging bull near Wall Street, New York City.

The Bleak Tech Market’s Silver Lining

Miro Vs. Dojoit — Which is Best Online Whiteboard?