My thoughts on software engineering.
As you might have guessed this all began with a common phrase, “if it works, don’t touch it”. I was talking to some friends and one started speaking about a project he had worked on last year and how the quality of his code had improved since, so this other friend says “well, if it works, don’t touch it”, then I started thinking about that and the times I’ve thought that or even said it and suddenly I considered what it means to be a software engineer and if by saying “don’t touch it” I was betraying the principles of my profession, so here are my final thoughts.
What does it mean to be a software engineer?
“the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”
That is the way that ISO/IEC/IEEE Systems and Software Engineering Vocabulary define software engineering and by extrapolating from that definition we can state a software engineer to be one who applies engineering to the process of software building, but what does that really mean? Well, if we want to dig into that concept we need to start by defining what engineering is.
The ENCYCLOPÆDIA BRITANNICA states engineering as “the application of science to the optimum conversion of the resources of nature to the uses of humankind” and if go right to the basics we find out that the word engineering comes from two words “ingenium” and “ingenerare” which mean “cleverness” and *“to create” correspondingly, but where does this leave us? As we defined a software engineer as a person who applies engineering to software, and by taking the previous concept of engineering into consideration we could “refactor” that statement as:
A software engineer is a person who systematically seeks to devise the most optimum way of converting computing resources to the needs of a final user.
Responsibilities of a software engineer
There is a code of ethics (which I recommend you to read) that a joint task force by the IEEE and the ASC summarized in eight points and that I’ll try to summarize even more here (for the purpose of this article I will only include those points that define product, self and profession principles):
- Ensure that their products and related modifications meet the highest professional standards
- Advance the integrity and reputation of the
- Participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.
So, by taking our previous definition and combining it with this professional principles we could complement our statement the following way:
A software engineer is a person who systematically seeks to devise the most optimum way of converting computing resources to the needs of a final user while meeting the highest standards possible and that is constantly contributing and improving his/her knowledge.
So, should I touch it?
Technology evolves, actually faster than anything else, and with every step forward us who are in the business of building it are required to evolve with it. Take for example WEB technologies, they evolved from being a system serving static files to client-server architecture and code on demand and then to websockets, GraphQL, RESTful services, etc. So imagine a software developer, who is asked to build a site with some X functionality, decides to use something with known vulnerabilities like flash or java applets, would you consider him/her to be ethical or even a good software engineer? No, it is not an optimal solution, nor it meets the highest professional standards, so why do it in the first place? (It might surprise you but I have known people like this).
Now let’s see the case of an existing system. I work with an eCommerce platform that has around 4.5million active users, we use Angular for the front-end however due to its configurable nature some pages take a long time to load, and since the site has lots of components active at the same time some operations take long time due to change detection, this could be solved using observable bindings and ChangeDetectionStrategy.OnPush , however it works as it is, it solves the current needs of our customer. Therefore, should I make the change? Let’s see:
The current solution works, there is no doubt about it, however does it fulfill the requirements of what a software engineer should do? The answer is no, it isn’t not optimal and it does not meet the highest standards possible. Should I change it? Will the extra work be worth it? Yeah, I should and will definitely be worth it, because not only I will be satisfying my role as a software engineer but it will prevent future issues, at this point you might be thinking about all the bugs that might appear after this change, but, didn’t we say software engineering was systematical? We did, therefore changes to an existent, even a new, code structure should always go through a pipe of quality analysis, code reviews, functionality reviews, etc. Sure, that never filters all bugs but I’d rather deal with issues that appear due to an improvement than with issues that exists as a consequence of technical debt.
So, what are your thoughts about this?
Top comments (2)
There are two sides to this. From a developer's point of view: yeah, you should touch it. Heck, you should not even touch it, but kick it 'till it's down. No kidding. If it ain't broke, break it. You have to take your code into the new age, or it will rot. And if you don't, you will end up with ancient code with wich you cannot do anything because all tech that you want to apply to your code will somehow not 'fit' because your framework is out of date or even the language you used is now obsolete. By then, your best bet is probably to start over.
But.
There is of course another side to this story because you are probably not working for free, unless it is a hobby project or you are participating in an open source project. If you work for a client, that client should pay you for your work. But try to place yourself in your client's shoes: would you be willing to pay for something that gives you 'something', although you cannot grasp what it is? If you have a car that runs absolutely fine, would you allow your car mechanic to replace - say - the Crankcase Ventilation valve* just because a new ceramic one is the current state-of-the-art hype. And by the way, it won't run more economical nor would it run better in any way. Stronger: you wouldn't even notice the difference. It'l cost you a few hundred though. I bet you would not. So why should your client?
* disclaimer: I have really no idea what it is, but it seems to be in a car
You've set up a straw man here. The question isn't really "Should I touch it?", it's "Should I touch THAT?"
Presumably there is some other feature/bug/thing that you could touch (if there isn't, the company has bigger problems). And any time you touch any piece of code, it's an opportunity cost, because there is some OTHER piece of code that you could touch instead.
Whether you are working for yourself or your client, you should work on the thing that has maximum value.