Many companies that have trouble delivering software on time exhibit a common pathology. Developers working on the next release are frequently interrupted for production support issues with the current release. These interrupts never appear in project schedules but can take up half of the developers' hours. When you include the cost of task-switching, this means less than half of their available time is spent on the new feature work. Invariably, when I see a lot of developer effort in production support I also find an unreliable QA environment.

What does a philosopher born in the 19th Century have to say about software design? More than you might think, particularly his ideas about family resemblance. Wittgenstein used the subject of "games" to illustrate an idea. We'll start with a counter-example. Suppose we operate with the then-prevailing notion that words are defined like sets in axiomatic set theory. Then there is a decision procedure that will let us decide whether something is a member of the set "

If you help other people solve problems, you may have run into this phenomenon: a person gleefully tells you how messed up their environment is. Processes make no sense, roadblocks are everywhere, and all previous attempts to make things better have failed. As you explore the details, you talk about directions to try. But every suggestion is met with an explanation of why it won't work. I say that these folks are "

CRC I find the old object-oriented design technique of CRC Cards to be useful when defining service designs. CRC is short for "Class, Responsibilities, Collaborators." It's a way to define what behavior belongs inside a service and what behavior it should delegate to other services. Simulating a system via CRC is a good exercise for a group. Each person takes a CRC card and plays the role of that service.

My daily language is Clojure. One of the joys of working in Clojure is its great core library. The core library has a wealth of functions that apply broadly across data structures. A typical function looks like this: (defn nthnext "Returns the nth next of coll, (seq coll) when n is 0." {:added "1.0" :static true} [coll n] (loop [n n xs (seq coll)] (if (and xs (pos? n)) (recur (dec n) (next xs)) xs))) I want to call your attention to two specific forms.

While reading Bryan Cantrill's slides from Papers We Love NYC, I was struck by something. One of the very first slides says: The traditional UNIX security model is simple but inexpressive. The papers go on to describe a progression of techniques to isolate processes from the host environment to greater and greater degrees. It began with the ancient precursor 'chroot', through Jails, and Zones. Each builds upon the previous work to improve the degree of isolation.

Please understand, dear Reader, that I write this with positive intention. I'm not here to impugn any person or organization. I want to talk about some decisions and their natural consequences. These consequences seem negative to me and after reading this post you may agree. When an established company faced a technology innovation, they often create a new team to adopt and exploit that innovation. During my career, I've seen this pattern play out with microcomputers, client/server architecture, open systems, web development, agile development, cloud architecture, NoSQL, and DevOps.

Here's a syllogism for you: Every technical review process is a queue Queues are evil Therefore, every review process is evil Nobody likes a review process. Teams who have to go through the review look for any way to dodge it. The reviewers inevitably delegate the task downward and downward. The only reason we ever create a review process is because we think someone else is going to feed us a bunch of garbage.

Every single person I've heard talk about Continuous Delivery says you have to change your system's architecture to succeed with it. Despite that, we keep seeing "lift and shift" efforts. So I was happy to be invited to join a panel to discuss architecture for Continuous Delivery. We had an online discussion last Tuesday on the C9D9 series, hosted by Electric Cloud. They made the recording available immediately after the panel, along with a shiny new embed code.

During this morning's drive, I crossed several small overpasses. It reminded me that the American Society of Civil Engineers rated more than 20% of our bridges as structurally deficient or functionally obsolete. That got me to thinking about how we even know how many bridges there are in a country as large as the U.S. Some time in the past, it would require an army of people to go survey all the roads, looking for bridges and adding them to a ledger.