I know by myself, EVERY time when I get a new project, with existing code base, first thought is frustration, and desire to rewrite it the way it feels right. It works for all programmers without exception.
There is one thing I’ve learned so far: you need to stifle your inner grumbler. If you work in a team, you have to accept that things not always be as you want. Every developer has its own tricks. You have to trust and learn to delegate.
The only thing that matter is Business value. If you want to grow and not be just coder you need to understand this term.
Almost all project goes through same stages, and on each stage you have a different goal and ways to accomplish them. On earlier stages, it means speed of development and rapid prototyping. Further its challenges like growing and scaling team and product. If all goes well, someday you will rewrite all your code to Scala :)
Lack of documentation and some temporary code is OK on early stages; it don’t have to be perfect, it should be good enough. Things change if you need to jump higher and scale team. You have to think about ease of learning for newcomers, and support costs, because it becomes crucial for business value.
Remember Twitter story. When it started it was super buggy Rails app, that was down all the time. Now check where they now, they looks much more like enterprise, Java everywhere, 1500+ employees. Good project is like a book; you can’t skip and start reading from the middle, you need to pass all stages one-by-one.
Each project has a unique history, respect it, do not make hasty decisions, always think about business value.
For sure I don’t mean that you should write crappy code. I mostly talking about premature-optimizations and rewriting from scratch. Right now there are lot of tools and techniques that allow to control code quality. At least tests, code-reviews and code analysers.
Excellent article from Joel Spolsky Things You Should Never Do
You can discuss this post at Hacker News