Coaching Series Tech Industry

What is an antipattern?

What is an antipattern?

Glad you asked. An anti-pattern is a system, process, or pattern typically found in business or software development that isn’t good. In other words, it’s actually counter-productive or works against the actual goal. Another way to think of antipatterns: things that you see when groups of people work together where they repeat the same anti-productive and anti-useful activities again and again.

So, in other words, an “anti- pattern” is something you shouldn’t do.

But antipatterns are unavoidable. They exist because humans are flawed, and structure leads to human agita which, like water, will always look for the shortest way to flow down a mountain.

Antipatterns are literally everywhere in software development. A good example: think of a company culture of meetings. You have endless meetings in which people try to agree on a design for something and go around and around in circles for hours—- or even days or weeks. You think to yourself, “Why are we even doing this?” That’s an antipattern.

That particular antipattern has a specific name: design by committee.

Where do anti patterns come from?

The antipatterns come from the early decades of urban office culture in the American 50s. Some come from the hardware manufacturing cultures of the 70s and 80s (IBM and Hewlett-Packard). Many of them come from the 90s, and new ones have emerged in the age of web development.

You can think of antipatterns typically as business (human) antipatterns and software (code) antipatterns. Although helping companies identify and work with their human antipatterns is an important part of business development, in this series I will focus on coding antipatterns, particularly things that can be found in Ruby on Rails.

Rails Antipatterns

Rails comes with powerful tools. These powerful tools can be used to break down the principles of object-oriented programming: to create code that is strongly coupled, not encapsulated, poorly organized, or repeats itself repeats itself. So remember that with great power comes great responsibility.

It is said the road to hell is paved with good intentions. All good antipatterns start with a need of a developer. Typically, they exist because of either that developer’s (1) lazyness or (2) ignorance in seeing the larger picture.


Domain Design & Event Sourcing Videos

The Single Responsibility Principle — Robert C Martin (June 2014)

An annoyingly pedantic talk that covers the basics of why we separate concerns in software. He covers the fundamental SOLID principle of single responsibilty: separate things that change for different reasons, and group together things that change for the same reasons.

Martin pontificates for many minutes about different anti-patterns found in software and business, and manages to talk down to the audience while he does it.

My Take: This is a skippable video as it doesn’t cover much more than that very basics of what SRP is, which you can glean faster than listening to this dude. As well, Martin doesn’t really address the differeing complexities of a large business vs. a small business.

Domain Modeling Made Functional — Scott Wlashin

Representing State The Kotlin Edition — Christina Lee (KotlinConf 2018)

Event Sourcing is Actually Just Functional Code — Greg Young

CQRS And Event Sourcing — Greg Young

Domain Drivin Design, Event Sourcing and CQRS With F# and EventSource