"Good Enough" IS Good Enough!

Fundamentals, Intermediate

​

Description 

Our culture's default assumption is that everybody should always be striving for perfection -- settling for anything less is seen as a regrettable compromise. This is wrong in most software development situations: focus instead on keeping the software simple, just "good enough", launch it early, and iteratively improve, enhance, and re-factor it. This is how software success is achieved!

​

Abstract

In 1989, Richard Gabriel caricatured two approaches to SW development: "worse is better" ("New Jersey approach") and "the right thing" ("MIT/Stanford approach"), reluctantly concluding NJ was more viable, for several reasons (speed of development, flexible designs, systems adaptable to a variety of uses [including changes in requirements], ease of gradual, incremental improvement, ...). And this debate hasn't died down since.

Debate rages, but reality has moved away from "right thing" ("Cathedral"-centralized "Big Design Up Front", focus on academia/large firms, unsuited to shifting real-world requirements), toward "NJ" ("Bazaar"-like, agile iterative enhancement, dynamic start-ups/independent developers, a world of always-shifting specs).

In this talk I support "the NJ approach", on both philosophical and pragmatical grounds, with examples from many areas. Winners of the "mind-share battles" focused on simplicity ("good enough"), not theoretical refinement/completeness: large ecosystems of developers, incremental improvement -- TCP/IP approach vs ISO/OSI, HTTP/HTML vs Xanadu, early Unix's simplistic (but OK) approach to interrupted system calls vs Multic's/ITS's perfectionism.

In Python, metaclasses often end up too complex (80% of their pluses can be had via class decorators, for 20% of the complexity); OTOH, incremental improvement worked just fine in sorting, generators, and guaranteed-finalization semantics.

The talk is not perfect, but I do think it's good enough.