Improving Wetware

Because technology is never the issue

Software Development, Planning and Timescales

Posted by Pete McBreen Fri, 28 May 2010 01:48:00 GMT

In Fast or Secure Software Development Jim Bird points out that many software organizations are going down the road of releasing the software very frequently.

Some people are going so far as to eliminate review gates and release overhead as waste: “iterations are muda”. The idea of Continuous Deployment takes this to the extreme: developers push software changes and fixes out immediately to production, with all the good and bad that you would expect from doing this.

There is a growing gap between these ‘Agile Approaches’ and mission critical software that has to be secure. Jim highlights many aspects of it in his article, but there is another wider aspect to consider.

Humans are bad at planning for the long term

The really bad news with this is that in this context the long term can be days or weeks, but as a society we need to be planning in terms of lifetimes.

For ‘Agile Approaches’ it makes sense to automate the release process so that it is easy to do with minimal impact. There are lots of technologies that help us achieve painless releases, and most of them are useful and effective. But just because we have a tool does not mean we should rely on it. As Jim points out, the frequent release mantra is based on the idea that it is easy to see if a release is broken, but it’s not always that simple. Security problems don’t show up like that, they show up later as successful exploits and attacks and bad press.

Some problems require careful planning, appropriate investment and preparation. One domain I am familiar with — credit card processing — has been fraught with problems because developers have not dealt with all of the corner cases that make software development so interesting and painful. Reportedly there have been exploits from server logs that included the http post parameters, which just so happened to be credit card numbers. Of course no organization will repeat any of the known mistakes — but without the long term focus on planning, investment and preparation that mission critical software requires, some other problem is bound to occur.

Failing to address the long term

Several years ago now, the Club of Rome study on the Limits to Growth was met with disbelief in most quarters, but less than half lifetime later we are hitting up against the limits that were identified back then. Peak Oil, Climate Change and the current financial meltdown are all related to these limits. Admittedly we are not good at dealing with exponentials, but reality has a way of making sure we cannot forget them. As the demand for oil reached the existing supply levels, the lack of successful investment in other supplies or alternatives meant that many economies crunched when we got near to peak oil supply volumes.

To think, a relatively simplistic computer model from nearly 40 years ago was able to produce a crude simulation of where we are now. Yes, many details were wrong, and the actual dates they were predicting were out, but what they were predicting was inevitable without policy changes and we failed to make the necessary changes. It was always easier to just keep on doing what we have been doing until suddenly oil is over US$100/barrel and then suddenly we act all surprised and horrified about the price of everything.

Software is Infrastructure

Software lasts a long time unless you make really bad mistakes, so we need to start treating it as infrastructure. But not like we are treating our current physical infrastructure. It is nice to be able to release software easily with minimal impact and costs, but we need to make sure that in doing so we are not exposing ourselves to longer term pain. Yes, make it easy to release, but only release when you know through intense and rigorous evaluation that what you release is better than what you have out there already.

Core systems do not get replaced quickly. Our 32 bit IP addresses are starting to hurt, but rolling out IP6 is a slow process. Just like our roads and bridges we have patched the existing system up lots of times, but it needs to be replaced and soon. Unfortunately, just like our roads and bridges, the necessary investment is daunting and we still want to put it off as long as possible.

As we enter the post cheap energy era, we need to reevaluate our planning horizon. We need to rediscover how to plan for the long term. Somehow or other, forty years after NASA put a man on the moon, NASA is now reduced to hitching rides with the Russian Space Program …

Understanding large numbers

Posted by Pete McBreen Sun, 16 May 2010 19:52:00 GMT

While reading Eaarth I came across an number that needed further thought. Supposedly a barrel of oil contains as much energy as a man working can put out in 11 years.

OK, so that needs some cross checking. A barrel of oil is 42 US gallons, or 158.987 liters (used to link to a Thailand website that was near the top of the google search for that conversion, now linking to wikipedia). That barrel of oil has about 6.1 GJ or 1,700 kWh, or 38 MJ per liter. roughly 10.5 kWh.

Maximum sustained energy that a human can put out is around 100W over an 8 hour period, so 0.8kWh/day, but that would be classed as extremely hard labor, so a better number to use would be about half that, so a good estimate would be 0.5kWh/day. Allowing for 250 working days/year, that means a strong, fit human can put out about 125kWh/year.

Comparing this to the 1,700kWh per barrel of oil, a human capable of a sustained output of 50W would take about 13.6 years to generate that much energy, so the figure of 11 years energy per barrel is reasonable. Other numbers in Eaarth suggest that in North America, the annual consumption of oil per person is about 60 barrels, so in a year, a human uses the equivalent of 660 humans worth of work.

Since that is hard to imagine, a smaller scale to look at it is that 1 liter of oil, enough to drive a car for maybe 15 km or 10 miles (assuming an efficient car), uses as much energy as an average human could put out in a month of working 8 hours a day, 5 days a week. (21 days work at 0.5kWh/day for the 10.5kWh in a liter of oil).

Small wonder then that the thoughts of Peak Oil and Global Warming from excess CO2 have everyone concerned in one way or another…

Fossil ignores files by default

Posted by Pete McBreen Sun, 16 May 2010 03:31:00 GMT

One difference between fossil and the other version control tools I use (git and svn) is that by default it ignores files that are not in the repository. So rather than having to set up a .gitignore to have it ignore stuff, fossil does that automatically

fossil status

To see the other files, you need to look for the extra files

fossil extra

And the really nice thing about extra, is that it does not matter where you are in the project directory structure when you issue the command, it searches the entire local-root looking for the unexpected files. This also means that fossil has a way of cleaning out any unwanted temporary files:

fossil clean

Clean prompts you to confirm every delete, so it is safe to run, but it is a nice feature when the tools you are using generate a lot of temporary or intermediate files as part of their processing.

Moving to Fossil

Posted by Pete McBreen Sat, 15 May 2010 17:23:00 GMT

After a few years of using Git as my version control system, it is now time to move on to a distributed version control system that is more suited to projects with a smaller number of contributors Fossil.

Main advantage I see that fossil has over git is the ease of setup for remote servers. A 2 line cgi script is sufficient for fossil to operate as a server over http. Git has something similar, but after several years of using git setting it up on a server is still not an easy task, which is why many people choose to use a service like Github or Gitorious. But the existence of these services points to a problem, why choose to use a distributed version control system and then adopt a centralized hosting service to use it. Surely the point of using a distributed system is to make it distributed — but we have created a system where the key repositories are all stored in a central place with a single point of failure.

Yes, I know that with a distributed version control system the clones have all the information that the original has, but the concept of centralizing the infrastructure seems strange to me. I much prefer the ease with which I can create a new fossil repository and then get it served out from an available web server relatively easily. Admittedly fossil does not integrate with any other identity management system, so the creator of the fossil repository has to manage the users (other than the anonymous user), but for small teams this is not an issue.

The other key feature for me is the autosynchronize on commit, so whenever a local commit is made, the changes are pushed to the original repository. Automatic, offsite backup without having to remember to do anything beyond the normal checkin of completed work.

Worst Case Thinking leads to bad decisions

Posted by Pete McBreen Fri, 14 May 2010 00:05:00 GMT

Bruce Schneier on worst case thinking

Worst-case thinking means generally bad decision making for several reasons. First, it’s only half of the cost-benefit equation. Every decision has costs and benefits, risks and rewards. By speculating about what can possibly go wrong, and then acting as if that is likely to happen, worst-case thinking focuses only on the extreme but improbable risks and does a poor job at assessing outcomes.

Bruce covers the idea in depth, but for me the problem with worst case thinking is that is can be used to justify doing nothing. By focusing purely on the extreme possible downside it forgets the value of the benefits, AND forgets that doing nothing also has a cost.

Zed Shaw and Learning Python The Hard Way

Posted by Pete McBreen Sun, 09 May 2010 22:57:00 GMT

Zed has started an interesting experiment on Learning Python the Hard Way.

Looks to be an effective approach to learning Python, but I’m more intrigued by the tools used. From a set of text files in a fossil repository there is a make file that builds the complete book as a PDF file. Seems like it could be something I could use for other projects, the only awkward bit about it being the size of the TeX installation needed to support the pdflatex generation process.

Fun with XHTML

Posted by Pete McBreen Sun, 09 May 2010 20:01:00 GMT

I’ve been looking at XHTML specifications recently and was surprised at the number of special symbols that are defined.

From simple things like ¬ ¬ and © © — to much more esoteric ones like ƒ ƒ. I can see the need for them, but the sheer number means that unless you use them all the time there will be the need to look them up.

I like the math set though, forall ∀ part ∂ exist ∃ empty ∅ nabla ∇ even if I have never had much use for these outside of math and logic classes. Similarly the arrows are nice harr ↔ looks neat, but not something I use a lot.

Overall there are some useful symbols in XHTML, and it sure beats trying to remember the key code to type them. After all brvbar ¦ is easier to type than trying to find the broken pipe symbol on the keyboard. sect § and macr ¯ could also be useful when annotating documents.