2016 - Alex Martelli - Good Enough is Good Enough

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.

Bio
Author of "Python in a Nutshell", co-author of "Python Cookbook", PSF Fellow, frequent speaker at Python conferences, prolific contributor to StackOverflow, and winner of the 2006 Frank Willison Memorial Award for contributions to Python, Alex currently leads "1:many tech support" for Google Cloud Platform. He's married to Anna Ravenscroft, his co-author in the "Cookbook" 2nd edition and "Nutshell" 3rd edition, also a PSF Fellow, and also a winner of the Frank Willison Memorial Award, in 2013.

https://youtu.be/_Ek3A2b-nHU

Transcript

1. ©2016 Google -- aleax@google.com "Good Enough" IS
   Good Enough!
   http://www.aleax.it/pybay16_geige.pdf 1
2. This talk's "level" 2 Shu Ha Ri ("Learn") ("Detach") ("Transcend") 2
3. Some Cultural Assumptions...: everybody should always be striving for perfection at all times! settling for a software release that's anywhere below "perfect!" is thus a most regrettable compromise. do you mostly agree with these...? OR...: keep-it-simple, just-good-enough launch early, launch often! get plenty feedback & LISTEN to it iteratively improve, enhance, refactor... 3 3
4. "Worse is Better" Richard Gabriel, 1989, a Lisp conference "New Jersey" approach, AKA "WiB" vs "MIT/Stanford" approach, AKA "The Right Thing" years of debate afterwards (plenty of it by RG, sometimes as "Nickieben Bourbaki")... on BOTH sides of the issue!-) 4 4
5. All agree on what's good...: simplicity correctness consistency completeness ...but there are important differences in...: - exact definitions and nuances - priorities 5 5
6. Worse-is-better (e.g: Unix) simplicity implementation (esp!) AND interface most important consideration in design correctness (slightly) better be simple than correct consistency "not overly inconsistent" completeness can be sacrificed to any of the top 3 MUST be, if simplicity's threatened 6 6
7. "The Right Thing" ("MIT") simplicity esp. interface correctness absolute-must, top priority consistency just as important as correctness completeness roughly as important as simplicity 7 7
8. Quoting RG himself...: The right-thing philosophy is based on letting the experts do their expert thing all the way to the end before users get their hands on it. Worse-is-better takes advantage of the natural advantages of incremental development. Incremental improvement satisfies some human needs... 8 8
9. G.K. Chesterton Anything worth doing... ...is worth doing badly! 9 9
10. Note to fontly critics 10 The proportional font I use is Apple Chalkboard, which is NOT MS Comic Sans :-) 10
11. Cathedral, Bazaar...? Eric Raymond, 1997 focus: two diverging models of
    software development Cathedral: close to RG's
    "right-thing" MIT/Stanford experts in charge Bazaar: chaotic, launch-and-
    iterate NJ-like models -- crowd in charge The core Bazaar idea: "given enough eyeballs, all bugs are shallow" 11 11
12. BUGS?! I don't DO bugs! my very first program ever WAS bug-free 1974: 3 freshmen HW design majors and a Fortran program to compute conditional probabilities of suit-division in bridge we had to punch it into punched cards we got one-&-only-one chance to run it...! it ran perfectly that first-and-only-time...! ...never ever happened again in my life. ...don't count on it, buddy...!-) 12 12
13. "Perfection" -> BDUF If you want to only release "Perfection", you clearly need "Big Design Up Front" everything must proceed top-down, perfect identification of requirements, begets perfect architecture, begets perfect design, begets perfect implementations, (it takes...) forever and ever, A-MEN! alas! real life doesn't tend to co-operate... stakeholders resent the "forever" part!-) 13 13
14. BDUF vs the real world requirements change all the time you ain't ever gonna nail them perfectly! architecture varies with design choices design varies with implementation techs implementation _always_ has some bugs only discovered in real-world deployment --> • ITERATIVE development's the only way to go! • deploy SOMEthing, fix bugs, improve, ... • solve SOME user problems, win mindshare 14 14
15. Backwards Incompatibility ...is your FRIEND!-) if you're constrained to remain backwards compatible forever, early-stage design errors drag you down "good enough" IS good enough, IFF... ...you can make it better later! e.g: raise 'some string' now raises TypeError instead (since Python 2.6) 15 15
16. "Perfect": verb, ¬adjective! perfecting your work is great keep doing it -- based on real data! perfection is a process, NOT a state you never "reach" it goalposts keep shifting no laurels to rest on! 16 16
17. What not to skimp on light-weight, agile process and its steps revision control, code reviews, testing... proper release-engineering practices code style, clarity, elegance documentation 17 no cowboy coding! 17
18. Must be in from the start security, in the most general sense, incl.: privacy auditability many other things would be `best` to have at the start, BUT you CAN refactor later...: modularity, `plug-ins` an API scalability you CAN incur technical debt, _with care_ but, DO plan "repayment" as you go! 18 18
19. Recoverable or not? focus on avoiding potential errors that could cause irrecoverable losses as long as one can/does recover, it's OK... ...in a `beta`, at least!-) is the reputational damage to yourself recoverable...? it depends! but, usually, YES esp. w courteous, speedy response to issues that get reported (=="service") "get it right the 2nd time" is usually OK 19 19
20. Customer service secret "Customers with the highest levels of satisfaction tend to be those who have had a problem resolved" -- even better than those who never had any problem at all! it's the "Service Recovery Paradox" http:/ /jsr.sagepub.com/content/ 10/1/60.abstract 20 20
21. General vs ad-hoc solution intuition may tell us ad-hoc easier, faster reality: sometimes, but NOT always (DRY!) 21 def find_by_col(root, color): if root.color == color: yield root yield from (find_by_col(c, color) for c in root.cs) def find_by_sha(root, shape): if root.shape == shape: yield root yield from (find_by_sha(c, shape) for c in root.cs) vs def find(root, n, v): if getattr(root, n) == v: yield root yield from (find(c, n, v) for c in root.cs) 21
22. WIB vs TRT: programming 22 22
23. TCP/IP vs ISO/OSI rough consensus... ...and RUNNING CODE
    (David Clark: MIT, but...
    IETF front and center!) 23 23
24. Xanadu vs the WWW 24 Perfect, ideal hypertext Hackish, incrementally improved hypertext Guess which one conquered the world...?-) 24
25. Intr syscall: ITS vs Unix MIT AI Lab's ITS: every long-running syscall needs to be quasi-atomic AND interruptible... so: every syscall must be able to...: unwind state changes at ANY point resume user-mode for intr. service restart kernel-mode syscall code again early Unix: errno←EINTR, return -1 -- that's it!-) 25 25
26. Metaclass vs Decorator class Meta(type): def __new__(m, n, b, d): cls = type.__new__(m, n, b, d) cls.foo = 'bar' return cls class X: __metaclass__ = Meta def Deco(cls): cls.foo = 'bar' return cls @Deco class Y(object): pass 26 ...vs... 26
27. Python incrementals sorting once: alist.sort(cmp=...) always in-place; slow; a bit cumbersome then: DSU x=[(k(a),a) for a in alist] x.sort(); alist[:] = x now: alist.sort(key=k); sorted(alist, key=k) generators: once yield-only, now w/`send` finalization: once try-finally, now `with` 27 27
28. WIB vs TRT: other fields 28 Bleep 28
29. Good enough never is (or is it?) Eric Ries, http:/ /www.linkedin.com/today/ post/article/20121008194203-2157554-good- enough-never-is-or-is-it "Lean Startups" use the "middle way" to...: minimum viable product: that version of a new product which allows a team to collect the maximum amount of validated learning with the least effort 37signals' Hansson disagrees: "just build something awesome and ship it";-) 29 29
30. Pick a Perfect Employee...? 30 http:/ /theundercoverrecruiter.com/find- perfect-employee/ : DON'T! you'll delay by months, miss opportunities he/she might not be out there looking! you'd likely be over budget rather: pick a GOOD (not PERFECT!) fit focus on personality & culture match provide TRAINING on missing skills 30
31. Satisficer vs Maximizer 31 Satisficer: 90% is just fine, take it, move on! 80% may be OK (20% of effort: Pareto's Law) Maximizer: 99.99% is NOT 100%, so it's A FAIL! 31
32. the "Oration": the soon-forgotten one... Edward Everett 13,508 words; two hours; reams of paper & then, the "Address": not-so-forgettable... Abraham Lincoln 267 words; two minutes; back-of-envelope "the world will little note, nor long remember what we say here"... but, 150 years later, it sure still DOES!-) Gettysburg Dedication 32 32
33. "Lowering expectations"? NO! our dreams must stay big! BHAG! Rightly traced and well ordered: what of that? / / Speak as they please, what does the mountain care? however: the best way TO those dreams remains "release early, release often" learn from real users' interactions Ah, but a man's reach should exceed his grasp / / Or what's a heaven for? Browning's Andrea del Sarto: less is more! 33 33
34. Q & A www.aleax.it/pybay16_geige.pdf 34 ? ! http:/ /shop.oreilly.com/product/0636920012610.do ebooks, all formats, DRM-free; at checkout: AUTHD 34