When I started off as a developer, I remember the lead architect lamenting the fact that he hadn’t been on a“greenfield” in a while - as he was scrolling through 30,000 lines of code in one file… project CSS 7 years later, I ask myself the question, “Have I learned how to keep a greenfield project ‘green’?” In the software world, the term “greenfield” refers to a brand new project, a lush undisturbed land, clean and un-trampled. In this place, a coder can lay down new laws, foundation, and ideals. He hopes people will come and view its beauty, maintainability, and scalability for years to come. Unfortunately, in one or two years time, reality comes crashing in with a vengeance. The project is no longer a “green field”, but rather a . muddy mess So what causes this? Here’s my opinion from my experience: Narrow deadlines provide easy excuses to compromise on code quality. Tests fall behind because they’re hard to write and there’s not enough time. Team leads are too embarrassed or not skilled enough for code reviews. Scope creep messes up the most well-laid abstractions. How do you combat “muddy mess” syndrome? Ideally, you handle it BEFORE the technical debt accrues, but that hardly ever realistically happens. First of all, accept the fact that you WILL have to let go of some of your rules. Regardless, enumerate the most important ones (like testing) and hold fast to them. Communicate those principles. Don’t be afraid to say “that code is not very good”. Do these things, and next thing you know, you’ll be promoted to engineering lead, and you can slowly melt into middle management. shameless plug: side project turned into - made because I needed to get tests made quickly and easily for many “muddy mess” projects. snaptest.io
