Obviously, you must write code such that the resulting software works as desired.
That’s no longer the main problem of software engineering. The challenge is
to organize it so that it fits in your brain. Code must be humane.
– Mark Seemann, Code that fits in your head
The goal of software design is to create chunks or slices that fit into a human mind.
The software keeps growing but the human mind maxes out, so we have to
keep chunking and slicing differently if we want to keep making changes.
– Kent Beck
You should aim for an architecture of your code base so that regardless of where you look,
the code fits in your head. At a high level, there’s seven or fewer things going on.
In the low-level code, there’s at most seven tings you have to keep track of.
At the intermediary level, this still holds.
– Mark Seemann, Code that fits in your head
In .Net the source code of a finally block is always called, right?
Even if there is a return statement or an exception is thrown in the try block, correct?
I mean, this is the reason why we use try-finally in the first place.
Well, I got into a case where the code of the finally block was not called …
Design-by-Contract is not only an easy way to find bugs earlier, it is also a great tactic to improve your code quality.
With Design-by-Contract we can document expectations and assumptions crystal clear in the source code itself and
so improve changeability and maintainability!
During my day job we recently did a code review of a small feature of an application which aims
to follow the principles of Clean Architecture.
At a first glance separation of concerns as well as basic principles of Clean Architecture were
followed. But a closer look revealed that some dependencies did not follow the Dependency Rule,
specifically there were dependencies from adapters layer to the frameworks layer.
During our design discussions which followed this observation I realized that this example
would perfectly serve for a case study on how to design a feature in Clean Architecture in detail.
Do you think Clean Code should be very well documented? Do you think code comments
should help the reader to understand what the code is doing? Or do you rather
prefer DRY principle with respect to code comments?
As a software craftsman Clean Code is one of my key interests so I started a YouTube channel
to provide practical coding tutorials on how to apply Clean Code principles.
In my first video I demonstrate that Clean Code does not only start when you write a new
component or add a new feature to some existing code base. Instead you can start applying
Clean Code principles and especially the Boy Scout Rule already while reading code.
Unless you are not completely new to our profession I am pretty sure you already heard
about “Domain Driven Design” (DDD). But maybe you think that DDD requires quite some effort which is only worth it
in big software projects and that it has to be done in the beginning of a project to be effective?
This is not necessarily true …
Here is a book which nicely demonstrates that DDD and Functional Programming (F#) are two great tools to tackle
software complexity in any software project, even in a small pet project:
It has been a while since my last post on “Implementing Clean Architecture”
but I wasn’t lazy ;-) In fact I was - apart from my day job - working on getting
Athena closer to the Clean Architecture. But there was one thing which puzzled me
for a while when implementing repositories:
In Clean Architecture
all details are restricted to the frameworks layer. The database is a detail.
all data conversion from the format most convenient for what ever persistence framework to the format
most convenient for entities and use cases, happens in the interface adapters layer.
How do I implement a repository in the interface adapter circle which accesses the TFS database using the
Microsoft TFS framework APIs? Isn’t that a violation to the Dependency Rule? In fact, isn’t any usage of a third party
API outside the frameworks circle a violation to the Dependency Rule?
Do you work in one of the cool “Lean Startups” with “DevOp culture”? No? Me neither ;-)
As a software craftsman you know that DevOp practices like Continuous Delivery, modular architectures,
trunk based development, test automation, working in small batches and Continuous learning do make a HUGE DIFFERENCE
when it comes to software delivery performance!
This is one of these books which try to help you achieving more of what is important to you.
It is definitively not the first book I have read about “being more productive” and “focus”, but
“Manage Your Day-toDay” gave me a few new insights and reminded my of some things I had learn some time back already but
got forgotten in the chaos of daily business.
In fact I think every software craftsman should read regularly - at least once a year - about “focus” and “productivity”.
It is all too easy to get lost in these many and “important” things which pop up every day on our desks and in our email in-box.
Could you also spent your whole day sending and responding to email just to wonder what you have done the whole day in the evening?
In the previous post I have discussed controllers and presenters.
I have shown you how I have implemented my controllers and presenters in the Athena project.
I was quite happy with my design so far but there was one thing which puzzled me …
In Asp.Net MVC a controller derives from System.Web.Mvc.Controller which creates a dependency from my controller to the Asp.Net
framework. Taking the Dependency Rule strict that either means my design is invalid or my controller actually belongs to the
In order to learn what others think about this design I have posted my question at
and had a discussion with @herbertograca.
In this post I will share what I have learned and how I solved the puzzle …