Software Development is very subjective

16 August 2022 · 8,566 views · Updated 16 June 2023

Most of you are familiar with the feeling of joining a new company and have that urge to rewrite everything. Seeing the blasphemy that your new team members committed a few years ago makes your eyes hurt. Of course, you know better, and you would follow the best practices when developing that feature. Right?

Probably. But over the years, I learned that the problem with “best practices” is that they’re very subjective. Each company you work at has different rules to be followed that, over time, make sense, and as you leave the company, you take some of those rules with you as your own “best practices.”

But there’s no one size fits all in software development. Everything that we do is very opinionated and works only for us. It’s a monster built from different aspects of different paradigms that helps us, and only us, to be efficient.

Everyone knows better.

Opinionated Practices

If we take a look at development practices, there are so many different ways that you can go about building software:

  1. Test-Driven Development - the Holy Grail of development everyone tries to achieve.
  2. Acceptance Test-Driven Development - a variation of the TDD but more focused on explaining what needs to be done from the business perspective.
  3. Behavior-Driven Development - another variation that focuses on creating a shared understanding of a description of how part of the software should work.
  4. Example-Drive Development and Story TDD - even more variations of how you can define what software needs to do and how to test it.

As you can see, each one is a highly opinionated practice, and each has developers who preach it’s the only proper way to build software. If you’re not doing TDD, are you even doing software development?

Opinionated Frameworks

The javascript world is full of wonders. There are frameworks that all claim a different approach to DOM rendering and encapsulation of modules. You can build your web application (or even mobile application) in a thousand different ways, and each of those frameworks you use has its own best practices that do not match.

Server-side rendering got exiled not long ago, but now it’s back on the table as the new cool thing with partial server-side rendering to “speed up” your application. The best practice now is to render content that changes less often server-side and the parts that often change on the browser. Some will agree, the others will say this is crazy.

Opinionated Frameworks tell you how to do things, and if you agree with them, you'll be much more efficient.

TailwindCSS is an example of a very opinionated CSS framework where the styles are done via the classes. Many people haaaaate the idea and argue, "HTML gets bloated, tailwind is like inline styles, it violates the separation of style and markup." The conventional wisdom is the opposite of Tailwind — hide as much CSS in the stylesheets and use a single class for an element. But I like the concept and think it makes me efficient when I do HTML changes for my blog, for example.

So who's right? Nobody. It's just our opinions, they're valid even if we have opposite ones.

Opinionated Products

You know how Microsoft Excel tries to guess what you’re trying to do, and sometimes it assumes wrong, so you have to go to the configuration and change the font, table, etc. That’s convention over configuration — meaning the product works delightfully for 90% of cases but allows the other 10% to be changed when necessary.

There are a lot of opinionated products — even if we take just the calendar applications. There are so many different ways you can display calendars and weekly schedules that hundreds of applications are built with strong opinions. For example, some allow booking slots only in 1-hour blocks, and others allow only a weekly view.

An excellent example in the Java world is the Ant vs. Maven. These are build tools used to create java executables. Ant gives you the flexibility, and you need to specify everything, while Maven hides most of the stuff but allows you to override the defaults.

Maven became more popular than Ant in the Java ecosystem because it was easy to use 90% of the time, and the other 10% you can change with configuration.

Conventions create an opinionated product. Opinions create user delight. User delight creates successful businesses.

Opinionated Processes

You might think that if you’re not doing agile to the letter, you’re a failure. Are you even doing software development if you can’t do it properly as the agile gods have decreed?

Well, that’s also wrong. There are so many opinions on doing agile that the original manifesto no longer makes sense. For example, during the last few months, I’ve heard several contradicting statements on doing estimations and planning for agile teams.

  1. You should estimate in points.
  2. You should estimate in hours.
  3. You should not estimate at all and break down the story into the smallest possible tasks.
  4. Don’t do agile at all. Waterfall is the best.

Even though you might think that “doing agile” is the best practice, there are so many opinions on how to do it that it doesn’t make sense to follow any advice blindly.

There’s a simple guide for adopting anything: you take any methodology that you think fits your goals and squeeze it, stretch it, squash it so that it works for your organization — so you can be as effective as possible. If anything inside the methodology makes you inefficient, throw it out and define your rules.

Opinionated Conclusion

There is no silver bullet solution out there that will make you automatically efficient. Quite the opposite, if you take any methodology and try to implement it exactly as it’s described, your efficiency will likely drop.

Being agile does not mean having a rule for everything and just following the red dotted line. Getting shit done is the only factor that matters. And even if you have a unique adaptation of the SCRUM methodology in your company — that’s also fine, as long as it works for you.

Opinions matter. The context surrounding you makes your situation unique, and the tools you select must also be adapted to your circumstances.

Every framework, programming language, and IDE you choose is just a tool that should help you get from point A to point B in an efficient way without compromising on your values. As long as you have that, then congratulations, you have a working system.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Other Newsletter Issues:

Other Popular Articles:

  • Reap

    I totally get the struggle with different opinions in software development. At the end of the day, what matters most is getting things done efficiently, even if it means mixing and matching methodologies to fit your team’s needs. It’s all about finding what works best for you and your organization.

  • Mason Lloyd

    Jumping into a new team and wanting to change everything is common, but I’ve learned it’s often more about understanding their context rather than imposing “best practices.” Every team’s unique blend of methods works for their specific situation, showing there’s no one-size-fits-all in software development. This adaptability has been crucial for integrating into new teams and finding the most effective ways to work together.

  • Gigi

    I used to be fixated on following the latest development trends and methodologies to the letter until I realized they weren’t a one-size-fits-all solution. What worked for me was picking and mixing elements from different methodologies to suit our specific project needs and team dynamics.

  • Jack Summers

    Adapting methodologies to team dynamics can boost productivity significantly. Flexibility over rigid “best practices” often yields better results, showing the importance of context in software development strategies.

  • Sebastian

    I once tried to overhaul an entire project based on what I thought were superior methods. Quickly, I learned that what works in theory doesn’t always pan out in practice. Instead, mixing elements from different methodologies tailored to our unique challenges made a huge difference. It turned more into crafting our own hybrid approach, which surprisingly improved our workflow and output. Sharing this, I’m curious if others have found similar success in blending practices to fit their project’s needs.

  • Anonymous

    Not crediting xkcd?

  • Anonymous

    There’s a big temptation for all of us to be a “methodology police”

  • Anonymous

    When we cleaned up the mess and got good at delivering software intensive systems on time and with good quality, our processes seemed to naturally evolve back to waterfall.

  • Anonymous

    Scrum is not an acronym.

  • Anonymous

    Xkcd credit for the comic “xkcd: Standards”