Skip to content
0:00 / 0:00

#cleancode#enterprisearchitecture#accidentalcomplexity

Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks

NDC Conferences

230K subscribers • 110 videos on Hallway • Conference channel

YouTube
  • Recommended by 2 people: 2 in engineering communities.
  • Presented by Kevlin Henney
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

939K views9 years ago2 recommendations

Software designTools and practiceDesign patternsSimplicity and complexityRefactoring and legacy code

Kevlin Henney analyzes how common enterprise coding habits and design assumptions systematically balloon codebases and increase accidental complexity.

Kevlin Henney It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, however, is rarely arbitrary and random in its structure or formulation. Systems of code, well or poorly structured, emerge from systems of practice, whether effective or ineffective. To improve code quality, it makes more sense to pick apart the specific practices and see their interplay — the cause — than to simply focus on the code itself — the effect. This talk looks at how a handful of coding habits, design practices and assumptions can systematically balloon code and compound its accidental complexity. NDC Conferences ndc-london.com ndcconferences.com

Why it's here

2 people recommend this

What people say. Recommended as a humorous and insightful critique of enterprise architecture patterns and over-engineering.

u/Alundra828in r/dotnet • Recommends

On “Should we unit test everything?”

Opinions on testing is a hot topic, and people get real passionate about how green their test coverage icon is. I'm always of the opinion though, right tool for the right job. I personally believe that widely unit testing for example a CRUD app is a waste of time. Because at the end of the day, you have to test it end to end anyway, so why not *just* test it end to end...? Unit testing at that point is just testing things you already know are tested. I think unit tests are great for helpers, extensions, etc. Anything you feel can produce a varying result, or should deal with edge cases, you should unit test. And that may turn out to be a lot of your app, in which case, that's fine. In fa…

u/extra_specticlesin r/dotnet • Recommends

On “Conversation with an enterprise architect”

"Clean Coders Hate What Happens When you let an Enterprise Architect at your code" - link to this video

u/bslessin r/Clojure • Mentions

On “Semantic Clojure Formatting”

Oh, I did not mean to imply your writing style is lacking, I'm sorry if I came across that way. Like I said, I don't know what circumstances you're dealing with in your domain. It can be that verbose names *are* correct in your context, it's just that I often find they do not. The point was that programming is more than one craft. It is true that the craft of engineering comes first in the order of priorities, but it is also a craft of communication and of writing. Take a look at slide 7 here. This is Hamlet. Same semantic content, totally butchered. Can be seen in the context of this talk. I can say it is not an appreciation of terseness for its own sake (looking at you perl), just mor…