Software Design

A friend of mine recently sent me a link to an interesting article "Not Your Father's Von Neumann Machine: A Crash Course in Modern Hardware".

One of the interesting elements discussed in this article is the relative cost of memory access. An access satisfied from L1 cache (closest to the processor) might take just 3 clock cycles, but an access requiring access to main memory might take 200 clock cycles.

That's a massive difference in performance.

Saw an interesting question on StackOverflow today: Polymorphism - Define In Just Two Sentences

Reading the answers, it seemed to me that everyone was getting bogged down in the technical aspects, and was missing the essential point of the term.

Despite the growing maturity of our industry, there are some mistakes that seem to be repeated by each new generation of developers.

We have good technical standards for how we document our information structure – from good old Entity-Relationship diagrams through to the UML. There are even some attempts to provide general guidance on information modelling – the Nebulon Archetypes aka Colour Modelling are one good example – but in too many ways the lessons learnt by one generation of modellers are left for the next to learn anew.

I have a draft post explaining the Single Responsibility Principle that I've been working on for the last couple of months. I've just never been able to find a simple way to explain it that's not open to misinterpretation.

I'm going to have to junk that post completely, because it's now obsolete.

Check out this explanation, put together by Brent Brown and posted by Jarod Ferguson:

Brilliant!

This morning I discovered that our StarTeam server was being uncooperative – refusing to accept check-ins because of a lack of available storage space.

Users were receiving this message:

A quick look at the appropriate network share revealed plenty of space – while the hives were configured to use up to 99% of the available space, the share was only 86% full.

Weirdness.

Delving into the log file, I found this message (formatted for this post):

The premise that systems should "fail fast" is pretty well established - the idea has it's own wikipedia page, and any number of books talk about it as a fundamental premise.

For example, Release It! from the Pragmatic Bookshelf makes several references to Fail Fast in Chapter 5: Stability patterns.