This is about one of my favorite principles, KISS (Keep It Stupid Simple, which I think is a better variation of the classic Keep It Simple, Stupid), that truly applies to software development. After 25 years of developing software, I have concluded that of a given software artifact, like an app, about 20% is spent on initial implementation and 80% is spent on maintenance.
In most cases the maintenance is done by someone else than the original developer, and therefore each programmer should consider the fact that, on average, the code will be read and changed four times what it took to write it. The conclusion is that you as a developer should write the code to be easily read. This is what solid coding guidelines are all about.
But it doesn’t stop with writing solid code. A lot of that maintenance time is actually spent on trying to understand the overall structure of the app. Where is a certain functionality located? What view is it that implements a certain screen in the app? It actually comes back to something really simple — order. Keeping all parts of the app according to a simple and understandable structure is as important as using a logical way of naming things. Equally important is probably that each part of the structure has a specific responsibility. This is what architecture guidelines are all about.
Therefore, the time invested during the initial implementation in creating something that can be easily understood and changed with an expected result, will save a lot of time during maintenance. So, long term, return on investment for software quality in development is obvious.
But there are obvious advantages already during implementation. A well-structured code will automatically prevent mistakes that lead to bugs, and it will also make debugging considerably easier. In projects with more than one developer, the same effects that are achieved in maintenance are realized already during the initial implementation.