During the past few years, many different titles have emerged for software developers. You can be a software developer, a software engineer, a frontend ninja, a computer programmer, a software architect and many other things that I may not even be aware of.
I don’t really know the actual difference between a software engineer and a software developer. Wait, let me rephrase that; in fact, there is no formal difference between the two. They are just made up titles for use in the software market. In some countries you may be called an “engineer” only if you have a particular university degree. Apart from that, though, there is no distinction regarding the practices that software engineers follow compared to developers that don’t possess such a title.
However, the word “engineer” is a key word that should concern everyone who practices software development. Engineers of most fields (electrical, civil, mechanical, etc) have some things in common, in the way they practice their discipline. These include, and are not limited to:
- Careful planning of the project at hand.
- Thorough inspection of the end product’s requirements, before starting construction.
- Design of blueprints, that at a great extent successfully envision the end architecture of the product.
- Organise beforehand the production process in split phases, with specific, concise and well defined tasks.
- Split the total product in small, modular, componentized building blocks in order to assist future maintenance, correction, enhancement and extension operations.
There is a lesson for us software developers in these practices. Many times, the very nature of our trade sets the premises for us ultimately deceiving ourselves. Software construction possesses some qualities that other fields of engineering that create tangible products don’t. It offers the creator unlimited undo and trial-and-error capabilities, and, also, it is relatively easy to create something that “just works”.
However, the human mind, especially when untrained, favours the easy and shallow solutions at first, and likes to oversimplify things. Eventually setting up a situation, where pre-planning, system architecture design, componentization and well-defined split construction phases seem rather nonessential.
Yet, modern (and not only) software is getting ever more complex trying to cater for numerous different situations, use cases and corner case scenarios and at specific situations greatly surpasses the complexity of products of some other forms of engineering.
Come to think about this: complete commercial applications usually contain hundreds of thousands of lines of code and scores of different use cases and scenarios covered. It’s impossible to keep in mind all the implementation and architecture details of a software project.
You wouldn’t start building a house without thinking first of the end design or the structural details. You wouldn’t start construction of a car’s engine without first drawing a diagram of the cabling and all the motor distribution parts' interconnections. Why then, should software differ?
Thus, usually, one has to be experienced enough in order to appreciate the benefits of the aforementioned practices of engineering. After all, they indeed introduce some overhead in the time and thought needed to build something. However, in the long run (and in many cases even sooner) they undoubtably prove to be totally necessary and essential to ever growing software products.
Planning needs twice the time the actual coding phase takes.
(Quote taken from The Mythical Man-Month, by Fred Brooks)
Think about it, one seldom dumps a software product after creating it — in the happy scenario that the market finds value in it and users are acquired, the need to enhance, improve and optimize it along the way will emerge. In the end, the codebase will get even bigger and the complexity harder to manage without careful procedures.
Only by building on solid foundations, will one be able to minimize the effort needed to extend and maintain the product successfully. As the codebase gets bigger, sloppy architectures that are not well-thought will introduce serious mental overhead, which ultimately raises the probability of regression bugs to appear.
That’s why, whichever our job title is, we should always try to follow these practices and “engineer” our code. Under specific circumstances (managers unwilling to cooperate, etc), it may be difficult to introduce such practices to your team. However, apart from the profound benefits that were listed before in this text, the inner geek inside you will find that working on well thought and reasoned code is a delight. It gives you the desire to continue working on the same project and bestow all your creativity on it, shipping features faster and making it awesome!