Worse Is Better, for Better or for Worse
Upcoming SlideShare
Loading in...5
×
 

Worse Is Better, for Better or for Worse

on

  • 3,149 views

Presented at GeeCON (15th May 2014) ...

Presented at GeeCON (15th May 2014)

Over two decades ago, Richard Gabriel proposed the idea of “Worse Is Better” to explain why some things that are designed to be pure and perfect are eclipsed by solutions that are seemingly compromised and imperfect. This is not simply the observation that things should be better but are not, or that flawed and ill-considered solutions are superior to those created with intention, but that many solutions that are narrow and incomplete work out better than the solutions conceived of as being comprehensive and complete. Whether it is programming languages, operating systems, development processes or development practices, 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, and look at how this approach to development can still teach us something surprising and new.

Statistics

Views

Total Views
3,149
Views on SlideShare
3,068
Embed Views
81

Actions

Likes
8
Downloads
95
Comments
0

3 Embeds 81

http://agora 63
https://twitter.com 17
http://www.google.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Worse Is Better, for Better or for Worse Worse Is Better, for Better or for Worse Presentation Transcript

  • Worse Is Better, for Better or for Worse @KevlinHenney
  • There are a thousand thoughts lying within a man that he does not know till he takes up the pen to write. William Thackeray
  • Stop Overpromising and Overshooting We want to do everything all at once. Grand plans! Sweeping gestures! Epic 23-book fantasy cycles! Don’t overreach. Concentrate on what you can complete. Temper risk with reality. Chuck Wendig http://terribleminds.com/ramble/2012/01/03/25-things-writers-should-stop-doing/
  • You have to finish things — that's what you learn from, you learn by finishing things. Neil Gaiman
  • In 1990 I proposed a theory, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention.
  • It is far better to have an underfeatured product that is rock solid, fast, and small than one that covers what an expert would consider the complete requirements.
  • The "good enough software" concept popularized by Yourdon. In many senses, it's just a rationalization of what's happening in the software world: the first company hitting the market with a feature-rich product is more likely to win the battle than the careful, quality-seeking company. Carlo Pescio http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html
  • "Good enough software" is rarely good enough. Niklaus Wirth http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html
  • The following is a characterization of the contrasting [the right thing] design philosophy:  Simplicity: The design is simple [...]. Simplicity of implementation is irrelevant.  Completeness: The design covers as many important situations as possible. All reasonably expected cases must be covered.  Correctness: The design is correct in all observable aspects.  Consistency: The design is thoroughly consistent. A design is allowed to be slightly less simple and less complete in order to avoid inconsistency. Consistency is as important as correctness.
  • Here are the characteristics of a worse-is-better software design:  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.
  • 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.
  • The more specific a design idea is, the greater its appeal is likely to be.
  • #!/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 # InitialComments print "Content-type: text/htmlnn"; $DBM = "/usr/ward/$ScriptName"; dbmopen(%db, $DBM , 0666) || &AbortScript("can't 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
  • There have always been fairly severe size constraints on the Unix operating system and its software. Given the partially antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy but a certain elegance of design. Dennis Ritchie and Ken Thompson "The UNIX Time-Sharing System", CACM
  • I always have it in the back of my head that I want to make a slightly better C. But getting everything to fit, top to bottom, syntax, semantics, tooling, etc., might not be possible or even worth the effort. As it stands today, C is unreasonably effective, and I don't see that changing any time soon. Damien Katz http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
  • There are only two kinds of languages: the ones people complain about and the ones nobody uses. Bjarne Stroustrup
  • Savings in time feel like simplicity
  • Interface Implementation
  • Implementation Interface
  • Implementation Interface
  • Aesthetics does not affect perceived usability, but degraded usability negatively affects perceived aesthetics. In other words, usability is more important than beauty. "Is Beautiful Usable, or Is It the Other Way Around?" http://www.infoq.com/news/2012/05/Aesthetics-Usability
  • OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Alan Kay
  • One of the most pure object- oriented programming models yet defined is the Component Object Model (COM). It enforces all of these principles rigorously. William Cook "On Understanding Data Abstraction, Revisited"
  • Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other. Ralph Johnson
  • Analysis Design Code Test
  • Analysis Design Code Test
  • Analysis Design Code Test
  • Design Design Design Design
  • Design
  • Um. What's the name of the word for things not being the same always. You know, I'm sure there is one. Isn't there? There's must be a word for it... the thing that lets you know time is happening. Is there a word? Change. Oh. I was afraid of that. Neil Gaiman The Sandman
  • The "defined" process control model requires that every piece of work be completely understood. Given a well- defined set of inputs, the same outputs are generated every time. Ken Schwaber Agile Software Development with Scrum
  • The empirical process control model, on the other hand, expects the unexpected. It provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable results. Ken Schwaber Agile Software Development with Scrum
  • Properly gaining control of the design process tends to feel like one is losing control of the design process.
  • The classic essay on "worse is better" is either misunderstood or wrong. Jim Waldo
  • Decide for yourselves. Richard P Gabriel