diff options
Diffstat (limited to 'content/blog/slowftware-development.md')
| -rw-r--r-- | content/blog/slowftware-development.md | 119 |
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 |