A classic newbie problem that can stay with a developer for years. Sooner or later, overengineering will become a problem – and not only for the developer himself but also for his colleagues.
You won’t find this in a good net development company. We are talking about the systematic introduction of excessive complexity into solutions at both the micro and macro levels.
It is rather difficult to give examples of this problem, but some typical cases can be identified:
· The desire to take into account absolutely all edge cases of the application, regardless of their likelihood and the degree of risk they carry. When developing a booking service (restaurant, hotel, medical services), such a developer can spend extra hours or days on special handling of cases when the database is empty, when the booking object changes its ID, when two requests from different users compete for a common slot, and so further. It is important that this may be a good idea in itself, but the difference is that a “strong” developer will ask the manager or customer how important it is to do it right now, and whether the problem is even real before solving it.
Also, read 20 COOL INTERNET FACTS!
· Waste of resources and time on different aspects of the task is disproportionate to their actual importance. For example, a developer wrote an incredibly advanced logging system for his service with 30 files and 5 different layers of abstraction. While the entire business logic of this service fits in a hundred lines, and the task could be solved in a matter of hours, it took several days. Such a system can be of great benefit under some circumstances but is it needed at this stage, and whether such circumstances will come at all – a “weak” developer does not ask such questions.
· Innovation for the sake of innovation. A developer, solving a problem that has already been repeatedly solved in the project, connects a third-party library for this, because it solves this problem better (as it seems to him), or he just wants to try it. This is not only an unjustified waste of time studying integration issues, mastering new tools, and re-implementing the solution. This includes the creation of excess complexity in the project and a point of failure due to the emergence of new dependencies, new semantics, and the likely lack of knowledge of this component by other team members. Such processes are necessary and useful for the project, but they are carried out, in the case of “strong” developers, to solve specific, known, and localized problems.
Also, read #3 SIGNS OF A GREAT SOFTWARE DEVELOPMENT AGENCY
It takes some experience to understand that more code means more bugs, and that brevity is indeed the sister of wit. There is a common and absolutely true phrase on this score: “The best code is no code”, that is, the best code is its absence. If a developer can solve a problem in a compact and elegant way – maybe without changing the code base at all, and decomposing large and complex tasks into compact and elegant ones – this is a sure indicator that you have a very “strong” developer.
It is important to clarify that not all additional work on the code that is not essential for solving the problem can be considered overcomplicated. Refactoring and formatting the code to comply with the standards adopted by the team, enriching it with comments, and tests, and highlighting additional abstractions to reduce cohesion are useful actions, although optional, that it is advisable to perform when solving a problem, it is the balance that is important here.
