Ones and Zeros

In this post Clay Shirky discusses the collapse of complex business models and Tainter’s book The Collapse of Complex Societies.

…a group of people, through a combination of social organization and environmental luck, finds itself with a surplus of resources. Managing this surplus makes society more complex—agriculture rewards mathematical skill, granaries require new forms of construction, and so on.

Early on, the marginal value of this complexity is positive—each additional bit of complexity more than pays for itself in improved output—but over time, the law of diminishing returns reduces the marginal value, until it disappears completely. At this point, any additional complexity is pure cost.

….

When the value of complexity turns negative, a society plagued by an inability to react remains as complex as ever, right up to the moment where it becomes suddenly and dramatically simpler, which is to say right up to the moment of collapse. Collapse is simply the last remaining method of simplification.

As Shirky points out in his post, the same thing can happen in business.  I believe something similar can happen with any over complex structure such as some software projects.  The FAA famously killed their modernization project in the late 1980’s due to this.  Way back in 1975 Fred Brooks in his book The Mythical Man-Month observed, “Adding people to a late project only makes it later.”  In reference to theoretical physics Einstein said, “Everything should be made as simple as possible, but not simpler.”  Sounds like good advice in general.

The study of failed software projects and systems should be part of our standard training for a software engineer.  In aviation accident analysis is an important area of study and civil engineers also do this.  I’m not the only pilot who’s read years of NTSB reports.  However in software we have nothing similar.  Fred Brooks’s book is a good start; it’s a classic.   But due to corporate embarassement and proprietary property issues, there’s no similar study in software engineering.

This lack forces us individually to replicate all of our predecessors mistakes.  The progress of our field suffers.

Sometimes it’s just one thing after another.  It’s been like that in my coding lately.  I need a plotting/graphic library for an iPhone app I’m writing.  I could write one, but it’s faster if I found one that I could use.  I’d prefer to focus on my app instead of writing a library.  Lo and behold; there was Google’s core-plot for the iPhone.  Wonderful!  Looks like it’s probably quality code and appears well supported.

It was archived under Mercurial source code control system in Google’s code website area.  So I needed Mercurial.  No problem.  I found an install for my Mac, I don’t even need to build from its source.

Ah.  The install doesn’t work.  It hangs and has problems with my Python version.  (Mercurial is very Python dependent, much of it is written in Python with a few native extensions.)  So I’ll install the necessary Python version.  But it still doesn’t install.  Several experiments (and days) later I decide to build from source.

Hm.  That doesn’t work either.  I start tracing and fixing problems: wrong SDK, wrong gcc version.  Of course the build process isn’t in an old-fashioned Makefile that everyone knows, but a new (to me at least) Python build process.  That means two things to learn: the build process and the Mercurial build.

Remember core-plot?  That’s what the goal is.  Actually, the goal is my app.

I’ll spare you the details of the more days working out the problems, downloading the correction older SDK and gcc and working it all out.  I finally was able to execute the one command to get the core-plot source locally on my machine.  I think some inconsistencies in my system installation with Python and the SDK/gcc version issues threw off the Mercurial build/install process.  It’s designed for an older system release than I have.

This is one reason that software development can take longer than expected.  There’s always some “little” problem that becomes another problems and so on.  This one’s resolved, but there will be others. I try to be positive and consider it job security.

From this article:

 Jon Kyl (R-Az) told Fox News’ Chris Wallace that Republicans are prepared to fight a nominee who might stick up for the little guy, a position he called “overly ideological.”

I’m just glad that Kyl wasn’t around during the American revolution.  He would have been a Tory, ie pro-King and against all those little guy revolutionaries.  I’m sure he’d think that stuff about “governments are instituted among men, deriving their just powers from the consent of the governed” is just so much nonsense.

Our five-year-old Prius has a problem with it’s battery.  There are actually two batteries in the Prius; the large 230V battery used to power the electric motor as part of the hybrid drive and the regular 12V battery used to kick over the starter and power the accessories.  This battery is charged from the bigger battery through an voltage shifting circuit.

If the 12V auxillary battery doesn’t hold a charge, then the accessories don’t work.  Five years is about the life of that battery, so I’m not surprised that it’s gone now.  Unfortunately, one “accessory” is the electronics to detect the key and start the hybrid engine.   I don’t like that single point of failure, it’s bad design.

Another design problem is the location of this 12V battery.  It’s under the trunk floor on the right side.  Now if I can’t use the accesories, I can’t open the hatch at the back.  I have to  go in through the side door, flip down the seats, remove the truck cover, remove the trunk floor and anything stored in that area (all through the side door).  Then I have to work in the small space to unbolt the hold ons and connections to that battery and lift it up and out of the space provided.  All this makes a five-minute job into an hour or more.

While I’m generally pretty happy with the Prius they didn’t do well here.