The DRY Principle

August 26, 2016

One of the first sessions I joined at SoCraTes 2016 was on the DRY principle in software design and when to apply it and -- maybe more importantly -- when not to. DRY stands for "Don't Repeat Yourself", which is an important guideline when we want to write maintainable code or documentation. Having stuff duplicated comes with two problems:

  • we have to make changes to more than one place (or risk inconsistencies);
  • to do so, we have to first find all those places.
Read on →

The Framework Dilemma

August 7, 2016

Software development to me is creative and innovative work that rapidly changes the world we live in. This is a great part of what I love about it. At least in enterprise application development, however, software itself is rarely the source of innovation. It is merely an enabler for the business to change and innovate.

One of many interesting insights I took from a seminar with Tom and Kai Gilb was owed to Tom's casual remark that the business domain is the most enduring aspect of our software. After all, many business domains predate software development by hundreds if not thousands of years.

Read on →

Designing for Testability

July 3, 2016

How do we ensure that software does what it is built for? That it contains no bugs? We write tests. But writing good tests can be a challenge. The approach of writing tests separately or after production code is mostly obsolete. Instead, we employ practices like TDD and BDD, which put testing at the beginning of the actual development process. One reason this works out so well is that it constrains us to writing testable software.

Testability is the quality of a software system that makes it easy to isolate a part of it and demonstrate the presence of a bug or design flaw. Importantly, testability enables actual software engineering -- as in applying empirical methods to steer development. Testing for defects is just one such method.

Read on →