Sebastian Gebski

What I'm going to write below is nothing new for anyone who've done fully fledged distributed systems development. BEAM veterans, hAkkers, Rafters, ZooKeeper consensus pursuers or Paxos tribe would probably call me Cpt. Obvious, but surprisingly (or not) majority of .NET people I meet & talk to still live the myth of ...

Infallible system

Developers worship Defensive Programming. Once they realize (some never do)

Sebastian Gebski

There are important thinking barriers to cross (break?) in a professional career of a software engineer. They are marked with some sort of epiphanies, for instance:

  1. "WTF?! I have to work with this legacy code, instead of creating something completely new?"
  2. "WTF?! How can I troubleshoot that if I don't have access to production DB?"
  3. "WTF?! I've just wanted to swap lib A for
Sebastian Gebski

Let's start with some bold statements:

  • Team that did shitty waterfall work will most likely do a shitty agile work too (you can freely substitute the word 'agile' with Lean Six Sigma, CMMI3+, XP or whatever)
  • Nice tools can make a noticeable impact (by improving morale, increasing dev agility, etc.), but even the best tool won't solve the actual, root problem you have with
Sebastian Gebski

The prose of life

Test automation ain't trivial & there are several reasons for that, including:

  • need for scalable structure (hierarchy, naming, etc.)
  • dealing with dependencies (coupling)
  • insufficient speed of execution affecting dev agility
  • shared resources impairing isolation
  • inertia of data (incl. configuration, parameterization, etc.)

But there are two even bigger issues I'd like to mention (& elaborate more about one of them):

  • it's