BeckDesignRules for Database Developers: Reveals intention – Naming

In the previous post of this series I wrote about the importance of knowing your problem domain, understanding the requirements and defining the tests to be passed.

I am grateful for all the positive feedback I got, but a number of readers felt that it was too long and hard to absorb. So I am going to abandon my initial idea of writing one post per design rule.

By slicing my thoughts and interpretation of Beck’s design rules into smaller chunks and subtopics I also get the possibility to explore the rules more deeply, which I am looking forward to.

Today I dive into Kent Beck’s second rule for simple software design as expressed by Martin Fowler: “Reveals intention”.

That phrase is short, on point, and easy to remember. It is, however, worth taking a look at what the people involved in developing these rules wrote when they discussed the ideas on the original C2 wiki-page:

“The next most important thing [after passing the tests – ed. Note] is that the code is as easy to understand as possible, therefore we need to ensure that it expresses every idea that we need to express clearly”

— Jason Yip

It’s important to remember that we don’t write code for machines. If we did, we could (and should) write binary code. Since we write code to be understood and maintained by other people, we don’t, because we humans are not naturally able to get the meaning of huge blocks of 0 and 1.

Any code we write serves two purposes:

  1. Make the machine behave in the way we want
  2. Tell the reader what we expect that behaviour to be

While the first purpose seems obvious, we often forget about the second one, which is although equally important if we aim for low maintenance cost and long-term success.

So how can we make our code readable and understandable? What are the possibilities we have, particularly in database development?

Continue reading


BeckDesignRules for Database Developers Part 1: Passes the tests

Software design and software architecture are topics which are sometimes associated with distant, slightly mad geniuses, living in an ivory tower and regularly throwing UML diagrams to their ground crew of “normal” developers. They are seen as arcane knowledge which can only be absorbed by the most experienced, most talented “10x developers“, “rockstars” and “ninjas”.

From my experience, this point of view couldn’t be farther from reality. On the contrary I see software design and architecture as fundamental parts of any kind of development work. The moment we start writing code, we will make decisions and are creating software design, no matter if we are aware or not.
Of course there might be guidelines, there might be an architecture given by others, there might even be detailed API descriptions and an abstract design which paints the big picture, but in the end the little, daily decisions will have a huge impact on the result.

Understanding the rules of good software design is therefore a topic which affects developers of any skill and experience level.
Knowledge in that field will be extremely beneficial for every task related to software development.

Four Rules of Simple Design

Kent Beck, developer of Extreme Programming (XP) and Test-Driven Development (TDD), came up with four rules of simple software design in the late 1990s, which Martin Fowler expresses like this:


Martin gives a great, comprehensible description in his article about the “BeckDesignRules” which is also the source of the picture above.

I will try to take a deep dive into these rules, their spirit and how they can be practically done in database development. There is also much personal interpretation from my side and I’m not entirely sure whether Kent Beck would agree on all of my thoughts (of course I hope so).

I will split this up into several blog posts (you wouldn’t believe how hard it is anyway to keep my personal goal of one post per month) and today’s post will cover the first, probably most important and impactful of Beck’s design rules:

Passes the Tests

This one is clearly about Unit-Testing, Test-Driven Development and lots of green lights in your testing report, isn’t it? It means that good software design must adopt specific patterns from XP or other agile methodologies, right?
Continue reading