content/blog/complexity.md

@@ -23,24 +23,23 @@ Before being able to manage complexity, it must be identified.  In addition to t
 * Humans: No two humans are the same.  DNA on its own is complex; factoring in the expression of DNA is beyond the understanding of any single person. 
 
 ## 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.  Using [scc](https://github.com/boyter/scc), a tool to estimate the size of codebases, it is shown to take about 16 years with 500 people to recreate [FreeBSD](https://www.freebsd.org/).
- 
-Considering the global communication they have to do, the complexity goes up exponentially.
+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 estimate the size of codebases, it is shown to take about 16 years with 500 people to recreate FreeBSD 12.1.
 
-While some complexity is unavoidable, it is best minimized.  Left unchecked, it will become unmanageable and will have to be scrapped to begin again.  Complex software is difficult to reason about and therefore difficult to rule out problems.  This is code that an adversary would enjoy combing through, trying to find an exploit.
+While some complexity is unavoidable, it is best minimized.  Complex software is difficult to reason about and therefore difficult to rule out bugs.  This is code that an adversary would enjoy combing through, trying to find an exploit.
+{ reasons it is undesirable }
 
-## Software engineers program, but programmers do not engineer
+## Software Engineers Program, but Programmers do not Engineer
 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 may take up almost all the time of a software engineer.  Many other tasks such as designing, testing, documenting, refactoring, and code reviews 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.
 
-## Simple is difficult, but effective
-[An antonym of complexity is simplicity.](https://www.thesaurus.com/browse/complexity) Although it is easy to express what a [simple system](https://simplesystems.tech/blog/post/simplicity) is, it is not easy to create one.  Simplicity is so effective to software, there are many books, blogs, and principles written on the topic -- even if not explicitly.  A few examples of principles:
+## Simple is Difficult, but Effective
+[An antonym of complexity is simplicity.](https://www.thesaurus.com/browse/complexity) Although it is easy to express what a [simple system](https://simplesystems.tech/blog/post/simplicity) is, it is not easy to create one.  Simplicity is so effective in software that many books and blogs are written on the topic.  A few examples of simplifying principles:
 
-* Encapsulation: This is a very powerful idea, especially when some complexity cannot be mitigated.  It can still be encapsulated.
-* UNIX philosophy:  "Make each program do one thing well."  This can save software from becoming an indominable mess.  Constantly adding features to the same program will eventually make it collapse in on itself.
-* Composition: Software should be composed of interchangable modules.  The boundaries between modules and modules responsibilities must be well defined.
+* Encapsulation: This is a very powerful idea, especially when some complexity cannot be mitigated -- it can still be 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.
+* Composition: Software should be composed of interchangeable modules.  The boundaries between modules must be well-defined.
 
-None of these principles are easy to carry out.  There is both a science and art aspect of designing and building something in a simple manner.  Once a system becomes simple, the benefits are exponential.  One important benefit for teams to think about is number of engineers who can work on a project.  If a system becomes an interconnected mess, usually only 1 or 2 people can work on it simultaneously.  If a system is well designed, especially using modularity, the number of engineers who can work on it simultaneously is practically unlimited, because each module is independent.
+None of these principles are easy to incorporate into an engineering process.  There is both a science and art aspect of designing and building something in a simple manner.  Once a system becomes simple, the benefits are exponential.  One important benefit for teams to think about is number of engineers who can work on a project.  If a system becomes an interconnected mess, usually only 1 or 2 people can work on it simultaneously.  If a system is well designed, especially using modularity, the number of engineers who can work on it simultaneously is practically unlimited, because each module is independent.
 
 ##### ? Monero provides a simple interface, but it was not easy to create.  There is a lot going on behind the scenes.
 ##### Reference Rob Pike's comments on GC (The simplest interface is none at all) https://www.youtube.com/watch?v=rFejpH_tAHM