simplesystems/website
simplesystems/website
1
0
Fork 0
Code Issues 18 Pull Requests Actions Wiki Activity

Clean up Complexity blog post.

Browse Source
This commit is contained in:
jeff 2021-10-05 10:52:24 -07:00
parent 9cc715bd92
commit e41b80cc6a
1 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
content/blog/complexity.md
View File

@ -8,7 +8,7 @@ desc: What is complexity as it relates to software?
The most [relevant definition of complexity](https://www.lexico.com/en/definition/complex) for this blog post is: (adj) "Not easy to analyze or understand; complicated or intricate." Intuition of complexity is important if you are designing, writing, or reading software. If you are purchasing software, it is important to prioritize simpler options; it will be cheaper in the long run. In this blog post, I will discuss identifying complexity, why it's bad, why simple is good, and how software engineers manage complexity. The most [relevant definition of complexity](https://www.lexico.com/en/definition/complex) for this blog post is: (adj) "Not easy to analyze or understand; complicated or intricate." Intuition of complexity is important if you are designing, writing, or reading software. If you are purchasing software, it is important to prioritize simpler options; it will be cheaper in the long run. In this blog post, I will discuss identifying complexity, why it's bad, why simple is good, and how software engineers manage complexity.
## Identifying Complexity ## Identifying Complexity
Before being able to manage complexity, it must be identified. In addition to the definition, it is helpful to know indicators and examples. Seasoned engineers sometimes call these smells; complexity is not black and white, but more of an intuition. Things that appear simple now may become complex in the future. Before being able to manage complexity, it must be identified. Along with the definition, it is helpful to know indicators and examples. Seasoned engineers sometimes call these smells; complexity is not black and white, but more of an intuition. Things that currently appear simple may become complex in the future.
#### Indicators #### Indicators
@ -27,22 +27,24 @@ Before being able to manage complexity, it must be identified. In addition to t
* Humans: No two are the same. DNA on its own is complex; factoring in the expression of that DNA is beyond the understanding of any single person. * Humans: No two are the same. DNA on its own is complex; factoring in the expression of that DNA is beyond the understanding of any single person.
## Complex Software is Undesirable ## Complex Software is Undesirable
All software is complex; it is one of the most complex man-made things. Physical creations such as space ships, submarines, and skyscrapers may be complex, but they are limited by the laws of physics. Software has no such limit. For example, [FreeBSD](https://www.freebsd.org/) is an operating system that powers parts of [Netflix](https://www.phoronix.com/scan.php?page=news_item&px=Netflix-NUMA-FreeBSD-Optimized), [WhatsApp](https://www.quora.com/Why-did-WhatsApp-choose-FreeBSD-over-Linux), and [PlayStation 4](https://en.wikipedia.org/wiki/PlayStation_4_system_software). Using [scc](https://github.com/boyter/scc), a tool to evaluate the size of codebases, it estimates it would take about 16 years with 500 people to recreate FreeBSD 12.1. All software is complex; it is one of the most complex man-made things. Physical creations such as spaceships, submarines, and skyscrapers may be complex, but they are limited by the laws of physics. Software has no such limit. For example, [FreeBSD](https://www.freebsd.org/) is an operating system that powers parts of [Netflix](https://www.phoronix.com/scan.php?page=news_item&px=Netflix-NUMA-FreeBSD-Optimized), [WhatsApp](https://www.quora.com/Why-did-WhatsApp-choose-FreeBSD-over-Linux), and [PlayStation 4](https://en.wikipedia.org/wiki/PlayStation_4_system_software). Using [scc](https://github.com/boyter/scc), a tool to evaluate the size of codebases, it estimates 16 years with 500 people would be required to recreate FreeBSD 12.1.
While some complexity is unavoidable, it is best minimized. Here are a few reasons to minimize the complexity of software: While some complexity is unavoidable, it is best minimized. Here are a few reasons to minimize the complexity of software:
* Expensive changes: As software gets more complex, the cost to change increases exponentially. A module bound to several business concerns is more expensive than a module that does one thing. Engineers, business representatives, and managers need to work together on multi-purpose modules instead of handing a simple task to an engineer to work on a single-purpose module. * Expensive changes: As software gets more complex, the cost to change increases exponentially. A module bound to several business concerns is more expensive than a module that does one thing. Engineers, business representatives, and managers need to work together on multi-purpose modules instead of handing a simple task to an engineer to work on a single-purpose module.
* Time: While money can be acquired, time is scarce. If a project becomes expensive, some larger companies can handle it. If the software is complex enough, the bottleneck becomes time, at which point it is too late. Cars travel quickly on highways, partly due to their straight path (simple). If the only way to get from A to B is a winding mountain road (complex), more time will be needed than the highway, no matter how fast a car you buy. * Time: Time is a scarce resource; more importantly, it cannot be produced, accumulated, or recovered. When complexity creeps into software, a large time cost in incurred. Money can be generated or borrowed to offset project costs, but time cannot. This is the most undesirable attribute of complex software.
* Engineer retention: Engineers who work on simple software run into less frustrating walls. This is more fulfilling work, and will keep engineers on the team. Engineers are less likely to take ownership of problems and code if it is part of a complex mess. * Engineer retention: Engineers who work on simple software run into less frustrating walls. This is more fulfilling work, and will keep engineers on the team. Engineers are less likely to take ownership of problems and code if it is part of a complex mess.
## Simple is Difficult, but Effective ## Simple is Difficult, but Effective
An antonym of complexity is [simplicity](https://www.thesaurus.com/browse/complexity). Although it is easy to explain a [simple system](https://simplesystems.tech/blog/post/simplicity), it is not easy to create one. This is the classic investment mindset applied to time. It is better to think twice and code once. Here are a few examples of simplifying principles: An antonym of complexity is [simplicity](https://www.thesaurus.com/browse/complexity). Although it is easy to explain a [simple system](https://simplesystems.tech/blog/post/simplicity), it is not easy to create one. This is the classic investment mindset applied to time. It is better to think twice and code once. Here are a few examples of simplifying principles:
* Encapsulation: When the complexity of software cannot be mitigated, it can still be encapsulated. This powerful idea is what enables the internet to work smoothly; each packet of information sent across it is an envelope. The inner workings of an automatic transmission are quite complex, but it is encapsulated so well that the driver simply selects "D". As [Rob Pike](https://twitter.com/rob_pike) points out in this [video](https://www.youtube.com/watch?v=rFejpH_tAHM&t=789), the simplest interface is no interface at all; garbage collection is completely encapsulated. * Encapsulation: When the complexity of software cannot be mitigated, it can still be encapsulated. This powerful idea is what enables the internet to work smoothly; each packet of information sent across it is an envelope.
* UNIX philosophy: "Make each program do one thing well." This can save software from becoming an indomitable mess. Constantly adding features to the same system will eventually make it collapse in on itself. The inner workings of a vehicle's automatic transmission are quite complex, but it is encapsulated so well that the driver simply selects "D". As [Rob Pike](https://twitter.com/rob_pike) points out in this [video](https://www.youtube.com/watch?v=rFejpH_tAHM&t=789), the simplest interface is no interface at all; garbage collection is completely encapsulated.
* UNIX philosophy: "Make each program do one thing well." This can save software from becoming an indomitable mess. Constantly adding features to the same system will eventually make it collapse in on itself. Maintaining this discipline is difficult, but is more effective than simply saying yes to everything.
* Composition: Software should be composed of interchangeable modules. The boundaries between modules must be well-defined. Chess software should have two players, but those players do not need to be humans on a computer. By keeping the player module separate, it can be swapped for an AI player module. This enables better testing and more interesting games. * Composition: Software should be composed of interchangeable modules. The boundaries between modules must be well-defined. Chess software should have two players, but those players do not need to be humans on a computer. By keeping the player module separate, it can be swapped for an AI player module. This enables better testing and more interesting games.