Software Architecture

Summary: Occamality and Software Architecture

This is a summary of my posts on the single most important principle of software: Occamality (non-redundancy). This principle applies to everything from the simple concept of what makes a piece of software "good" to developing and evolving software quickly, efficiently and with high quality. It drives good software architecture and all other aspects of development, from requirements through QA. 

This summary also includes my posts on software architecture, mostly explaining why widely accepted architectures like microservices are terrible.

 

To start, it's worth pointing out that software people don't know what makes a piece of software "good."

https://www.blackliszt.com/2023/09/how-do-you-know-if-a-given-piece-of-software-is-good.html

Software people often have strong thoughts about software languages and architecture. However, it is extremely rare for those opinions to be grounded in or related to the goals of software architecture. What are the goals? Here’s my proposal.

https://www.blackliszt.com/2022/05/the-goals-of-software-architecture.html

Here are the key specific things you do to accomplish the goals.

https://www.blackliszt.com/2020/02/how-to-build-applications-that-can-be-changed-quickly.html

Here is a layman's, common-sense explanation of the same idea:

https://www.blackliszt.com/2022/10/how-to-improve-software-productivity-and-quality-common-sense-approach.html

Here is a specific explanation explaining why Occamal programs are better than non-Occamal ones and why you should care.

https://www.blackliszt.com/2023/09/why-should-you-build-occamal-programs.html

How do you apply Occamality in practice? Here is a short, simple list of the practical things you do.

https://www.blackliszt.com/2023/09/understanding-occam-optimality-practically.html

Occamality isn't another entrant in the myriad of design principles competing for attention in the chaotic world of software -- it's an overriding principle, one that stands above and ranks all the contenders.

https://www.blackliszt.com/2023/09/occamality-and-other-design-principles.html

Occamality isn't confined to writing software. It applies to all stages of the development lifecycle, from requirements through QA and support.

https://www.blackliszt.com/2023/09/occam-optimality-applies-to-all-stages-of-the-software-life-cycle.html

The value of reducing redundancy isn't confined to software; it's a general principle.

https://www.blackliszt.com/2020/05/lessons-for-better-software-from-washing-machine-design.html

Saying that you should reduce redundancy in a program sounds simple, but once you get past trivial examples, it's not. Here's an analysis of the increasingly sophisticated kinds of redundancy in programs that should be addressed.

https://www.blackliszt.com/2023/10/moving-towards-occamal-software.html

Reducing redundancy is accomplished by taking a declarative approach to programming instead of a purely imperative one. There are many examples of this.

https://www.blackliszt.com/2021/07/software-programming-languages-the-declarative-core-of-functional-languages.html

Databases are an excellent, proven example of applying the principle of Occamality.

https://www.blackliszt.com/2023/09/occamality-in-databases.html

It's not just databases -- Occamality is a thread that weaves through much of the history of software.

https://www.blackliszt.com/2023/09/occamality-in-software-history.html

You might think that reducing redundancy is an obviously valuable thing to do. The trouble is, modern software orthodoxy endorses the notion of collections of code that are separated by high walls (components, services, layers, objects, etc.), which typically leads to huge amounts of redundancy.

https://www.blackliszt.com/2023/09/occamality-the-problem-with-layers-components-and-objects.html

There is a simple idea that shows the basic approach to eliminating redundancy in programs: instead of stating how a thing should be accomplished, you concentrate on defining what is to be accomplished.

https://www.blackliszt.com/2023/09/achieving-occamality-what-not-how.html

The optimal way to reduce redundancy includes recognizing that in addition to instructions and data, programs include varying amounts of metadata. Metadata is an easy concept for those who use it, but many programmers don't get past the idea of parameters. Here's a way to understand metadata:

https://www.blackliszt.com/2023/09/achieving-occamality-through-definitions.html

In broader context, here's how metadata fits into a whole program, as the third dimension of software architecture.

https://www.blackliszt.com/2020/02/the-three-dimensions-of-software-architecture-goodness.html

For all dimensions, lack of redundancy is the main virtue. As a group, the more functionality is expressed in metadata and the less in code, the better.

A focus on metadata is similar to having a generic direction-generating program that refers to an easily-changed map.

https://www.blackliszt.com/2020/06/the-map-for-building-optimal-software.html

Here’s more theoretical depth on the role of metadata in a software system, with a comparison to theories of the solar system.

https://www.blackliszt.com/2022/10/how-to-improve-software-productivity-and-quality-code-and-metadata.html

Why put as much application knowledge into metadata as possible? It's the easiest thing to change, and above all, it's the best place to eliminate redundancy, which is the enemy of fast, error-free change.

https://www.blackliszt.com/2020/03/william-occam-inventor-method-for-building-optimal-software.html

Here is a more extensive explanation of the history and context of Occam's Razor and its relevance to software.

https://www.blackliszt.com/2023/09/occams-razor-the-key-to-optimal-software-development.html

How do you achieve this ideal architecture for a body of code? Not all at once! You avoid the usual nightmare of useless, ever-changing requirements and do something that makes a customer happier than they were. Then fix it. Here’s the process, to which I’ve given a fancy name.

https://www.blackliszt.com/2022/09/better-software-and-happier-customers-with-post-hoc-design.html

Here’s another statement of the basic idea:

https://www.blackliszt.com/2011/06/software-how-to-move-quickly-while-not-breaking-anything.html

https://www.blackliszt.com/2020/03/how-to-pay-down-technical-debt.html

Here is more detail and explanation of how to use increasing amounts of metadata to help build applications quickly, which of course should be a major goal of software architecture.

https://www.blackliszt.com/2022/05/how-to-improve-software-productivity-and-quality-schema-enhancements.html

Here's a short case study from early in my career that demonstrated to me the incredible value of taking an Occamal approach to building an end-user business application.

https://www.blackliszt.com/2023/09/achieving-occamality-through-definitions-case-study.html

Here is a more recent case study of a system based on extensive use of metadata and what happened when technology-fashion-driven executives took over the company.

https://www.blackliszt.com/2023/09/case-study-replacing-metadata-with-fashionable-software.html

One of the most basic aspects of software architecture is the data and where it is stored. The default choice for most architecture is to use a standard DBMS. Given the steady advance of Moore's Law, this is often no longer the best choice.

https://www.blackliszt.com/2010/09/databases-and-applications.html

 

Bad Software Architectures

Software is infected with architectural religions, none of them with a sound basis in logic or real-world experience. It’s not that you can’t build software that sort of eventually kinda works with them – but it’s like building a car with a steam engine.

Sadly, some programming languages and programming concepts encourage redundancy.

https://www.blackliszt.com/2014/03/how-to-evaluate-programming-languages.html

Starting a couple decades ago the idea of “distributed computing” as an architecture become the thing all the cool kids gravitated to.

https://www.blackliszt.com/2015/04/the-distributed-computing-zombie-bubble.html

A modern incarnation (with a new name and rhetoric of course) is micro-services, which is supposed to boost programmer productivity.

https://www.blackliszt.com/2021/03/how-micro-services-boost-programmer-productivity.html

Not only does micro-services boost programmer productivity, it supposedly is a “scalable” architecture – in sharp contrast to the evil “monolithic” architecture … a word which is usually pronounced with a sneer.

https://www.blackliszt.com/2020/06/why-is-a-monolithic-software-architecture-evil.html

The trouble is, microservices make about as much sense as blood-letting did in medicine. It's widely accepted as useful, but entirely without evidence.

https://www.blackliszt.com/2019/02/what-software-experts-think-about-blood-letting.html

Programmers seem to like to layer their software, often without thinking about it.

https://www.blackliszt.com/2012/06/layers-in-software-fuss-and-trouble-without-benefit.html

Similarly when they link together pieces, a key decision is whether the coupling is loose or tight.

https://www.blackliszt.com/2012/08/coupling-in-software-loose-or-tight.html

Components and layers have been promoted for a long time.

https://www.blackliszt.com/2021/03/micro-services-the-forgotten-history-of-failures.html

https://www.blackliszt.com/2021/09/software-components-and-layers-problems-with-data.html

https://www.blackliszt.com/2021/08/the-dangerous-drive-towards-the-goal-of-software-components.html

For the best results, it’s good to focus on the goals of software architecture described above, and assure that everything that you do contributes to those goals. Part of how you do this is to avoid the always-present temptation of following software fashions.

https://www.blackliszt.com/2023/07/summary-software-fashions.html

 


Categories