From 3b23b2661ea2f7f96311209ffd57d7c487fcc463 Mon Sep 17 00:00:00 2001 From: Ahmed Abdelhalim Date: Tue, 1 Oct 2024 12:48:55 +0200 Subject: Move the sections of the blog post --- content/blog/slowftware-development.md | 119 ++++++++++++++++++--------------- 1 file 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**.
-[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:
-"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.
-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,
-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:
+"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.
+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,
+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.**
+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-.
Apply those ideas to make both the development environment and output products better, and more sustainable.
Make sure that when you are moving, you are moving into the right direction towards a clear goal, -and not just moving.
+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 -- cgit v1.2.3