/~/blog/ Slowftware Development
2024.10.06

Slow is Fast

The fastest way to create high-quality software is to develop this software slowly and thoughtfully. It might seem counterintuitive, but by focusing on understanding the problem, designing the right solution, and refining it through iteration and simplification, ends up being faster in the long run.1

Rushing to get an MVP out the door often results in poorly scoped projects and architectural design, technical debt, and “Big balls of Mud” – architectures that are costly to maintain, and slow to fix.

Perfection Through Removal

“Perfection is attained, not when there is nothing more to add, but when there is nothing more to remove.”
— Antoine de Saint-Exupéry’s observation

The same applies also to software development. Simplicity trumps complexity. Clean, maintainable software is born from stripping down, not piling on. Yet, simplicity doesn’t come quickly. It requires careful thinking, planning, and understanding the problem before jumping into coding.

Worse is Better

In 1989, Professor Richard P. Gabriel wrote an essay 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, 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.

This philosophy advocates a stronger emphasis on quality and true agile principles through “simplicity over correctness”2.

It’s easier to maintain simple software, even if it’s not fully feature-complete. A simpler design is often more robust because it’s easier to test, easier to debug, and easier to extend later on. By aiming for simplicity, you not only make the system easier to work with but also pave the way for future improvements.

Working Backwards

Amazon’s “Working Backwards” process exemplifies the power of taking time upfront to define the customer experience. Before any code is written, teams work backward from the final product, crafting press releases and FAQs to clarify the vision. This approach forces developers and stakeholders to deeply understand the problem before jumping into solutions, preventing the costly mistake of building the wrong thing.

By focusing on the end goal from the start, it ensures that despite that the process may seem counterintuitive and slower, it actually speeds up the development and delivers better products.34

Agile Pitfalls

Agile, though powerful, is often misunderstood and misinterpreted, Many organizations are taking it too far and using it to avoid careful planning and preparation5, Many teams focus on velocity and delivering a constant stream of features without truly understanding the product’s requirements. This “move fast, break things”6 approach can lead to shallow products that don’t truly solve the customer’s problems. Instead of rushing to build the next feature, teams should balance speed with proper planning, and proper architectural decisions, focusing on building sustainable solutions rather than quick fixes.

Avoid the Big Ball of Mud

In a paper published in 1997, Authors Brian Foote, and Joseph Yoder examine the most frequently deployed architecture, dubbed “The BIG BALL OF MUD”:

A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

“Big Ball of Mud” architectures arise when short-term gains —like meeting deadlines— are prioritized over long-term health —like architectural design integrity—. These systems are thrown together hastily, without regard to maintainability, leading to increased complexity and either an inevitable need for rewrites or quite high maintenance and running costs.

Many reasons could lead to the creation of a “Big Ball of Mud”, these include:

While architecture often takes a back seat to more mundane concerns such as cost, time-to-market, and programmer skill. Architecture is a long-term concern, and shouldn’t be seen as a luxury, or treated with neglect. To quote the authors:

If you think good architecture is expensive, try bad architecture.
— Brian Foote

Good architecture takes time and meticulous thought, but it pays off when your system is easy to maintain and scale.

Code Disposability Over Reusability

Another shift in thinking comes with focusing on code disposability. Rather than trying to write code that’s reusable across the board, aim for code that’s easy to delete or replace.

By reducing dependencies and layering the code, you build flexibility into the system, making it easier to evolve. “Boring7” (aka simple code) is often more effective than clean but overly abstracted code, which is harder to debug or replace when needed.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
— Brian W. Kernighan

There can be tension between “Code Disposability” and “Code Reusability”, namely around the “DRY” principle, In such cases, a “healthy” level of repetition that would make the code more replaceable or removable is preferred to making the code more reusable (by being more “DRY”).8

Slowftware Development

(or slow software development), is the collection of these old ideas and concepts, to develop valuable, maintainable software with patience and a deliberate focus on simplicity and correctness.

It’s an attempt to embrace working backward from the realized end-product vision, iteration, disposable code, and solid architecture design to create systems that don’t just work for today but are easy to constantly and sustainably evolve in the future.

Slow software development isn’t about being slow. It is about being thoughtful, sustainable, and ultimately, faster in the long run.

Special thanks to Abdallah Dorra and Tom Nick for proofreading, reviewing, and making suggestions on this post.

Further Readings:

  1. “In our study of 343 businesses (conducted with the Economist Intelligence Unit), the companies that embraced initiatives and chose to go, go, go to try to gain an edge ended up with lower sales and operating profits than those that paused at key moments to make sure they were on the right track. What’s more, the firms that “slowed down to speed up” improved their top and bottom lines, averaging 40% higher sales and 52% higher operating profits over a three-year period.” — source ↩︎

  2. In this interview, Kevlin Henney elaborates on this claim, “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. It is also easier to correct something that is incorrect when it is simple than when it is complicated. And it is easier to discard and replace something that is simple and incorrect, because it’s simple.” ↩︎

  3. The Kindle e-reader, AWS cloud computing services, and the Echo voice assistant with Alexa all came from “working backwards” at Amazon. ↩︎

  4. Fun fact: The initial version of this article was written in an “investigative journalistic” style about the history of the blog’s ideas and philosophies, but Tom Nick suggested “working backwards” from the desired conclusion and end goal of the post, and building the narrative from there, removing all the unnecessary narrative, quotes, and undefended claims. Which led to a better and shorter final version. ↩︎

  5. “The fundamental problem with agile, as many companies use it, is that its relentless pace biases developers. They want to get out a minimum viable product in only a few weeks, so they skimp on scoping out just what the product should accomplish.” — source ↩︎

  6. Although Gabriel himself later regretted this statement, many software companies latched onto this particular interpretation of the worse-is-better philosophy. Facebook’s Mark Zuckerberg promoted the “Move fast and break things” term. — source ↩︎

  7. “Boring is good. Boring is stable. Boring means being able to focus on your work.” – source ↩︎

  8. This claim was inspected by Sandi Metz in her blog post and RailsConf talk. ↩︎