I am not teaching you anything. I just help you to explore yourself.

– Bruce Lee

Now what would be a better way to start a post than to quote a childhood hero who was a martial artist, an actor, but also a philosopher - Bruce Lee! (The old movies were common on TV while I was growing up)

This is a continuation of my satirical post TDD - The Toilet-driven development, albeit in a less satirical manner.

I’ve mentioned in the post how there is no right methodology to build software (especially those under the Agile umbrella), because they’re being sold context-free. It’s the context that decides whether you’ll have success with a certain practice, but no one really knows the exact context under which a certain methodology was born (or if it’s simply someone’s thoughts on what should work).

Building software is a lot like a martial art. The more you practice it, the more you get better at it. That’s right, practicing. Not watching some youtubers, hanging out on streams, meetups, or even reading some stupid blogs like this one. Building stuff, even if it’s something really stupid or completely useless.

Practice makes perfect. After a long time of practicing, our work will become natural, skillfull, swift, and steady.

The term martial art has it’s roots in Latin, meaning “arts of Mars”. And we know that Mars was a Roman god of war. Coincidentally, Erik Meijer famously compared writing software with fighting a war. And it is a fight with almost everything - fighting the language constructs, the legacy codes, design patterns out of place, web frameworks that are trying hard to be the lid for every pot, hard deadlines, “quick changes”, acute insufficiency of important details written down, emergency bugs, people’s opinions, your own motivation… the list goes on. It can be quite frustrating, but it’s the frustration that helps you learn what works and what doesn’t in a given situation. That’s context.

Without frustration you will not discover that you might be able to do something on your own. We grow through conflict.

The waterfall software methodology was perceived as too rigid, and the Agile movement was born as something that was supposed to be better at “responding to change”. But what did we get? A set of recipes consisted of questionable practices, from coding to management, that somehow should transform an organisation into a software production powerhouse. And if you fail while doing it, you “didn’t do it properly”, or you have “skill issues”. And if you change something to accomodate to your use case, then that’s “not the real method X”. What is it, then? I should remind you that there are numerous books on Scrum, which was originally a 15-page pamphlet!

And what do I suggest instead?

Absorb what is useful, discard what is not, add what is uniquely your own.

Rinse, repeat, and do not fear of failure.

There are only three important things about any piece of software:

1. It does what it’s supposed to do, as good as possible
2. It doesn’t break the budget
3. Is delivered in a reasonable time frame

How will you get there is not really that important, as long as you care enough to actually get there. And as I suggested many times, there is no recipe that could be followed mindlessly while expecting a successful outcome every time. It takes something that everyone desperately tries to avoid - a bit of effort.

Only the self-sufficient stand alone - most people follow the crowd and imitate.

The idea to roll your own methodology probably sounds intimidating. It could raise questions like: Where do I start? Do I have room for errors, enough time to try out things? If you’ve experienced enough frustration with the existing stuff, you’ll probably have an idea or two what to do differently. While I can’t give any specific instructions, I could point out some things that frustrate me in particular, and maybe you’ll be able to pick up a couple of things from there.

Here are some of the things I find frustrating with the existing methodologies, in no particular order:

Form without substance

This is something that frustrates me in general, not just in software development.

For example - daily meetings. Why organize meetings every day, where no one is listening to anyone, just to satisfy some prescribed form? The first thing I’d stop doing are the meetings for the sake of meetings, or any other activity being done just because it’s “by the book”. This is especially infuriating in remote teams with the big time zone difference, when you have to stay at work late in the afternoon just to satisfy some stupid formality. Now don’t get me wrong, meetings are important, but only when they’re productive. I also don’t like the idea of having a schedule to talk about what’s good or bad. Imo those things should be discussed as soon as they happen. And those are best to be discussed one on one with the manager, rather than in a group where you won’t feel just as free to talk about things.

If you really want to spend your time fulfilling formalities with little to no sense, I suggest becoming a clerk in a state-owned institution in any of the post-communist countries in Europe. You could even earn a pension for doing it.

Evangelism

Do you know what actually has to be evangelized, rather than promoted? That’s right, a religion. Or likely a cult. Did you also notice how you need to “change your mindset” every time they want you to swallow something that sounds downright crazy? There’s no need to “evangelize” anything that sounds even remotely reasonable to most people.

Rituals

See above.

Borderline psychotherapy

Some of those agile “gurus” are way too enthusiastic about psychology, and I’ve seen some collectives resembling a mental institution, or AA at least. Look pal/gal, I know that most programmers have issues, but, first and foremost, this is the workplace, and we’re all grown-ups here. Why don’t you go finish some college for a start, and run your sessions in your own house and leave us all alone?

Besides - pairing, mobing, but also sprints… all of them look like some social experiment to me (or a psyop if you will), where peer pressure is intelligently deployed to squeeze out the last drop of productivity juice from every programmer involved. Even the best engines will burn out if you hold the gas pedal on the floor for too long, but that doesn’t matter if you can afford changing cars every now and then. And it’s hard for me to understand people who actually like to program in pairs. It must be either some ego trip where one keeps showing off their skills to some junior, or the sense of accomplishment for merely giving some input while the other person is doing all the work. But the salary is in the bank account, who cares about merit anyway.

Not giving credit

You’ll notice how everything is about great teamwork, team this, team that. Being selfless and all. From each according to his ability, to each according to his needs and similar kind of BS. Newsflash - this is work, and we work for money, and for recognition so we could earn even more money. This is still capitalism as far as I know, and selflessness is for religions, charities and political extremism. Give credit where credit is due, or be ready to lose people. (Just to clarify one thing - none of this justifies being a jerk to your colleagues)

Insistence on vanity metrics

I have a huge issue with giving importance to the test coverage. Do you know that some time ago, a programmer’s productivity was measured by the number of lines they could output? Sounds ridiculous, right? I feel just about the same for code coverage measuring code quality. Just because some code was executed in a test, it doesn’t mean it works. Those are two different things. I write tests for coverage on a daily basis. They test almost nothing, but that beautiful green color is everywhere. Why? Not because I want to do it that way, but because I’m expected to do so. It’s also funny how can you exclude code from coverage and still keep that 100%. So, is it really 100% then? What about those non-trivial tests that you wrote, what’s testing them? Besides, there are many ways to verify that software works as expected, and not all of it has to be automated on the lowest layer you know. A pedantic QA person is sometimes more valuable than your entire test suite. But tell that to a TDD zealot and be ready for some “skill issue” ad hominem attacks.

Another stupid thing is the planning poker. Junior points can’t be the same as senior points, and averaging it out will somehow make it more trustworthy? And a Fibonacci sequence lol, what’s that for? To make it look more like it’s rooted in math? Mystical, even? What a pile of rubbish! But I do like Lateralus though…

Now some of you might say “but something is still better than nothing”. Well, I’m in the nothing camp this time. It’s better not to be in a marriage at all than to be in a really bad one.

Avoidance of all forms of documentation

A lot of people don’t like writing documentation, and the most common excuse is that there’s no time for it. But do you know what’s great about documentation? You don’t have to repeat yourself every now and then. New hires can get up to speed without much of your help. Also, a lot of WTFs could meet their “ooooh that’s why” before someone expresses their wish to rewrite everything from scratch. And the company doesn’t need to die with your departure either.

Ok, I better stop before this post has turned completely from philosophy to free floating hostility, and it’s already way too long for most people. If you persisted up to this point, I’d like to thank you and congratulate you on your patience.

With all being said, what’s next? Well, until there are enough brave souls to speak up and change the status quo, me, and a lot of other people like me, will continue reporting on daily meetings what they did, what they’ll do and if they have any blockers.

Maybe I’ll apply this advice myself one day. Maybe you’ll do it too, dear reader. But I don’t expect this to ever become a thing. Why? Because it’s common sense. There are no certificates for common sense. There are no expensive two-week education sessions for common sense. There’s no branding value to exploit in common sense. So it’s just us fighting with our frustrations. But:

To hell with circumstances; I create opportunities.

Thanks for reading!

All quotes in the text are by Bruce Lee.