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.
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?
If I have to download the internet to use your module, I’m not going to use it.
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.
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.
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.
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.
Technical arguments are never enough, you need economical ones.
You need to experience pain to have the willingness to change.
Better hardware and software is the cheapest way to get more work done.
Stupidity adds up, intelligence multiplies.
Guidelines, not rules.
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.
An append-only model can be cached forever.
Wrong models cause massive accidental complexity.
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.