Blog Post: Complexity #12

Merged
jeff merged 13 commits from BlogPost_Complexity into master 2020-04-19 22:57:46 +00:00
Showing only changes of commit e43dd030db - Show all commits

View File

@ -27,13 +27,13 @@ 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. [FreeBSD](https://www.freebsd.org/) is an operating system that was first released in 1993. 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 space ships, submarines, and skyscrapers may be complex, but they are limited by the laws of physics. Software has no such limit. [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.
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 instead of just handing a simple task to an engineer. * 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 instead of just handing a simple task to an engineer.
* Time: While money can be acquired, time keeps ticking. If a project becomes expensive, some larger companies can handle it. If the software is complex enough, the bottleneck becomes time and at that point it is too late. By analogy, if the task is to carry a gallon of water 100 meters, it could be put in a car(expensive, but fast) and cover the distance quickly. If the water must be converted to steam and then back to water, it will take much longer, and the car will not help with delivering it on time. * 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 and at that point it is too late. By analogy, if the task is to carry a cup of water 100 meters, it could be put in a car(expensive, but fast) and cover the distance quickly. If the water must be converted to steam and then back to water, it will take much longer, and the car will not help with delivering it on time.
* 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.
@ -46,11 +46,12 @@ An antonym of complexity is [simplicity](https://www.thesaurus.com/browse/comple
* Composition: Software should be composed of interchangeable modules. The boundaries between modules must be well-defined. Chess software should have 2 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 2 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.
These principles are not easy to incorporate into an engineering process. There is both a science and an art aspect to designing and building something simply. Once a system becomes simple, the benefits become evident quickly. One important benefit for teams to think about is the number of engineers who can work on a project. If a system becomes a convoluted mess, usually only 1 or 2 people can work on it simultaneously. A system designed well, especially using modularity, will increase the number of engineers who can work on it simultaneously. These principles are not easy to incorporate into an engineering process. There is both a science and an art aspect to designing and building something simply. Once a system becomes simple, the benefits become evident quickly. One important benefit for teams to think about is the number of engineers who can work on a project. If a system becomes a convoluted mess, usually only a couple people can work on it. A system designed well, especially using modularity, will increase the number of engineers who can work on it.
## Software Engineers Manage Complexity ## Software Engineers Manage Complexity
A programmer understands software languages and can program a computer to accomplish tasks. A software engineer will do the same, with the addition of minimizing the program's complexity. In fact the act of minimizing the complexity takes up most of the engineer's time. Many other tasks such as designing, testing, documenting, refactoring, and code reviews are much more time intensive -- and important -- than the actual programming. A programmer understands software languages and can program a computer to accomplish tasks. A software engineer will do the same, with the addition of minimizing the program's complexity. In fact the act of minimizing the complexity takes up most of the engineer's time. Many other tasks such as designing, testing, documenting, refactoring, and reviewing code are much more time intensive -- and important -- than the actual programming.
Software engineers must create programs that are simple enough to be understood by other engineers. This enables others to work on the project and create something greater than the sum of the engineers' abilities. Software engineers must create programs that are simple enough to be understood by other engineers. This enables others to work on the project and create something greater than the sum of the engineers' abilities. Creating obvious software is a skill acquired through working with others. One of the most useful abilities of that skill is to use [design patterns](https://en.wikipedia.org/wiki/Software_design_pattern). When the writer and reader of a program know a common design pattern, they can quickly communicate its intent.
##### ? design patterns ## Conclusion
Writing software is easy, but writing good software is not. Seek simplicity to save the business and other engineers time and money.