Worse is better, for better or for worse - Kevlin Henney


Published on

Over two decades ago, Richard P Gabriel proposed the thesis of "Worse Is Better" to explain why some things that are designed to be pure and perfect are eclipsed by solutions that are seemingly limited and incomplete. This is not simply the observation that things that should be better are not, but that some solutions that were not designed to be the best were nonetheless effective and were the better option. We find many examples of this in software development, some more provocative and surprising than others. In this talk we revisit the original premise and question in the context of software architecture.

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Worse is better, for better or for worse - Kevlin Henney

  1. 1. Worse Is Better,for Better or for Worse @KevlinHenney
  2. 2. In 1990 I proposed a theory, calledWorse Is Better, of why software wouldbe more likely to succeed if it wasdeveloped with minimal invention.
  3. 3. It is far better to have an underfeaturedproduct that is rock solid, fast, andsmall than one that covers what anexpert would consider the completerequirements.
  4. 4.  Simplicity: The design is simple in implementation. The interface should be simple, but anything adequate will do. Completeness: The design covers only necessary situations. Completeness can be sacrificed in favor of any other quality. Correctness: The design is correct in all observable aspects. Consistency: The design is consistent as far as it goes. Consistency is less of a problem because you always choose the smallest scope for the first implementation.
  5. 5. Implementation characteristics are foremost: The implementation should be fast. It should be small. It should interoperate with the programs and tools that the expected users are already using. It should be bug-free, and if that requires implementing fewer features, do it. It should use parsimonious abstractions as long as they don’t get in the way.
  6. 6. #!/usr/bin/perl# -------------------------------------------------------- PerlInterpreter# PerlInterpreter must be the first line of the file.## Copyright (c) 1995, Cunningham & Cunningham, Inc.## This program has been generated by the HyperPerl# generator. The source hypertext can be found# at http://c2.com/cgi/wikibase. This program belongs# to Cunningham & Cunningham, Inc., is to be used# only by agreement with the owner, and then only# with the understanding that the owner cannot be# responsible for any behaviour of the program or# any damages that it may cause.# -------------------------------------------------------- InitialComments# InitialCommentsprint "Content-type: text/htmlnn";$DBM = "/usr/ward/$ScriptName";dbmopen(%db, $DBM , 0666) | &AbortScript("cant open $DBM");$CookedInput{browse} && &HandleBrowse;$CookedInput{edit} && &HandleEdit;$CookedInput{copy} && &HandleEdit;$CookedInput{links} && &HandleLinks;$CookedInput{search} && &HandleSearch;dbmclose (%db);if ($ENV{REQUEST_METHOD} eq POST) {$CookedInput{post} && &HandlePost;}# &DumpBinding(*CookedInput);# &DumpBinding(*old);# &DumpBinding(*ENV);# -------------------------------------------------------- WikiInHyperPerl
  7. 7. In a purist view of object-orientedmethodology, dynamic dispatch is the onlymechanism for taking advantage of attributesthat have been forgotten by subsumption.This position is often taken on abstractiongrounds: no knowledge should be obtainableabout objects except by invoking theirmethods. In the purist approach,subsumption provides a simple and effectivemechanism for hiding private attributes.
  8. 8. OOP to me means only messaging,local retention and protection andhiding of state-process, and extremelate-binding of all things. It can bedone in Smalltalk and in LISP. Thereare possibly other systems in whichthis is possible, but Im not aware ofthem. Alan Kay
  9. 9. One of the most pure object-orientedprogramming models yet defined isthe Component Object Model (COM). Itenforces all of these principlesrigorously. Programming in COM isvery flexible and powerful as aresult. There is no built-in notionof equality. There is no way todetermine if an object is aninstance of a given class. William Cook "On Understanding Data Abstraction, Revisited"
  10. 10. William Cook, "On Understanding Data Abstraction, Revisited"
  11. 11. newStack =   (let items = ref()  { isEmpty =   #items = 0, depth =   #items, push =  x  items := xˆitemsy  y  0...#items, top =   items0 })
  12. 12. var newStack = function() { var items = [] return { isEmpty: function() { return items.length === 0 }, depth: function() { return items.length }, push: function(newTop) { items = items.unshift(newTop) }, top: function() { return items[0] } }}
  13. 13. Any application that can bewritten in JavaScript, willeventually be written inJavaScript. Atwoods Law
  14. 14. There have always been fairly severesize constraints on the Unix operatingsystem and its software. Given thepartially antagonistic desires forreasonable efficiency and expressivepower, the size constraint hasencouraged not only economy but acertain elegance of design. Dennis Ritchie and Ken Thompson "The UNIX Time-Sharing System", CACM
  15. 15. This is the Unix philosophy: Writeprograms that do one thing and doit well. Write programs to worktogether. Write programs to handletext streams, because that is auniversal interface. Doug McIlroy
  16. 16. True architectural styledoes not come from aconscious effort to createa particular look. Itresults obliquely — evenaccidentally — out of aholistic process.
  17. 17. Stewart Brand, How Buildings Learn See also http://www.laputan.org/mud/
  18. 18. When a design decisioncan reasonably go one oftwo ways, an architectneeds to take a step back.Instead of trying to decidebetween options A and B,the question becomes"How do I design so thatthe choice between A andB is less significant?" Themost interesting thing is notactually the choicebetween A and B, but thefact that there is a choicebetween A and B. Kevlin Henney "Use Uncertainty As a Driver"
  19. 19. Properly gaining controlof the design processtends to feel like one islosing control of thedesign process.
  20. 20. The classic essay on"worse is better" iseither misunderstoodor wrong. Jim Waldo
  21. 21. Decide for yourselves. Richard P Gabriel