With DevOps becoming more and more widespread in several industries, I’d have hoped more people would notice the correlation between the quality of the code and the quantity of negative feedback. Don’t get me wrong, I’m not talking about the convention followed or whatnot, I’m talking about the overall quality of the code.
Tasked with implemented a feature, testing it, deploying it and supporting previously implemented features leaves thinking about the future of said feature little time for consideration, and by no mean am I saying I have not fallen victim to that, but let us focus on the implementation of the feature itself.
Let’s say a developer is tasked with making a simple web application that creates a PDF based on a few text fields. So, our fictional developer makes a page on the frontend that has the fields required, namely the person’s name, their date of birth, and their favorite color. Since the data needs to be persisted, the data will need to be sent to the backend where it will be stored in a database.
So far, so good. The developer was tasked with doing a simple application, and he gave a simple solution. There’s nothing wrong with that. After all, there’s no point in over-engineering a simple problem if YAGNI.
A week later, the client using the new application is extremely satisfied; the application does exactly what they wanted it to. In fact, the client is so satisfied that they want the application to create another PDF based on different text fields.
What a bad programmer might deduce from the request:
All I have to do is copy the code I just made, but change the field names!
What a good programmer might deduce from the request:
The application is no longer simple, I should instead assume that this isn’t the last document I’ll be asked to add. The application should be redesigned accordingly.
(Do keep in mind that “bad” and “inexperienced” can be synonyms here, but “good” and “experienced” are not necessarily interchangeable.)
Perhaps the bad programmer will be able to do it faster, but when your client tells you they want to add each of their 50 unique documents, can you guess which application will be more pleasant to work with?
Let’s not even talk about how unmaintainable the bad programmer’s code is, rather, let’s focus on self-improvement.
I’m aware that not everybody has a passion for programming,but there should be no valid reason for any developer to not seek self-improvement. By challenging oneself to take the more technically challenging approach, not only are you bound to improve your skills as a developer, you’re paid to do it.
The good programmer will attempt to tackle the challenge in a way that will make creating any number of document
a simple task. For instance, using the abstraction of a field (e.g. AbstractField), creating several more precise
fields that extends said field abstraction (e.g. TextField, NumberField, DateField, etc.) and having a list of
fields inside your Document would be a significant improvement over having a specific class for each document.
Not just that, but you could even allow your client to create their own documents.
Don’t blame it on “but I’m just making the minimum viable product” - that’s a bad habit to pick up. That kind of minimum viable product may end up never upgrading from that stage and require an insane amount of time to support. If the application you made was done so with care and attention, you would have at least thought about allowing the client to make his own documents from the very moment he said that he wanted to add another document. If not, then you should have at least taken the time to ask him if he was interested in migrating more than one document and even perhaps take a step back and find a way to let the client create their own documents by providing them with a selection of fields as well as a way to position them on their own.
If you know that the application is definitely going to become bigger and bigger, you must make sure to not use a bad and counter-intuitive design. Any project started with a bad foundation is bound to collapse sooner or later.
The more features an application has, the more carefully they must be implemented.
The quality of the features you add is much, much more important than the quantity of features.
Every new feature that you are asked to add is a challenge in itself, but if the last feature(s) you implemented were implemented quickly without proper testing, you might have to both implement a new feature and fix an old feature at the same time. If you always have to end up fixing previously implemented features, maybe it’s a sign that you didn’t implement it well in the first place.
It’s possible to miss some details and just dismiss a request, only to later realize that your application is now complex and hard to refactor, but what’s truly important is that when you realize that, you don’t just ignore it and tell yourself that “it’s too late to change anything anyways”.
For the love of programming, don’t allow a software that you’re not satisfied with to end up in production. It benefits neither yourself nor other developers.