Move the sections of the blog post

1 files changed, 64 insertions, 55 deletions

diff --git a/content/blog/slowftware-development.md b/content/blog/slowftware-development.md
index 92c0826..9c87b6b 100644
--- a/content/blog/slowftware-development.md
+++ b/content/blog/slowftware-development.md
@@ -49,55 +49,7 @@ because the software solution that needed to be implemented quickly to capitaliz
 with redundancies and proper quality control.
 
 Now you start to see how going slower is **faster** and **cheaper**.<br>
-[Working-backwards](#working-backwards) will help with that,
-but let's assume (for now) that one understood the problem correctly, how to "slowly" write the best solution?
-
-# Worse is better
-In 1989, Professor [Richard P. Gabriel][4] wrote an [essay][5] to describe the dynamics of software acceptance.
-It is the argument that software quality does not necessarily increase with functionality: that there is
-a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability.
-Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.
-
-In his [essay][5], he sums up the worse-is-better philosophy as:
-- **Simplicity**: the design must be simple, both in implementation and interface. It is more important for the
-implementation to be simple than the interface. Simplicity is the most important consideration in a design.
-- **Correctness**: the design must be correct in all observable aspects. It is slightly better to be simple than correct.
-- **Consistency**: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity
-in some cases, but it is better to drop those parts of the design that deal with less common circumstances
-than to introduce either implementational complexity or inconsistency.
-- **Completeness**: the design must cover as many important situations as is practical. All reasonably expected
-cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must
-be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness
-if simplicity is retained; especially worthless is consistency of interface.
-
-And although the philosophy itself advocates for better, but a variation of it was adopted early on by Facebook
-and attributed to its founder, Mark Zuckerberg:<br>
-"Move fast and break things and the idea was if unless you're breaking some stuff, you aren't moving fast enough". They
-used to build software as quickly as possible, even sacrificing correctness for the sake of a quick release.<br>
-Another variation was used to justify releasing inferior technology or product sooner than better later.
-
-The essence of the philosophy is,
-
->  **when tradeoffs are required in a software system,
-> priority should go to implementation simplicity at the expense of completeness or correctness.**
-
---- [source][8].
-
-This was observed in the [UNIX philosophy][13]
-- Make it easy to write, test, and run programs.
-- Write programs that do one thing and do it well.
-- Write programs to work together.
-
-And also propagated to many modern languages. For example, [the zen of python][6] emphasizes:
-- Beautiful is better than ugly.
-- Explicit is better than implicit.
-- Simple is better than complex.
-- Complex is better than complicated.
-- If the implementation is hard to explain, it's a bad idea.
-- If the implementation is easy to explain, it may be a good idea.
-
-Now, taking the goals of simplicity then correctness as the highest priorities in the solution,<br>
-how to "slowly" write a "worse" solution?
+So, how to "slowly" write the best solution?
 
 # The Agile Manifesto
 In 2001, _The Agile Alliance_, a group of 17 software practitioners met at a resort to discuss lightweight development
@@ -196,7 +148,54 @@ It ensures that everyone involved in the development process, from engineers to
 product that genuinely meets customer needs (which is a core principle in agile,
 but occasionally miss-placed and miss-used).
 
-But back to the question: How to "slowly" write an "agilely working-backwards worse" solution?
+So, how to "slowly" write the best "working-backwards" solution?
+
+# Worse is better
+In 1989, Professor [Richard P. Gabriel][4] wrote an [essay][5] to describe the dynamics of software acceptance.
+It is the argument that software quality does not necessarily increase with functionality: that there is
+a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability.
+Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.
+
+In his [essay][5], he sums up the worse-is-better philosophy as:
+- **Simplicity**: the design must be simple, both in implementation and interface. It is more important for the
+implementation to be simple than the interface. Simplicity is the most important consideration in a design.
+- **Correctness**: the design must be correct in all observable aspects. It is slightly better to be simple than correct.
+- **Consistency**: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity
+in some cases, but it is better to drop those parts of the design that deal with less common circumstances
+than to introduce either implementational complexity or inconsistency.
+- **Completeness**: the design must cover as many important situations as is practical. All reasonably expected
+cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must
+be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness
+if simplicity is retained; especially worthless is consistency of interface.
+
+And although the philosophy itself advocates for better, but a variation of it was adopted early on by Facebook
+and attributed to its founder, Mark Zuckerberg:<br>
+"Move fast and break things and the idea was if unless you're breaking some stuff, you aren't moving fast enough". They
+used to build software as quickly as possible, even sacrificing correctness for the sake of a quick release.<br>
+Another variation was used to justify releasing inferior technology or product sooner than better later.
+
+The essence of the philosophy is,
+
+>  **when tradeoffs are required in a software system,
+> priority should go to implementation simplicity at the expense of completeness or correctness.**
+
+--- [source][8].
+
+This was observed in the [UNIX philosophy][13]
+- Make it easy to write, test, and run programs.
+- Write programs that do one thing and do it well.
+- Write programs to work together.
+
+And also propagated to many modern languages. For example, [the zen of python][6] emphasizes:
+- Beautiful is better than ugly.
+- Explicit is better than implicit.
+- Simple is better than complex.
+- Complex is better than complicated.
+- If the implementation is hard to explain, it's a bad idea.
+- If the implementation is easy to explain, it may be a good idea.
+
+Now, taking the goals of simplicity then correctness as the highest priorities in the solution,<br>
+So, how to "slowly" write a "working-backwards worse" solution?
 
 # The Big Ball of Mud
 > If you think good architecture is expensive, try bad architecture.
@@ -280,8 +279,7 @@ It is worth mentioning here that, having a design pattern reference guide at arm
 identifying the design pattern(s) that could be employed to solve different or common programming problems. Personally,
 I keep the refactoring.guru [book][24] (and [website][25]) close by.
 
-But back to the question: How to “slowly” write an “agilely working-backwards worse” solution that isn't a "big ball of
-mud"?
+So, how to "slowly" write a "working-backwards worse" solution that isn't a "big ball of mud"?
 
 # Re-disposable code
 In a series of blog posts titled:
@@ -342,8 +340,8 @@ It can also be seen how these concepts are changing depending on the situation.
 it is encapsulating a ball of mud that can be disposable or replaced, yet sometimes AHA is better because [a wrong
 abstraction][32] is even more expensive than no abstraction.
 
-**The bottom line is: There are no silver bullets, use your own judgment.** So
-how to “slowly” write a “boring agilely working-backwards worse” solution that is a "disposable small ball of mud"?
+**The bottom line is: There are no silver bullets, use your own judgment.**<br>
+So, how to "slowly" write a "working-backwards boring worse" solution that is a "disposable ball of mud"?
 
 # Slowftware development
 _pronounced: /sloʊf(t)ˌwɛə/_: is the answer to the previous question by using the previously mentioned concepts to:
@@ -364,7 +362,18 @@ Put simply, use the previously mentioned concepts and techniques, to develop dis
 software in a true agile manner -which occasionally can happen in an agile framework-.<br>
 Apply those ideas to make both the development environment and output products better, and more sustainable.<br>
 Make sure that when you are moving, you are moving into the right direction towards a clear goal,
-and not just moving.<br>
+and not just moving.
+
+This is not a silver bullet to fix current software development, it's not a new paradigm for development, and it's not
+a step-by-step checklist to deliver correct, sustainable, reusable software fast.
+
+This is just the collection of these old ideas, put together in an attempt to make software development more concise and
+more fun, while maintaining a sustainable pace of development with foresight on the end goals, and trying to be as
+fast as possible, without sacrificing or compromising on quality.
+
+So next time, you feel that the way agile is being used in a team or a company isn't working as intended, try suggesting
+or incorporating these ideas in the development process, which I call "slowftware development".
+
 
 [3]: https://varnish-cache.org/docs/trunk/phk/thatslow.html
 [4]: https://en.wikipedia.org/wiki/Richard_P._Gabriel