“We must do something”
“How about we paint this elephant pink and let it rampage through the nursery?”
“Well, it’s better than nothing, I suppose”
No, no, no, no
There’s a limit to what you can do. If you don’t know your next step, step away from the keyboard, grab a coffee, or a whiteboard, or a book. If you’re still not sure, write some tests to experiment, and throw them away so you can think about the full impact before you wrote the final version.
A man of action forced into a state of thought is unhappy until he can get out of it. – Franz Kafka
Movement isn’t always progress
Just because you’re doing something doesn’t mean it’s productive, if it’s poorly conceived and planned, if it’s reactive rather than proactive, it’s just as likely to be actively harmful. Bad code isn’t technical debt, it’s a trapdoor, or a cancer if it starts to spread.
Adding code without requirements is a clear way to hokey-cokey code or creeping complexity. If you can’t say that your change will improve the code for other developers, the customer, or the users, stop and think.
It’s not just changes that cause problems. Unthought architecture can be even more dangerous. Obviously statically typed code is better than dynamic, because the compiler does something to protect you. Except static typing doesn’t protect you from null references, it doesn’t protect you from yourself.
It’s obviously better to have some logging than no logging. Unless you log everything and can’t find anything. Unless you log user and database passwords in the clear on your web server.
Every line of code you write is a breeding ground for bugs and security holes. If you remove complexity, and embrace simplicity, nothing is the most secure, most reliable way to implement something, and you need to justify the risks that come from changing that by giving the change a reason to happen.
It’s not just code
Is it better to have a project plan for a different project with different deadlines than no project plan? And even if it has the name of your project at the top and estimates you wrote, is it still a realistic plan for your project?
And are they your use cases?
Strive for quality via simplicity (and go read Zen And The Art Of Motorcycle Maintenance: 40th Anniversary Edition to truly understand that). You Aren’t Going To Need It. So don’t write it, until you do. Embrace nothing when the right something is unclear.
It’s not always easy, especially when we want to look busy, but sometimes your most productive hour is the one you spent watching that presentation on your todo list, rather than writing that $6bn dollar error.