Grammarly check

1 files changed, 43 insertions, 42 deletions

diff --git a/content/blog/slowftware-development.md b/content/blog/slowftware-development.md
index 9c87b6b..5367798 100644
--- a/content/blog/slowftware-development.md
+++ b/content/blog/slowftware-development.md
@@ -6,7 +6,7 @@ draft: false
 
 # Going fast, slowly
 I recently came across an almost [10-year-old blog post][3] on Varnish HTTP Cache
-(which was released almost 20 years ago).
+(which was released nearly 20 years ago).
 In that post, the author shares the LoC (Lines of Code) analysis of Varnish and talks about the average
 LoC per hour per developer and how the LoC metric has been used before to judge productivity.
 
@@ -30,7 +30,7 @@ The time required is dependent on many factors, including but not limited to, th
 the understanding of the problem, the time needed to theorize a solution, and the time needed to code that
 solution.
 
-The first factor, "previous experience," isn't controllable. (at least not for this post purposes).<br>
+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
 estimated time required.<br>
 The other two factors are the most influential. And the ones that are affecting how correct the "time to code"
@@ -60,8 +60,8 @@ They wrote down the [Manifesto for Agile Software Development][15], and the 12
 [Principles behind the Agile Manifesto][16]. And although these lightweight methods already preceded the publication
 of the Agile Manifesto, they came to be collectively referred to as the agile software development methods.
 
-Few things have reached far and beyond the reach of the agile manifesto in software development, and fewer things
-have had more impact than the agile manifesto in recent years on software development and work methodologies
+Few things have reached far and beyond the reach of the Agile Manifesto in software development, and fewer things
+have had more impact than the Agile Manifesto in recent years on software development and work methodologies
 (both good and bad).
 
 Over the years, there has been criticism and debate over the agile values, and how they can undermine various
@@ -78,17 +78,17 @@ disciplines of the software development process, namely documentation and testin
 
 --- [source][17].
 
-Personally, I think that most of the criticism, is targeted towards the interpretation or to be more specific,
-the miss-interpretation of the agile principles. That's not to say that there are no merits to the criticism,
+Personally, I think that most of the criticism is targeted towards the interpretation or to be more specific,
+the misinterpretation of the agile principles. That's not to say that there are no merits to the criticism,
 but to actually inspect and try to correct the shortcomings of the agile framework.
 
 In an [article][18] titled, "**Have we taken agile too far?**", [Colin Bryar][19] and [Bill Carr][20] write about
-their criticism  of agile process, especially in the crucial early stages.
+their criticism of the Agile process, especially in the crucial early stages.
 
 > Agile is a powerful process for product development, but many organizations are taking it too far and using it
 > to avoid careful planning and preparation.
 
-They elaborate on this deposition that "**Speed Isn't Everything**", they inspect a miss-interpretation of the principle
+They elaborate on this deposition that "**Speed Isn't Everything**", they inspect a misinterpretation of the principle
 "**Sustainable development, able to maintain a constant pace**", where the focus is on maintaining a constant pace
 rather than being sustainable.
 
@@ -104,7 +104,7 @@ rather than being sustainable.
 > viable at all, so customers can’t give realistic feedback. The developers haven’t had time to do their homework
 > and prepare something that’s sustainable.
 
-In order to avoid these miss-interpretations and reap the benefits of using agile, they suggest:
+In order to avoid these misinterpretations and reap the benefits of using agile, they suggest:
 
 > We’re not arguing that companies should throw agile out the window. It’s still a highly effective tool for product
 > development, especially software-driven offerings. Many of its principles and processes have been used successfully
@@ -115,13 +115,13 @@ In order to avoid these miss-interpretations and reap the benefits of using agil
 
 # Working Backwards
 
-Working backwards is a systematic way of vetting ideas to create new products. It starts by defining the
-customer experience, then iteratively work backwards from there until the team achieves the clarity of thought
+Working Backwards is a systematic way of vetting ideas to create new products. It starts by defining the
+customer experience, then iteratively work backward from there until the team achieves the clarity of thought
 around what to build.
 
 In their book titled "[**Working Backwards**][21]", authors [Colin Bryar][19] and [Bill Carr][20], describe (among
-many other principles and practices) the "working backwards" strategy and how it was developed, its key tenets, and
-the practices that emerged from working backwards (i.e., the banning of PowerPoint presentations at Amazon).
+many other principles and practices) the "Working Backwards" strategy and how it was developed, its key tenets, and
+the practices that emerged from working backward (i.e., the banning of PowerPoint presentations at Amazon).
 
 > Working backwards emerged in 2004: Amazon’s e-commerce strategies had proven successful, and the company was
 > aggressively seeking new opportunities with a large potential market. Where should it look?
@@ -139,8 +139,8 @@ the practices that emerged from working backwards (i.e., the banning of PowerPoi
 
 --- [source][18].
 
-The brilliance of this strategy, is that the iterative process of drafting, reviewing, and refining the PR/FAQ documents
-forces the teams and management to take the time to deeply understand not only the problem at hand,
+The brilliance of this strategy is that the iterative process of drafting, reviewing, and refining the PR/FAQ documents
+forces the teams and management to take the time to deeply understand not only the problem at hand
 but also the vision of what the product **is** to be, not what the product **might** be
 (when developed with agile MVP principles).
 
@@ -168,11 +168,12 @@ cases should be covered. Completeness can be sacrificed in favor of any other qu
 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
+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 inferior technology or product sooner than better later.
+Another variation was used to justify releasing an inferior technology or a product sooner rather than a better one
+later.
 
 The essence of the philosophy is,
 
@@ -217,7 +218,7 @@ In this paper, the authors examine many of the forces that affect the architectu
 - Cost.
 
 And how these forces can affect the development life-cycles.<br>
-The uniqueness of this paper is that it actually doesn't describe the resulting systems as anti-patterns.
+The uniqueness of this paper is that it doesn't describe the resulting systems as anti-patterns.
 
 > These are not anti-patterns, at least in the customary sense. They are not straw men. Instead, they seek to
 > examine the gap between what we preach and what we practice.<br>
@@ -230,8 +231,8 @@ The uniqueness of this paper is that it actually doesn't describe the resulting
 
 They go even further as to observe that this specific pattern might have a survival advantage over good code, not a
 position most companies want to be in, since the cost to maintain, and time to fix bugs increases drastically the longer
-the project runs. More over, it can (and almost always) lead to the "TOTAL REWRITE" (which is also as expensive if not
-even more expensive, and takes a lot of time too).
+the project runs. Moreover, it can (and almost always) lead to the "TOTAL REWRITE" (which is also as expensive -if not
+even more expensive- and takes a lot of time too).
 
 > As per CONWAY’S LAW [Coplien 1995], architects depart in futility, while engineers who have mastered the muddy details
 > of the system they have built in their images prevail. [Foote & Yoder 1997] went so far as to observe that inscrutable
@@ -244,11 +245,11 @@ observations in the paper, and the prevalence of the "BIG BALL OF MUD" or some d
 traced back to the previous forces mentioned, and how their application always undermines the architecture of the system
 and results in these undesirable patterns.
 
-And although the publishing of this paper precedes the publishing of the Agile manifesto, it's hard not to see the
-similarities between the common miss-interpretation of the agile principles, and the causes/forces that lead to
+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
 develop big balls of mud.
 
-**A good takeaway from this paper, is how important software architecture is to maintaining a healthy system, that
+**A good takeaway from this paper is how important software architecture is to maintaining a healthy system, that
 can be cost-efficiently maintained and relatively fast to fix.**
 
 > It is not our purpose to condemn BIG BALLS OF MUD. Casual architecture is natural during the early
@@ -288,7 +289,7 @@ In a series of blog posts titled:
 1. [Repeat yourself, do more than one thing, and rewrite everything.][28]
 
 The [author][29] suggests that instead of focusing on code reusability, one should focus more on code disposability.
-The reasoning behind this, is not that it's just more fun to delete code down the line (although it's really fun), but
+The reasoning behind this is not that it's just more fun to delete code down the line (although it's really fun), but
 with the main focus on disposability, it results in a system that is actually more reusable, and less tightly coupled.
 
 They start with the following quote:
@@ -303,7 +304,7 @@ beginning as follows:
 > Don’t hard code every choice, and maybe allow changing a few at runtime.
 > Don’t try to do all of these things at the same time, and maybe don’t write so much code in the first place.
 
-These steps and concepts not only embrace the resulting "balls of mud" and keep them at bay, but also utilize the
+These steps and concepts not only embrace the resulting "balls of mud" and keep them at bay but also utilize the
 resulting effects they have on the system to improve system usability by improving the system disposability.
 > A system where you can delete parts without rewriting others is often called loosely coupled,
 > but it’s a lot easier to explain what one looks like rather than how to build it in the first place.<br>
@@ -315,7 +316,7 @@ resulting effects they have on the system to improve system usability by improvi
 > Code that is loosely coupled isn’t necessarily easy-to-delete, but it is much easier to replace,
 > and much easier to change too.
 
-One of the interesting ideas, is the discectomy between clean and boring code, and how sometimes clean code
+One of the interesting ideas is the discectomy between clean and boring code, and how sometimes clean code
 isn't desirable since it's harder to debug than boring code, or as the author puts it:
 > The problem is that “clean” is highly contextual in meaning. Clean code can be hard-coded into a system,
 > and sometimes a dirty hack can written in a way that’s easy to turn off. Sometimes the code is clean because
@@ -329,39 +330,39 @@ isn't desirable since it's harder to debug than boring code, or as the author pu
 > ...<br>
 > **Code that’s easy to debug is easy to explain.**
 
-Another interesting idea, is the miss-interpretation of "[Don't Repeat Yourself (DRY)][30]" as "Don't Copy Paste". There
-is a complete post about miss-using DRY and how it complicates the system design and, in return, makes the system less
-reusable and less disposable.
+Another interesting idea is the misinterpretation of "[Don't Repeat Yourself (DRY)][30]" as "Don't Copy Paste". There
+is a complete post about the misuse of DRY and how it complicates the system design and, in return, makes the system
+less reusable and less disposable.
 
 A healthy level of repetition and redundancy can a lot of times help in maintaining a system that is disposable and
 reusable; the "[Avoid Hasty Abstraction (AHA)][31]" is an example of this.
 
 It can also be seen how these concepts are changing depending on the situation. Sometimes DRY is better than AHA because
-it is encapsulating a ball of mud that can be disposable or replaced, yet sometimes AHA is better because [a wrong
+it encapsulates 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.**<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:
-- work-backwards from the customer's or client's point of view.
-- identify the right problem that needs to be solved.
-- simplify that solution.
-- iterate on the simplified solution with different stakeholders.
-- start conceptualizing an architecture -based on design patterns if possible-.
+_Pronounced: /sloʊf(t)ˌwɛə/_: is the answer to the previous question by using the previously mentioned concepts to:
+- Work-backwards from the customer's or client's point of view.
+- Identify the right problem that needs to be solved.
+- Simplify that solution.
+- Iterate on the simplified solution with different stakeholders.
+- Start conceptualizing an architecture -based on design patterns if possible-.
 
 Then, once the theorized solution has been decided:
-- write a disposable boring code, that is also easy to debug (and test).
-- follow the agile principles, not the agile framework meetings.
+- Write a disposable boring code, that is also easy to debug (and test).
+- Follow the agile principles, not the agile framework meetings.
 
-Iterate with the customer, once a meaningful chunk of the work has been delivered, welcome late changes, while
-rewriting your code to be more boring, more disposable and more testable.
+Iterate with the customer, once a meaningful chunk of the work has been delivered, and welcome late changes, while
+rewriting your code to be more boring, more disposable, and more testable.
 
 Put simply, use the previously mentioned concepts and techniques, to develop disposable, reusable, sustainable
-software in a true agile manner -which occasionally can happen in an agile framework-.<br>
+software in a truly 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,
+Make sure that when you are moving, you are moving in the right direction towards a clear goal,
 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