Joel Spolsky’s writing and opinions are evergreen, and his 2004 book The Best of Software Writing shows it. I’ve always been jealous of Joel Spolsky for being right all the damn time. His selection of articles for “The Best of Software Writing Volume I” shows off how prescient he constantly is. This book collects writings from 2003 and 2004, and almost every one could have been written today and be immediately relevant. ...
A 1984 paper that models the time it takes to complete a project, and shows what happens when you are up against bad deadlines. The answer will not surprise you! I love seeing software development modeled as an equation, and this paper gives a great one. Time = ( work_to_software + work_towards_planning ) / ( productivity_per_person * people ) This list comes with a half dozen caveats, all on how these numbers are not independent. ...
All of this comes from reading everything in Martin Fowler’s https://www.martinfowler.com/microservices/, and many of its linked articles. Core reading Microservices https://www.martinfowler.com/articles/microservices.html Microservice architectural style: building applications as suites of services Amazon has the idea of a Two Pizza Team - a team should be feedable by two pizzas Smart Endpoints Dumb Pipes - There is no smart choreography of messages or central busses, just straight service calls over http or something similarly simple. At most, there are message queue services (e.g. rabbitmq). ...
excerpt from How Complex Systems Fail 15) Views of ‘cause’ limit the effectiveness of defenses against future events. Post-accident remedies for “human error” are usually predicated on obstructing activities that can “cause” accidents. These end-of-the chain measures do little to reduce the likelihood of further accidents. In fact that likelihood of an identical accident is already extraordinarily low because the pattern of latent failures changes constantly. Instead of increasing safety, post-accident remedies usually increase the coupling and complexity of the system. This increases the potential number of latent failures and also makes the detection and blocking of accident trajectories more difficult. ...
For my own reference, here are notes I took while reading Google’s book on SRE. Site Reliability Engineering - Edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy Chapter 7 has great stories about the growth and setbacks of automation at Google. http://landing.google.com/sre/book/chapters/automation-at-google.html Chapter 13 has stories of emergencies. My favorite involved a disk erasing system which used 0 to mean “all”. http://landing.google.com/sre/book/chapters/emergency-response.html They namedrop Perl. Jeez. All bug-fixes are cherry-picked to go into the mainline. ...
If you’re responsible for a large, legacy code base, here’s my hint to you: delete your failing tests. Good code bases have a large suite of unit tests, probably around 80% coverage, that are run automatically by integration scripts. Getting to this is step one. Step two is managing those tests, and the most important job now is to make sure they aren’t failing. Unfortunately, in any large code base, failing tests are everywhere. ...
A small trick to make “before” a bit more powerful, a bit more useful, and a bit more dangerous. In Moose, the “before” and “after” method modifiers normally don’t affect the method they are modifying. But I’ve always wished that I could. Specifically, I wish “before” could take in and modify the parameters, and “after” could take in and modify the return value. Today I learned that I can partially get my wish. ...
Eric Brewer and Daniel Abadi expand our notions of what the real trade-offs are in the CAP theorem. Flexible positioning between C and A Eric Brewer discusses the range of options available under CAP in “CAP Twelve Years Later: How the “Rules” Have Changed”. In particular, he notes that designers don’t have to pick exclusively between AP or CP, but can choose a range of flexible options between the two, including limiting operations during a partition to just certain, inviolable operations that will maintain invariants. ...
A scientist’s idea of literary criticism is different from most people’s. It involves math. Prof. Alan Kaminsky graphs and predicts the size of Harry Potter books in “Harry Potter Book Sizes” . He notes that the books were initially growing exponentially. (I thought they were growing in Fibonacci scale, just by eyeballing the heights of each hardcover.) If his prediction had held, the last book should have been just over 7000 pages. Which would not qualify it as the longest book ever. In fact, it would only be number four. ...
Chuck Jones inspires UI designers in this classic paper from Ungar and Chang. Another paper about the SELF programming language, this time on its interface, “Animation: From Cartoon to the User Interface” by Bay-Wei Chang and David Ungar. Chang and Ungar take lessons from traditional animation to inform the design of their own GUI. It opens with the observation that animators work with 24 frames per second, and the audience is never confused from frame to frame, but even the simplest GUI can trip users up when things change unexpectedly. The solution, of course, is to buy the ACME Web Development Framework. No, wait… The solution is to steal a few simple lessons from hand-drawn animation to make a GUI more intuitive. Everything from bouncing at the end of a move, to motion blur when an object moves more than its size in a single frame, to using non-linear easing. ...