Tag Archives: complexity

Lessons on Competition from Mother Nature

An interesting short article by Joel Barker with some ideas to think about, Surviving the Fittest: New Lessons on Competition from Mother Nature:

As a result of this emerging body of research, we now must reexamine our competitive paradigm and factor in the new information. It is now clear that ‘the fittest’ not only don’t win all the time, but are only a piece of the more complex system. This information can lead to new strategies for small companies and new insights for the big companies that presently dominate their industries.

The idea that what is winning right now is best is flawed. What is successful now is dependent on the larger system and the conditions that impact that system. In the news the last few days British Airways had to shut down flights worldwide. This has happened numerous times for major airlines in the last few years.

view from a train in Rocky Mountain National Park with tree and snow covered mountains in the background

By John Hunter, see more of my trip to Rocky Mountain National Park.

The systems that they settled on may seem to be working well for years and then suffer catastrophic failures. Why did they accept systems that could fail so completely? Given the frequency it is happening numerous competitors are choosing solutions that are too fragile. And it isn’t just one organization doing it, numerous huge airlines (United, Delta, British Airways, Southwest) have found themselves caught in a situation where they fail to deliver what customers pay for due to so complete a failure of their IT system that they cannot fly any planes many hours in a row.

I suppose this could be evidence that designing an IT system for a huge airline is not something that can be done with the reliability we expect from most things (that the business doesn’t have a day every decade or two where they business just can’t operate that day). But I doubt it. It seems much more likely the existing system creates organizations that are more focused on other things than building a reliable, robust IT infrastructure.

A post I wrote on my Curious Cat Science and Engineering blog a few years ago, 500 Year Floods, looked at the problem of making judgements about unknown systems. The concept of 100 and 500 year floods is to help us make decisions about long term planning and risks. Looking at an area to build a building (or city) can be aided by history and seeing what the area has experienced in the past. But you can’t just assume the future will be the same as the past. Systems change over time. What worked in the past doesn’t necessarily work well in the future.

And as I mentioned in my article, our evidence and understanding also changes (hopefully by us gaining more knowledge and gaining a clearer understanding as we learn more). Thinking systemically takes into account the impact of interactions on results. Results are not independent of the circumstances.

Continue reading

Statistical Learning as the Ultimate Agile Development Tool by Peter Norvig

Interesting lecture on Statistical Learning as the Ultimate Agile Development Tool by Peter Norvig. The webcast is likely to be of interest to a fairly small segment of readers of this blog. But for geeks it may be interesting. He looks at the advantages of machine learning versus hand programming every case (for example spelling correction).

Google translate does a very good job (for computer based translation) based on machine learning. You can translate any of the pages on this blog into over 30 languages using Google translate (using the widget in the right column).

Via: @seanstickle

Related: Mistakes in Experimental Design and InterpretationDoes the Data Deluge Make the Scientific Method Obsolete?Website DataAn Introduction to Deming’s Management Ideas by Peter Scholtes (webcast)

Pleasing Customers

Why is 37signals so arrogant? (the broken link was removed) by Don Norman

The Brash Boys at 37signals Will Tell You: Keep it Simple, Stupid. Brash is an understatement. I was quoted in the article because of my article arguing that simplicity is highly overrated: the tasks that we do require tools that match the requirements, and these add complexity.

Yes, they are arrogant — and proud of it: “Arrogant is usually something you hurl at somebody as an insult,” Hansson said. “But when I actually looked it up — having an aggravated sense of one’s own importance or abilities’ — I thought, sure.” Park concludes his article by saying “Call it arrogance or idealism, but they would rather fail than adapt. ‘I’m not designing software for other people, ‘Hansson says. ‘I’m designing it for me.’ ” “I’m not designing … for other people.” I think that simple phrase speaks volumes. Thank goodness most companies recognize that this attitude is deadly.

I don’t agree. Not compromising leads to solutions that are unlikely to be all things to all people. But with an intelligent and knowledgeable leader will lead to excellent solutions for those that share desires. Now I don’t think this is the best strategy, especially for growth. But it can be an excellent strategy for startup, innovators and those seeking 1,000 fans.
Continue reading

If Tech Companies Made Sudoku

Topic: Management Improvement

A fun post as we head into the weekend: If Tech Companies Made Sudoku by Kathy Sierra

Frankly, we’re a little baffled that your original design was so… simple. I’m sure we all recognize that our target market demands a much more media-rich, interactive, high-action experience. Love the whole grid thing, though.

The graphic on the original post is great. You can also read about an attempt to focus IT differently: The Declaration of Interdependence [the broken link was removed] by Alistair Cockburn:

Lean manufacturing teaches us that having large inventories is inefficient. It also teaches us that the overall efficiency of a process improves as the batch size passed from stage to stage is reduced. Today this has become accepted in most (but not all) manufacturing circles, yet many people may be surprised that it also applies to software development.

We often seem to add unnecessary complexity to software; creating fragile code that is frustrating to use.