Developers just wanna have fun
Software engineering Project management

Developers just wanna have fun

Software maintenance is painful because of hype driven development.
Bartosz Mikulski
Bartosz Mikulski – 5 min read

Software maintenance is painful because of hype driven development.

Table of Contents

  1. Creativity and boredom
  2. Placebo
  3. The solution?
  4. It is a trap!

We have a tremendous level of hype at every stage of software development. It influences our every decision. It is the main topic of our informal conversations with colleagues. It is everywhere.

Product owners add new features just because the features look great during the demo. Developers choose new languages and tools when they see something new and shiny at a conference or read about it in a blog post.

Creativity and boredom

What is the cause? In my opinion, it is both creativity and boredom. What do creative and ambitious people do when they work on dull tasks? When developers don’t feel fulfilled they create their own challenges. How long can you write CRUDs before you start to over-engineer them?

Do you remember your first year of being a programmer? In my case, it was awesome! Every day I was doing something new. Something that was impossible (for me) a week earlier. I was returning home both satisfied and mentally exhausted. I know I am not the only person who misses that feeling.

At some point, your tasks are no longer challenging and you no longer feel the satisfaction. It is the time when the hype creeps in. It is the time when you try a new framework, language, database, etc. not because you need it but because it looks interesting. Sometimes you don’t want to be the only person who is not playing with the new toy. The new toy that seems to be everywhere. Everywhere you look there is someone talking about it.

I feel we need an example. Is there any reason to write code in Haskell? Seriously, anything? Does it solve any of your problems? Or is it just “pretty badass to have Haskell in CV”?

Don’t get me wrong. You must learn new techniques, languages, and tools. You want to be on top of the game, don’t you? However when someone asks you why do you want to use something and the only answer you can give is “because I can”, maybe you should rethink your decision.

Placebo

It seems to me that every office has now at least one foosball table. Some companies have game rooms, others have free beers in the fridge. You can give everyone a nerf gun and encourage people to shot each other. You can rent a house in Thailand and move your team there for a month during winter. Sounds cool? Yes. Is it cool? Yeah! Do you feel great in such place? Sure! Will the feeling last longer than two months? I doubt it.

Are we trying to substitute satisfaction with foosball tables and nerf guns?

The solution?

You may not be able to change the thing you are doing. What you can try to change is the way you approach your daily work.

The next time when you want to develop a new feature or use a new tool ask yourself whether you can prove that it is necessary. Is there any quantifiable data about it? Sure, in case of new features there are your user’s comments. When we talk about new tools, there are other developer’s tweets and some conference talks.

I am not asking you about such data. Is there anything you can measure? Does the creator of the new tool claim that it is faster than the one you are currently using? What is the most straightforward test you can perform to check that? Is the test relevant to your daily work? How can you check whether it is faster when you use the tool to implement your features?

If you are seriously considering using the new tool you need to spend some time testing it. Please don’t tell me it is a waste of time and it is better (and cheaper!) to base your decision on other people’s opinions and your gut feeling.

After all, you should be able to measure everything (there is a great book about that). It does not even need to be accurate. If you don’t know anything for sure, even a rough estimate is better than nothing.

Now you can decide. Now you can tell everyone what you want to do and the people around you will have to accept it because you have the proof. You can even feel the satisfaction you miss so much. Even if you decide not to use the new cool thing, at least you made the decision in the right way.

If you can’t do any of those things (I don’t believe you…), maybe there is a small service in your project. Something that is truly a microservice, something that you can rewrite in less than a day. Such service is a perfect place for experimentation and learning something new. Please do not experiment with the most important and complex parts of your application; you are going to regret it faster than you think.

It is a trap!

Beware of post factum justification if you want to make data-driven decisions. What if you have already made the decision? What if there is something you really, really want to use? Maybe you are just susceptible to hype. What to do now?

We all know you are going to tweak the criteria and procure data that justifies the choice you have already made. You can pretend it is not the case, but it seems to be the human nature. I have no idea how to deal with that, maybe you know?

Older post

Support for old browsers — is it necessary?

Do you think that every web page should support all existing browsers? How about all versions of those browsers?

Newer post

Prevent accidental deployments on Friday

You feel you should not deploy your code on Fridays but nothing stops you. Can you prevent accidental deployments?

Related Posts

Data engineering Project management

Theory of constraints in data engineering

Are you busy, but nothing ever gets done? Perhaps, theory of constraints will help you
Published on: 25 Jun 2021

Software engineering

Query string validation in Fastify

How to validate query parameters using Fastify
Published on: 25 Jan 2019

Software engineering

Assert object pattern

The easiest way to make your tests more readable and easier to maintain
Published on: 12 Dec 2018

Are you looking for an experienced AI consultant? Do you need assistance with your RAG or Agentic Workflow?
Schedule a call, send me a message on LinkedIn. Schedule a call or send me a message on LinkedIn

>