"SELECT" isn't broken. (h/t The Pragmatic Programmer, by Hunt and Thomas) Junior programmers will sometimes think the problems they encounter are the fault of bugs in well-tested system software, rather than their own code. (1)
The implementers of the legacy code aren't stupid. It's very common for junior programmers, tossed into the swamp of some codebase that's been around for years through many different hands, think the code is junk and the original implementers were fools. Usually, it's just that the problem is much more complicated than the juniors understand, and that's how the code got that way.
New tools probably won't solve the problem. There's a tendency with junior programmers to whine about the antique tools in use, convinced that the new Foobaz framework or Language X will magically clear up the issues they encounter. But the problems with code usually aren't from the tools used to build the code - they're from failure to understand the requirements, and time/scope/resource constraints on development.
Perfect isn't as important as finished. It's easy to get caught up in perfectionism. It's a good excuse to avoid releasing something you find embarrassing into the world. But the more time you squander polishing that turd, the less time you have for the next tur... er, cool new project.
If you can't write a test for it, you don't understand it well enough. Writing good tests is hard. It's easy to fall into a trap of "That's too hard to test. I'll just sort of check manually to make sure it works". This will bite you in the ass later!
(1) My first really good bug as a junior programmer actually was a "SELECT is broken" kind of problem (technically, mmap() was broken). I went to a great deal of effort to prove to the senior programmers (and then IBM) that my code was actually correct and I had an OS bug. And if some junior programmer came to me today and said a deep system call like mmap() was broken, I'd laugh at her and tell her to check her code. So sometimes, SELECT actually is broken - just not as often as junior programmers think.
If you can't write a test for it, you don't understand it well enough.
While this statement is generally true, I'm amazed how often people rely on
substituting good architecture and composability of modules with tests. Like
testability was some kind of magic chicken that made software good once
somebody waved it over the codebase, while the tests are mostly useful for
detecting regressions.
The ability to write tests is a fine measure of good architecture and composability. Excessive coupling is one of the top reasons tests can't be easily written.
Comments
"SELECT" isn't broken. (h/t The Pragmatic Programmer, by Hunt and Thomas) Junior programmers will sometimes think the problems they encounter are the fault of bugs in well-tested system software, rather than their own code. (1)
The implementers of the legacy code aren't stupid. It's very common for junior programmers, tossed into the swamp of some codebase that's been around for years through many different hands, think the code is junk and the original implementers were fools. Usually, it's just that the problem is much more complicated than the juniors understand, and that's how the code got that way.
New tools probably won't solve the problem. There's a tendency with junior programmers to whine about the antique tools in use, convinced that the new Foobaz framework or Language X will magically clear up the issues they encounter. But the problems with code usually aren't from the tools used to build the code - they're from failure to understand the requirements, and time/scope/resource constraints on development.
Perfect isn't as important as finished. It's easy to get caught up in perfectionism. It's a good excuse to avoid releasing something you find embarrassing into the world. But the more time you squander polishing that turd, the less time you have for the next tur... er, cool new project.
If you can't write a test for it, you don't understand it well enough. Writing good tests is hard. It's easy to fall into a trap of "That's too hard to test. I'll just sort of check manually to make sure it works". This will bite you in the ass later!
(1) My first really good bug as a junior programmer actually was a "SELECT is broken" kind of problem (technically, mmap() was broken). I went to a great deal of effort to prove to the senior programmers (and then IBM) that my code was actually correct and I had an OS bug. And if some junior programmer came to me today and said a deep system call like mmap() was broken, I'd laugh at her and tell her to check her code. So sometimes, SELECT actually is broken - just not as often as junior programmers think.
While this statement is generally true, I'm amazed how often people rely on substituting good architecture and composability of modules with tests. Like testability was some kind of magic chicken that made software good once somebody waved it over the codebase, while the tests are mostly useful for detecting regressions.
The ability to write tests is a fine measure of good architecture and composability. Excessive coupling is one of the top reasons tests can't be easily written.