I have now worked at a bunch of companies, and consulted for quite a few. I have looked at some pretty horrible code.
Every company I visit with say the same thing:
“Yeah, but our code really sucks. “
It does not suck any more than other code I have seen. It usually sucks just about as much.
Do a thought experiment:
Of the ugly code you’ve seen, when was it written? How long has it been alive?
Most of the time, I have seen ugly code that started a good few years ago. I have also worked in companies that practiced TDD and unit testing, and still had ugly code. Their code did NOT start out with unit testing, and was just as untestable and hard to read and lots of the code you see in your own place.
If you ‘hack away’ code and it suddenly becomes successful, you hack away even more. and then suddenly, it is 2 years into the product’s life, and now it is becoming increasingly hard to maintain. NOW you also realize your code really sucks, because it was never intended to be a long lived piece of code, it was always a type of experiment to see what would happen; Would people really like it?
And then they did, and then there wasn’t enough time except to take money, fix patches and live.
And now it’s time to pay all that technical debt, and that is a good thing, because if you find yourself in technical debt, it means your product has gone through its trial by fire, and now it is growing up to become a real boy.
So do not feel bad your code used to suck. You’re doing something about it now, right? it was just in its puberty, when you needed to focus your efforts on making sure you’re on the right path.
When I am in a startup, I usually do not write tests until I feel that
- I know how to build what I am trying to build.
- I know customers really want what I want to build.
- I know the code I write will live more than a month.
Until then, I think of things as a big prototype, but unlike other places, I am not afraid of throwing it away, but I am also not afraid to accept the fact that some hackity crap code will enter during the experimentation process.
Does this mean you have permission not to write unit tests? YES, IF the main focus in your head is to get feedback that you are building the right thing. Once you know it is the right thing, not doing automated tests is very foolish.