2013's most read posts

This time of year, we're all very busy honoring traditions. This post is no exception (2009, 2010, 2011, 2012).

Today was probably the first time this year that I took some time to study my blog's Google Analytics metrics. If I keep last year's black swan posts out of the equation, traffic seems to be comparable to last year's. The most meaningful metrics to me are the number of subscriptions and the average time spent reading. Both of them increased - happy about that!

The actor model has been gaining in popularity more and more. Next to addressing more infrastructural concerns, it can also be used as a framework for modeling and reasoning about complex systems. Working with a team of mainframe programmers over the last year, I observed a few similarities in how they have been designing their systems. Actor Model in COBOL is the third most read post of 2013.

The second most read post was Not handling edge cases, making them explicit instead. Inspired by a talk with Greg Young at DDDX, I tried to create a narrative that uncovered an edge case in a green field project. Instead of handling the edge case, we use an event to make it explicit, allowing a human to intervene. This way we can go to market more quickly, with less code, and we might even end up with happier customers.

Number one is But I already wrote it. In this post I shared my motivation having an argument with a colleague about whether to dump some code that did too much. Don't cherish your code. It's nothing but a means to an end; the side product of creating a solution. Aim for simple and lean solutions; nobody likes bulky software, nobody likes fighting complexity all day. Don't neglect the hidden cost of that extra small feature you're throwing in.

Thank you for reading!

Databases are growing on me

I learned all about logical design of relational databases back in school; tables, columns, data types, views, normalization, constraints, primary keys, foreign keys... At the same time, I learned how to use SQL to put data in, and how to get it out again; INSERT INTO, SELECT, FROM, WHERE, JOIN, GROUP...

In the first project I worked on just out of school, we weren't doing anything interesting with databases; we didn't have that many users, or that much data. A database veteran on the team took it on him to maintain the schema and to provide stored procedures we could do work with.

All that time, I consciously was very ignorant of the database. I had no idea what was in the box, and I didn't care either; databases were boring, applications were where the fun was at.

Since then, I have rarely worked with a team that had a dedicated role for database design. Why invest in another person when you can do without? Database basics are not rocket science; with 20% of the knowledge, you get very far. Definitely now that it's probably easier and cheaper to throw hardware at the problem.

That being said, it's a good idea to keep a DBA close. Time and time again I see them only being called in when it's too late and much needed improvements are often too far-reaching and expensive. No wonder DBA's are grumpy all the time.

Being exposed to databases more and more, I got to pick up a few things here and there - mostly cargo-cult best practices. It wasn't until last year that I got really curious for what was in the box. Working on an application with a decent amount of data crunching for a year forced me to open up the lid. Also my ventures in NoSQL land, overhearing discussions on Twitter between kellabyte, ayende, gregyoung, pbailis and others had much to do with it.

On opening the lid, I found a lot more than I expected. It had never occurred to me how much interesting problems databases have to solve. Making a database execute a query and see results returned in milliseconds only looks easy on the surface. Memory, disk, CPU, caching, networking, protocols, concurrency, fault tolerance, data structures, transactions, compilation... it's all in there.

The book Physical Database Design and the SQLite technical documentation were the first good reads that helped me understand what was going on closer to the metal. From there, I now try reading a paper (or a reference) from the Readings in Database Systems collection once in a while. This collection of papers is supposed to contain the most important papers in database research. Maybe academic, but delicious brain food nonetheless - stretching my mind in ways I'm not used to.

Buildstuff 2013

Last night, I returned from Vilnius, after seven intensive days of Buildstuff. After a few long months, I was looking forward to be influenced and inspired by concepts and experiences strange to my day-to-day job - surrounded by people hungry to build better software. Because of the diversity of the program, the high level of the speakers and the presence of some familiar DDD-community faces, my expectations were easily met. Also, the location and low rates for tickets, transport and beer make it a very reasonable investment.

I expect the videos to be uploaded over the next few weeks and thus I will not bore you with session summaries. Instead I picked out some quotes which stood out for me in one way or the other; because they were spot on, summarize a concept in just a few words, or because they challenge me and give me food for thought.

Hope to see you again next year, Buildstuff.

Bertrand Meyer

Code contracts help generating tests. Pre-condition failed? Not a useful test. Post -condition failed? We found a bug.

Documenting assumptions outside of code lead to rapid unscheduled disassembly of the Arianne 5.

Why separate tests from your program? 

RBob Ashton

If I have to download the internet to use your module, I'm not going to use it.

Ian Cooper

The test is the unit, not the object under test. 

If you use tests to drive the implementation that couple to the inside, remove them once you're finished.

Devs often find outside-in testing too hard because they don't master the good setup techniques.

Joe Armstrong

A program is the most precise description of the problem that we have.

Paper systems are far more fault tolerant than what we're replacing them with.

Failure should not be handled in each piece of code but let it be handled externally.

Jonas Bonér

Isolate the failure, compartmentalize, manage failures locally, avoid cascading failure.

Synchronous RPC, distributed transactions and shared mutable state are the graveyard of distributed systems. 

Synchronous RPC give you a very high abstraction that ignores all problems. 

It's all about message passing; let that be the programming model.

Simon Brown

You can have micro-services without them being different physical artifacts. Pull them out when it pays off.

Package by component instead of by layer. Components can have layering too.

If your code doesn't match the architecture, it becomes very hard to do architectural refactoring.

Good architecture enables agility.

Torben Hoffmann

Technical arguments are never enough, you need economical ones.

You need to experience pain to have the willingness to change.

Aras Pranckevicius

Better hardware and software is the cheapest way to get more work done.

Stupidity adds up, intelligence multiplies.

Guidelines, not rules.

Alberto Brandolini

Watching the ceiling while making decisions is forbidden; visualize.

Time-box decisions. Be happy with a decision, although it's probably not the best solution.

The easiest way to remove crap from your system is not to put crap in.

Greg Young

An append-only model can be cached forever.

Wrong models cause massive accidental complexity. 

Pieter Hintjens

You are defined by what you say online, not by who you are.

You can't avoid getting your information stolen, but we can make it extremely expensive.

As information centralizes, it gets easier to spy on us. 

Book review: Antifragile

When things are fragile, they break easily. We often see fragility as a bad thing and design things to be robust. But this isn't what we're really after either; things that are robust might be hard to break, but they're also hard to change, making them fail to adapt to new stressors over time. The model that we're really after is antifragility; when something is antifragile it will benefit from stressors and get better over time.

A cup is fragile; drop it and it breaks. A skyscraper on the other hand is robust; it is designed to resist the forces of nature; from hurricanes to earthquakes. A perfect example of antifragility is the human body; go to the gym, work your ass off, and you will grow stronger.

In this book, Taleb takes this model and applies it to a wide variety of systems; biological, medical, economic and political. Most concepts are easily relatable to software too.

While the core concepts could be summarized in a few pages, Taleb uses anecdotes, ancient texts, narratives and formulas to prove his point - resulting in a 519 pages thick book. Not all passages are a smooth read though. Some parts read as if they were written in one sitting, dumping everything that had been building for years on paper, without being proofread after. Mixing that with Taleb's extremely rich (= hard) vocabulary makes for reading sessions where your full concentration is a must - not suitable for after work commutes. It took me six weeks to finish the book - well worth it though.

There are a lot of things that stuck with me. Instead of sharing those in my own words, I revisited some quotes I highlighted and copied them below. I hope they give a better feel of what to expect from the book.

Remember that you need a name for the color blue when you build a narrative, but not in action - the thinker lacking a word for "blue" is handicapped; not the doer. 

It would have taken a bit of heroic courage to justify inaction in a democracy where the incentive is to always promise a better promise than the other guy, regardless of the actual, delayed cost. 

It's much easier to sell "Look what I did for you" than "Look what I avoided for you." Of course a bonus system based on "performance" exacerbates the problem. 

The benefits of procrastination apply similarly to medical procedures: we saw that procrastination protects you from error as it gives nature a chance to do its job, given the inconvenient fact that nature is less error-prone than scientists. 

People who build their strength using these modern expensive gym machines can lift extremely large weights, show great numbers and develop impressive looking muscles, but fail to lift a stone; they get completely hammered in a street fight by someone trained in more disorderly settings.  

In project management, Bent Flyvbjerg has shown firm evidence that an increase in the size of projects maps to poor outcomes and higher and higher costs of delays as a proportion of the total budget. But there is a nuance: it is the size per segment of the project that matters, not the entire project. 

What survives must be good at serving some purpose that time can see but our eyes and logical faculties can't capture. 

We notice what varies and changes more than what plays a large role but doesn't change. We rely more on water than on cell phones but because water does not change and cell phones do, we are prone to thinking that cell phones play a larger role than they do. 

Corporations that are large today should be gone, as they have always been weakened by what they think is their strength: size.  

There are secrets to our world that only practice can reveal, and no opinion or analysis will ever capture in full. 

Recall that under nonlinearities, the simple statements "harmful" or "beneficial" break down: it is all in the dosage. 

When you think you have found a free lunch, say, steroids or trans fat, something that helps the healthy without visible downside, it is most likely that there is a concealed trap somewhere. Actually, my days in trading, it was called a "sucker's trade." 

What made medicine mislead people for so long is that its successes were prominently displayed, and its mistakes literally buried - just like so many other interesting stories in the cemetery of history. 

We are built to be dupes of theories. But theories come and go; experience stays. 

The English went further and had the families of the engineers spend time with them under the bridge after it was built. 

In the old days, privilege came with obligations. You want war? First in battle.
Never ask anyone for their opinion, forecast, or recommendation. Just ask them what they have - or don't - in their portfolio. 

Corporate managers have incentives without disincentives - something the general public doesn't quite get, as they have the illusion that managers are properly "incentivized." 

Third layer, the even more serious violation: companies trying to misrepresent the product they sell by playing with our cognitive biases, our unconscious associations, and that's sneaky. The latter is done by, say, showing a poetic picture of a sunset with a cowboy smoking and forcing an association between great romantic moments and some given product that, logically, has no possible connection to it. You seek a romantic moment and what you get is cancer. 

Don't be fooled by money. These are just numbers. Being self-owned is a state of mind.

Antifragile by Nassim Nicholas Taleb.