Today I would like to discuss a topic of 'wrong' code in software development.
I often find developers arguing. It can be about the use of languages, certain patterns or frameworks. Whichever topic it is, each of the arguers is adamant that the opposing approach is 'wrong'.
Those arguments between developers are fierce. People defend their right to develop software in their preferred style. So in situations when the preferred approach is criticized, people start to treat it as a personal attack. This leads to violent responses towards opposing viewpoints.
This often happens because people think that there is only one 'correct' way of doing things. That some people are not educated enough to follow 'the right way'. These personal biases often stem from education and experience.
In reality, there is no such thing as 'wrong' code or 'wrong' approach, even though that term is used a lot in the industry.
The word 'wrong' is completely meaningless when it comes to describing the way code is written. It won't sway either of arguing parties to change their opinion.
Think. Will the opinion of others hinder your ability to solve the problems in your day-to-day life?
Some argue that using specific language, framework or pattern will allow you to make fewer mistakes. This is misguided. It is with real complexity and a high volume of code where real problems arise. Difficulties come from the sheer amount of code and inter-connection within it. Regardless of the language or methodologies you use.
All these patterns, frameworks, etc. help you to bootstrap your project at the very start. They are very helpful when the amount of code is very small.
In contrast, you may have a codebase with the line count approaching 1 million. Even if those lines are written using the most ideal programming language, you still risk having problems. For example, you may have structured your code without proper separation. The code may also have some convoluted logic. The language choice or use of functional programming vs OOP will not save you from problems. When the complexity of the application raises, the significance of those choices approaches zero.
The bigger the project, the more important it becomes to have sensible architecture and separation of elements in your code.
After your code is separated arguing about 'wrong' code becomes a moot point. Each element can be written in a way and in a language that is the most practical for the problem at hand.
I would like to underline once again that views of others no matter how radical are just that - views. It is perfectly normal to not share those viewpoints. At the end of the day, it's irrelevant for the end-user in which language you write your code in. It's also unimportant whether you used the latest version of EF Core.
The application should solve the problem it was designed to solve. It should be delivered on time and have a pleasant and performant user experience. So, there is no point in arguing that the same thing could be achieved with 5 lines in Python.
If you can achieve the result to the satisfaction of the end-user with the technology stack you feel most comfortable with, go for it. Play to your strengths, there is no reason to torture yourself or obsess over which js framework to use.
As a software developer, the value you can bring to the project comes from your ability to strategically apply a slew of tools at your disposal. Your code does not automatically get better when you base it on the newest framework. Upgrade your code, not the framework it runs on.
Technologies evolve at a break-neck speed and what is considered 'new' is ever-changing. So you will find your self in a never-ending loop of constant re-writes.
There are software products that withstood the test of time. They are still popular not because they use a certain language or hot new framework. We use them because they solve a particular problem better than competitors.
So, develop the code in a way you think is appropriate. Approach software development from different viewpoints. Seek out the workflow the most comfortable for you. Stop seeking a silver bullet, the universal approach does not exist.
Did you ever defend a certain viewpoint or were told that the code you wrote was wrong? Share your thoughts in the comments 😤
Top comments (4)
I think you're right! This reminds me of a convo I was having with a buddy of mine a few days ago. We're both designers who code. We were discussing the idea that the "right" way to code is often influenced by the industry (i.e. the huge tech companies that influence a lot of tech and how it's built by people all over the world).
I think the standard is geared towards these companies and what they produce, but the "right" way to do something for our projects doesn't necessarily need to mirror what they're doing. I've found myself so stuck on learning about what I think I ought to be doing that I don't allow myself to be creative in my problem solving, even in the realm of coding.
But there are a lot of wrong ways to develop software. The challenge is to find the way which is the least wrong (within the available sensible constraints).
I am not convinced anybody has found the right way, yet.
In some extreme examples, maybe.
In big projects, however, I often find business logic in UI components, untested code or hardcoded magic numbers sprinkled throughout. And still, the application is 'in production' earning money and providing value to the customer.
We introduce technical debt all the time but sometimes being purist costs more.
There are definitely wrong ways to develop code. Maybe there are different ways to do things right and the right way depends much on the business... But..
In every object oriented language SOLID is important. In functional languages Single Responsibility, open closed and Dependency Inversion are still important. SOLID principles enable
you for unit testing.
If you really have 1 Millions lines of code, you should organize your code. Microservices or self contained systems are one way, but brings more complexity to your stack. So here are different ways.
There are much code smells (see Martin Fowler Refactoring) easy to detect, easy to remove.
Honestly, there are a lot of wrong ways. But there are good ways. And it's much easier to change from a good way to another good way, then from a bad way to a good one.