Sebastian Gebski

I've encountered a very similar situation in so many companies: their IT landscape grew all the time (while nothing was decommissioned), layers they've initially got became more complicated or even split into sub-layers: sometimes parallel, sometimes stacked. Obviously, different components frequently utilize different technologies, so the skill-set required to develop & maintain all that got significantly broader.

Consequences are numerous:

  • architecture is complex &
Sebastian Gebski

Just some random thoughts / stuff I've bumped into recently. Enjoy.

Interweave tests in support

I love this legacy code rule (it's supposed to help fighting the technical debt):

When you touch any existing piece of code, always leave it in at least slightly better shape than it was before.

It makes sense, sounds golden, but it's quite intangible (or ephemeral) by its nature. What

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