| I once inherited an old ASP.NET Web Forms code base, I was a solo developer at that time. I hated it, on my young and inexperienced eyes “everything was a mess”. It didn’t follow any good practice. The code didn’t have any layer, most of the code was written in the view and it didn’t follow the DRY principle, it had just a few libraries to share some code, so there was a lot of repetition. Of course, I started “improving” it. I chose a layered architecture, I wrote several generic classes to implement the repository pattern, since I was a solo developer it took me a while to migrate big pieces of code to my new implementation. Bugs came and went and I started noticing something. Even though my implementation was “beautiful”. I hated to fix bugs on the new and “improved” code base. To debug I had to jump around a lot. The bug was always hidden. And sometimes my changes could affect other places in the code base so I had to be really careful.
In the other hand fixing bugs in the old implementation was pretty straightforward and it rarely broke other places. The project came to an end. The company bought a CRM that had more features so they shut the old code base down. All my efforts to improve the code were a waste of time. They wasted my time, not only because it was not going to be used in the future, but because even if it lived longer my changes added unnecessary complexity to the code base. This complexity made it difficult to work on a really simple project, it made it fragile and it was simply not fun. I learned a lot. I don’t judge code bases anymore. Now I can see the benefits of “ugly” code. |
Pretty code is often pretty because the ugly part is hidden, like the piping in your bathroom.
I know where I'd much rather have a bug (leak), personally.