What is the problem of 'over-engineering' that causes the project to die due to extra 'just in case'?
As the saying goes in Japan, 'over-engineering' is often a problem even at overseas software development sites, where products become more complicated than necessary. Mr. Simon Munoz, the chief product manager of
Overengineering can kill your product --Mind the Product
https://www.mindtheproduct.com/overengineering-can-kill-your-product/
According to Munoz, a product manager with experience as a software engineer, overengineering, sometimes described as 'code and design to solve a non-existent problem,' has defeated more projects than lack of development skills. It is a dangerous problem that has been made to happen. Therefore, Mr. Munoz summarized the causes, effects, and preventive measures of overengineering as follows.
◆ Causes of overengineering
Overengineering occurs when trying to make a product promising in case of an unknown 'just in case'. Even though that 'just in case' rarely happens, problems such as 'wasting time' and 'project complexity' continue to be a burden until the end of the project.
Another cause of overengineering is inexperience. Generally, it is said that the more experienced you are, the less likely you are to be over-engineered, but that is because 'by the time you become a skilled engineer, you have experienced over-engineering to the point of disgusting.'
Below is a learning curve that represents the relationship between engineer experience and code complexity. Inexperienced engineers first write and program simple code. Eventually,
◆ Impact of over-engineering
Overengineering specifically causes two problems: The first is “increased development costs”. As a product becomes more complex, development costs and development time increase, and the
Munoz cited 'microservices ' as an example of overengineering. Microservices are a method of combining multiple small services to form one large application. Microservices have emerged against the backdrop of the rapid changes in the business environment that have made it difficult for monolithic architectures built as a single application to handle them.Munoz said, 'I overengineer microservices. I've taken it as an example because it's unnecessary in 99% of cases, especially for startups that need to adapt to the market as soon as possible, a monolithic monolith-like architecture would be more profitable. ' I am commenting.
There is also 'Premature optimization, ' which involves setting up complex infrastructure with few users yet, or optimizing at the wrong time for fear of repeating the same thing in the future. , It is a typical example of over-engineering.
◆ How to prevent over-engineering
According to Munoz, the best way to prevent overengineering is to 'make an engineer a true product engineer.' Specifically, acquire the skills of a product manager by having engineers get involved in daily work to understand the reasons for each initiative, and by having them participate in sessions with users to acquire a user's perspective. It seems that over-engineering will be less likely to occur by having them do it.
Also, well-defined problems and disambiguations reduce the risk of engineers being over-engineered in the unlikely event. For proper definition, it is recommended to set goals using service level goals (SLO) and service level indicators (SLI).
Munoz asks himself, 'Does this help solve the problems users are facing now?' And 'Do I need to do it now?' As advice for engineers to avoid overengineering. Then you can determine if the emergency scenario carries the risk of overengineering. '
He also told the founders of startups looking to hire Ensia, 'I think it's a good idea to prioritize hiring senior engineers who already have experience in other companies. Ask and look for scars from past shuraba. The trick is to choose someone who responds to those questions with a focus on user perspective and simplicity over technical solutions. ' I did.
◆ A saying that is a commandment to overengineering
Finally, Mr. Munoz introduced the following three maxims to avoid falling into overengineering.
・ YAGNI principle
The YAGNI principle is an abbreviation that stands for 'You ain't gonna need it' and represents the principle that 'features should not be added until they are actually needed.' increase.
・ KISS principle
The KISS principle stands for 'Keep it simple stupid' and calls for the design to be as concise as possible, avoiding unnecessary complexity.
・ Worse is better
The literal translation of 'Worse is better ' is 'bad is good', but in reality it means 'the fewer options you have, the better'. 'In other words, the term is to maintain the essential functionality of the product and prevent the addition of unnecessary elements that can lead to complexity,' Munoz explains.
Related Posts:
in Software, Posted by log1l_ks