diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/blog/slowftware-development.md | 78 |
1 files changed, 56 insertions, 22 deletions
diff --git a/content/blog/slowftware-development.md b/content/blog/slowftware-development.md index 5367798..9884cbe 100644 --- a/content/blog/slowftware-development.md +++ b/content/blog/slowftware-development.md @@ -27,8 +27,7 @@ There is no perfect software, and there will be none in the future, but there ar (and software developers) out there, and for anything good to develop, it needs time, **lots** of time. The time required is dependent on many factors, including but not limited to, the developer's previous experiences, -the understanding of the problem, the time needed to theorize a solution, and the time needed to code that -solution. +the understanding of the problem, the time needed to theorize a solution, and the time to code that solution. The first factor, "previous experience," isn't controllable. (at least not for this post's purposes).<br> The last factor, "time to code," is the least important, it can be adjusted (with hiring) or planning costs for the @@ -157,23 +156,48 @@ a point where less functionality ("worse") is a preferable option ("better") in 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. - -Although the philosophy itself advocates for better, 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 an inferior technology or a product sooner rather than a better one -later. +> - **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. + +This philosophy has been miss-interpreted[^1] (past the catchiness of the phrase), as advocating for doing a bad +job with code or architecture. In truth, what the philosophy embodies is a stronger emphasis on quality and +true agile principles (incremental change and sustainable development pace). + +To elaborate on "simplicity over correctness": + +> Looking through the definition of "Worse Is Better," you might be struck by the immense value it places on +> correctness, more than most other approaches that state it is a value, but don't support it beyond lip service. +> The "Worse Is Better" position that "the design must be correct in all observable aspects" is fairly clear on where +> it stands on correctness. But it is not uncompromising, as the "better to be simple than correct" +> compromise acknowledges. +> +> When we state characteristics of a design style, such as simplicity and correctness, these characteristics are +> often in sympathy, but sometimes they are in tension. How do we resolve that tension? Simplicity is considered +> the most important characteristic. One consequence of simplicity is improved correctness: not just that it is easier +> to create correct code, but that it is easier to see that code is correct. As Tony Hoare observed, +> "There are two ways of constructing a software design: One way is to make it so simple that there are obviously +> no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." +> It is also easier to correct something that is incorrect when it is simple than when it is complicated. +> +> Furthermore, it is easier to discard and replace something that is simple and incorrect. Because it's simple, +> we understand it and can replace it with confidence—than something that is complicated and incorrect — because +> it's complicated, we do not understand it, so replacement evokes fear. There is another side to this as well: +> favor something that is simple and correct over something that is complicated and correct, +> because, whatever our aspirations, the latter is less likely to be or to remain correct. +> +> In short, the (minor) ordering of simplicity over correctness better serves the longer term than just emphasising +> correctness alone. + +--- [source][33]. The essence of the philosophy is, @@ -182,7 +206,7 @@ The essence of the philosophy is, --- [source][8]. -This was observed in the [UNIX philosophy][13] +This philosophy 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. @@ -242,8 +266,8 @@ even more expensive- and takes a lot of time too). There are always exceptions of course, for example, the paper mentions how the [Wiki-Web code at c2.com][22] has its humble origins as a "THROWAWAY CODE" that succeeded beyond the author's expectation, but this is not the rule. The observations in the paper, and the prevalence of the "BIG BALL OF MUD" or some dialect of it, can almost always be -traced back to the previous forces mentioned, and how their application always undermines the architecture of the system -and results in these undesirable patterns. +traced back to the previously mentioned forces (Time, Experience, Complexity, ...), +and how their application always undermines the architecture of the system and results in these undesirable patterns. Although the publishing of this paper precedes the publishing of the Agile manifesto, it's hard not to see the similarities between the common misinterpretation of the Agile principles, and the causes/forces that lead to @@ -375,6 +399,14 @@ 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". +_Special thank to [Abdallah Dorra][34] for proof-reading and making suggestions on unclear sections._ + +--- +[^1]: one famous misinterpretation, a variation 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".<br> + They used it to build software as quickly as possible, even sacrificing correctness for the sake of a quick release. + [3]: https://varnish-cache.org/docs/trunk/phk/thatslow.html [4]: https://en.wikipedia.org/wiki/Richard_P._Gabriel @@ -406,3 +438,5 @@ or incorporating these ideas in the development process, which I call "slowftwar [30]: https://en.wikipedia.org/wiki/Don't_repeat_yourself [31]: https://en.wikipedia.org/wiki/Don't_repeat_yourself#AHA [32]: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction +[33]: https://www.agileconnection.com/interview/worse-better-revisited-interview-kevlin-henney +[34]: https://www.linkedin.com/in/abdallah-dorra-2bbba229/ |