Monthly Archives: July 2014

Quote

Posted on by

The thing I treasure about science fiction is its utility as a toolkit for thinking about the relationship between technological change and human beings. This is why I value “design fiction” so much: an architect might make a visualization that flies you through her as-yet-unbuilt building, an engineer might build a prototype to show you what he’s thinking of inventing, but through design fiction, a writer can take you on a tour of how a person living with that technology might feel. That’s the kind of contribution to the discussion about which technology we should make, and how we should use it, that can make all the difference.

Cory Doctorow, at Locus Online, on “Cold Equations and Moral Hazard”. Read it.

“Distributed big balls of mud”

Posted on by

Read Simon Brown’s post about how microservices are not the Silver Bullet some are promoting them to be.  As always, pick the right tool for the problem *and* for who will be solving it (the team and organization matters!!!). Sometimes, yes, that’s microservices. Sometimes it’s not. Pick your poison, but do so with open eyes and a level of clarity.

 

Quote

Posted on by

Consider a system to be made up of procedures, some of which are stateful and others which aren’t. We have already discussed the difficulties of understanding the bits which are stateful, but what we would hope is that the procedures which aren’t themselves stateful would be more easy to comprehend. Alas, this is largely not the case. If the procedure in question (which is itself stateless) makes use of any other procedure which is stateful — even indirectly — then all bets are off, our procedure becomes contaminated and we can only understand it in the context of state. If we try to do anything else we will again run the risk of all the classic state- derived problems discussed above. As has been said, the problem with state is that “when you let the nose of the camel into the tent, the rest of him tends to follow”.

As a result of all the above reasons it is our belief that the single biggest remaining cause of complexity in most contemporary large systems is state, and the more we can do to limit and manage state, the better.

“Out of the Tar Pit”, Ben Moseley and Peter Marks, 2006

Quote

Posted on by

The means by which we live are marvelous indeed. And yet something is missing. We have learned to fly the air like birds and swim the sea like fish, but we have not learned the simple art of living together as brothers.

King Jr, Martin Luther (2012-11-06). A Gift of Love: Sermons from Strength to Love and Other Preachings (King Legacy) (pp. 76-77). Beacon Press. Kindle Edition.

Quote

Posted on by

The “software crisis” was first identified in 1968 and in the intervening decades has deepened rather than abated. The biggest problem in the development and maintenance of large-scale software systems is complexity — large systems are hard to understand. We believe that the major contributor to this complexity in many systems is the handling of state and the burden that this adds when trying to analyse and reason about the system. Other closely related contributors are code volume, and explicit concern with the flow of control through the system.

“Out of the Tar Pit”, Ben Moseley and Peter Marks, 2006

Quote

Posted on by

Only through the bringing together of head and heart— intelligence and goodness— shall man rise to a fulfillment of his true nature. Neither is this to say that one must be a philosopher or a possessor of extensive academic training before he can achieve the good life. I know many people of limited formal training who have amazing intelligence and foresight. The call for intelligence is a call for openmindedness, sound judgment, and love for truth. It is a call for men to rise above the stagnation of closedmindedness and the paralysis of gullibility.

King Jr, Martin Luther (2012-11-06). A Gift of Love: Sermons from Strength to Love and Other Preachings (King Legacy) (p. 43). Beacon Press. Kindle Edition.