Code Smell: Feature Envy

Are your classes green with envy?

Are your classes green with envy?

Methods suffer from Feature Envy, if they use other classes more than their own. This article describes why this is bad design, how to visualize feature envy and how to cure it.  Continue reading


Code Smell: Data Class

Dumb Data Class

Dumb Data Class

This articles describes what’s bad about dumb data holding classes. It describes how to refactor Data Classes. Also Code Smells are introduced briefly, of which Data Class is one.  Continue reading

Grumbling about JavaScript

Must... resist... killing... JavaScript

Must… resist… killing… JavaScript

This article describes why JavaScript is crap and its community is dumb, from an object-oriented point of view. It names alternatives and shows why they are problematic. It reveals that waiting for later versions is an option. Continue reading

The Single Responsibility Principle

Swiss Army Knife

Are your classes Swiss Army Knifes?

Every good software is based on fundamental principles, every developer should know. This article explains the single responsibilities principle using a simple example. It introduces a new diagram to identify responsibilities of a class and a simple refactoring to get rid of multiple responsibilities.  Continue reading

Advantages of Graphical Notations #1: Understand existing Software

Code vs. Diagram

Reading Code vs. Reading Diagram

In software development one can highly profit from using graphical representations, instead of reading the code directly. This article uses a simple example, to demonstrate the advantages of diagrams over code. This first part, is about understanding the status quo of an existing software.  Continue reading

Principles WTF

Think Different

Principles WTF

“Hey. Why don’t we write down some principles?”
“Why not. It might help.”
“Help who? With what?”
I regularly see folks, in what I assume is their eagerness to help and communicate, invest what can amount to considerable time and effort in discussing and, moreover, writing down sets of principles, manifestos, and the like.
This all without asking:
“Who needs us to write down some principles?”
“What do they need them for?”
“How will they actually get used?”
“How will we know if they’ve been of any use in e.g. meeting folks’ needs?”
“Could we spend the time and effort on doing something else more useful?”
– Bob

View original post