Warning signs in a software project rarely are found in code first. Just about the time you unpack your cubicle and get your development environment up and running, you will already have received warning signs about the application. Here’s what to listen for:
- “The code is very complex.”
- “Be careful when you make this change, it’s going to affect X.”
- “No, we don’t have unit tests. Our code is too complex for that.”
- “We have a global cache that takes care of all of that.”
- “We don’t fully understand what that affects, so be careful.”
These phrases center around a theme: The code is really hard to grok and it’s chock full of dependencies.
Uh oh.
If you’ve worked in with enough legacy codebases, you’ve probably gotten used to that. Get un-used to it. It’s wrong. Code is only as complex as you make it. As Ernest Hemingway has taught us, you don’t need to use big words to tell a story.
Your code is not an exception to this rule.
Before you cast aside what I’m saying, think about it this way: If a human can communicate using nothing but the most basic language, and communicate effectively, then why can’t the same thing be done in code? Why is that the exception?