If pragmatism raises technical debt, call it oversimplification (rant)

Post image

The word “pragmatism” or “pragmatic” is, in my personal opinion, the most overrated word in agile development. Many people use this as a buzzword without knowing what it means. I hear people saying “He solved that complex problem in half an hour, he’s so pragmatic!” and think for myself “Yeah, but that ‘solution’ probably causes other devs three times more effort than a sustainable solution would take.”

Okay, but that’s only my anger speaking. Let’s read a definition of pragmatism:

a reasonable and logical way of doing things or of thinking about problems that is based on dealing with specific situations instead of on ideas and theories – merriam-webster.com

A Reasonable and Logical Way

So even pragmatic solutions have to be reasonable and logical. I would ask so many people out there: “Is missing out documentation, tests and software design principles really a logical and resonable way of solving problems?” At least I don’t think so. Maybe if it’s only for a Executive Board presentation, you can rapidly build a prototype without having documentation or tests. But doing that, one has to take care that this prototype is not going life two weeks later.

Based on Dealing with Specific Situations

Of course, if there is a disaster case, you cannot think about the best way to build a solution for 2 days. What I am talking about are estimated, scheduled projects which are barely “fucked up” technically, because one wants to finish them fast or without thinking about it. In a second, or maybe third release, technical dept is appearing but because you have not documented nor tested, you cannot refactor. This is not pragmatism!

For specific situations or problems in development, there are often provided patterns or parts of solutions. Using those “best practices” is probably the quintessential of pragmatism. Building an over-simplified custom solution, because one doesn’t understand the best practice, is not.

Instead of on Ideas and Theories

There are many theoretical approaches in development. Let’s take the Enterprise Design/Architecture Patterns (Gang of Four) as an example. There were some people telling me, that they don’t use them, because this is theoretic and has nothing to do with pragmatic solutions. But if a “pragmatic solution” is the best way to deal with a specific situation, then I would highly recommend those patterns because the are very pragmatic.

Finishing…

Many people use words like “pragmatism” or “best practice” as buzzwords but don’t understand what they mean. Therefore, please be aware that pragmatism does not mean laziness or oversimplifying a complex problem. It means thinking practical, but also logical and resonable, so don’t misuse them.

You May Also Like

28 Days Later: Surviving Your First Month as a CTO

28 Days Later: Surviving Your First Month as a CTO

There’s a tired old trope in leadership circles: “Your first 100 days define your legacy.”

Cute idea. Presidential even. But let’s be real: in a tech org, 100 days is a lifetime. By the time you’re on Day 101, you’re not building credibility – you’re shambling through the hallways, moaning about roadmaps, and scaring interns. In other words: You’re already a Zombie CTO.

You don’t get 100 days. You get 28. Roughly three sprints if you’re on a 10-day cycle, and that’s all the slack you’ll ever get. If you don’t establish trust, show judgment, and land a couple of quick hits by then, you’re at best irrelevant – at worst, undead.

So here’s your 28-day survival guide – not theory, not TED-talk fluff, but field-tested tactics for how to stay alive (and keep your org alive with you).

Read More
How to Map Your System Landscape in One Afternoon – The C1.5 Shortcut

How to Map Your System Landscape in One Afternoon – The C1.5 Shortcut

You’ve just stepped into a new role – maybe as CTO, maybe as Head of Development – and as usual, the architecture is a maze or even completely missing. Documentation is outdated, knowledge is scattered, and no one holds the full picture. Without a map, you’re flying blind.

You could spend weeks reading thru confluence, readme and code, piecing things together, but there’s a shortcut:

In this post, I’ll show you how to map a “good-enough” system landscape in one afternoon using a lightweight, practical shortcut of the C4 framework I call C1.5.

Read More