Archive for the ‘Overlooked Resources’ Category

James Mickens: Life as a Developer

Wednesday, January 31st, 2018

Below is a somewhat whimsical talk given by James Mickens last year titled Life as a Developer: My Code Does Not Work Because I am a Victim of Complex Societal Factors That are Beyond My Control.

(If you recall, Mickens is the guy who did the insane/awesome Monitorama talk about the cloud a few years ago.)

As usual for dear begoateed James it is full of silly digressions, but the theme is quite an important one today: unnecessary complexity is increasing and that trend will conspire with our own limited capacity for comprehension, information retention, research of the new and obscure, and interpersonal communication to ensure that if we keep going as we are the whole world will eventually succumb to entropy and leave us in a big ball of digital hellfire.

Life As A Developer: My Code Does Not Work Because I Am A Victim Of Complex Societal Factors That Are Beyond My Control…. from NDC Conferences on Vimeo.

Rich Hickey: Simple Made Easy

Tuesday, December 8th, 2015

This is an excellent presentation of the “soft tech talk” type given by Rich Hickey about the difference between a thing being “easy” in the sense that it is near to our experience and it actually being “simple” in the sense that understanding the idea does not force us to understand a lot of other ideas that are partially folded into it. His point is that we should be careful about the way we use the words “easy” and “simple” and be rather more specific than we tend to be, because this hides up a rather large and common class of complexity problems that we tend to gloss over within programmer society because we are merely familiar with a huge class of unnecessarily complicated constructs that have nothing to do with the business problems we are supposed to be solving.

Rich Hickey: Simple Made Easy

If only it were glaringly obvious to us when we were engaging in the glossing-over of non-essential complexity in architecture. I suppose one way of at least trying to become conscious of this is the frequency of use of a certain alarm-bell phrase: “just”. Ward Cunningham’s wiki actually has a whole page on it, along with another page that enumerates and discusses/argues a few other linguistic red flags of note.

Fred Brooks: Design Requirements

Sunday, August 19th, 2012

This overlooked resource is a talk that Fred Brooks gave to a very small audience June 4, 2007 — the first day of the WSOM Design Requirements Workshop. He does not discuss requirements or elicitation of requirements (which is what everybody else talked about) but rather discusses design as a process and how that is inseparable from the process of divining requirements. His primary points are:

  • You can’t know what you want to build until you already have something concrete. Everything is a throw-away until it is “good enough”.
  • Since you can’t know what you want to build, you don’t know the requirements, even after you start work. This indicates that the process of design and the process of divining requirements cannot be treated separately the way that academic literature treats the subjects.
  • The design process sometimes occurs in a more complex environment than in past years because of the late 20th century concept of “collaborative design”. Further, this is not the best design model for every project.

Unlike many other Fred Brooks talks there is a bit of audience interruption — sometimes with valid points, sometimes not — and you can observe both Fred’s unscripted response as well as others in the audience responding to audience comments and questions. It is interesting from a human perspective for this reason as well.