I’m working on this theory that the more automation you wrap around a
development environment - testing, static analysis, etc. - the lazier
the developers in that environment get due to increased reliance on the
automation.
That’s not necessarily a bad thing, but I’m not so sure it’s good,
either.
Let’s say you have a .NET project and you’ve got it totally wired up
with automation.
- You have a continuous integration server running the build on every
check-in.
- You’re running unit tests and failing the build if the test coverage
levels fall below a certain limit.
- FxCop
runs with almost all the rules turned
on to check
for consistent behavior.
- StyleCop runs with almost all the
rules turned on to ensure the code is consistently formatted.
- NDepend runs to check your dependencies
and ensure other custom project-specific standards are met.
You even run your code through code reviews to ensure you get a second
(or third, or fourth) set of eyes on everything. (No, that’s not
automated.)
The point is, you’ve got all of these checks and balances in place so,
ideally, the automation will catch a lot of the stuff before it even
makes it to code review.
Somehow, though, you still see things creeping through. Things that
should have been caught somewhere along the way. Things that don’t make
sense.
Maybe it’s a bad naming convention that’s started that encourages the
breaking of the Single Responsibility
Principle…
like
HtmlHelper.
(If you have to name your class with “Helper” or “Utility,” I’ll also
put good money down that you don’t really know what it’s supposed to do
and that you’ve totally broken SRP. But even if you disagree with my
example, stick with me.)
So you add some automation around that to try and head off that bad
naming convention. The build will break or give a warning or something
if the bad convention is used. You educate the team on why the rules
were updated and folks agree to amend behavior. Fixed, right?
Nope. There’s always a way to game the system. Now there’s a new
convention where instead of “Helper” or “Utility” it’s “Service” but the
point is the same - it’s a dumping ground for random, only loosely
related functionality. But now everyone thinks it’s OK, it’s not a
problem. Why is that?
The automation didn’t catch it, so it must not be a problem.
The automation only catches the exact rule being broken, but can’t
enforce the principle. If a person doesn’t catch it - you, the
developer - that doesn’t mean it isn’t an issue.
Another example: You have your test coverage requirement cranked up to
95%. That’s pretty high. It’s not 100% because in some cases that’s not
even possible, but 95% gives you some wiggle room to leave things
uncovered but have full coverage on those things you are able to cover.
The thing is, once you have a significant codebase, that 5% can
potentially be pretty big. It might be several [small but important]
classes.
How come there aren’t any unit tests for this code? “Well, the build
didn’t fail, so isn’t it OK?” No, it’s not OK to not test your code just
because you found a loophole in the automated rules. I mean, the cops
may not have caught you for robbing the bank, but does it mean you
didn’t break the law?
The automation didn’t catch it, so it must not be a problem.
The thing is, there’s not even always a way to catch this in code
review. The naming convention thing can be caught… if the reviewer is
familiar with the team’s past history and why the convention is in
place. The coverage is actually harder to catch, especially if there is
a lot to review all at once. You have to have a lot of discipline to
mentally follow through the various execution paths and see how the
tests exercise it. You also have to trust that the developer submitting
the code for review did their due diligence and actually wrote the
tests.
Missing it in code review can sometimes even mean worse things. Now, not
only did the automation let it slide, but a fellow developer also missed
it. Must mean you never have to fix it if someone else runs across it
and does catch it, right? Why do you have this 3000 line method? “It
made it through code review.”
Sometimes this means you update the automation to try to catch these
things. Cool, now you can’t have a 3000 line method. But that 2999 line
method is just fine because the automation didn’t catch it.
That’s why I’m starting to think automation makes you lazy. You can
rely on the automation to catch so much, you stop trying to preemptively
catch it yourself. You stop using your own heuristics to detect issues
with your code and you fall back on the automation. And that’s sort of
the point of automation - to help you catch things you’d otherwise
miss… but it doesn’t entirely remove your responsibility for being
the developer.
Be a professional developer. Use the automation, but also use your
brain. Work with the automation. Understand that the automation around
your build is a tool there to help you, not robotic police trying to
enforce the law. Collaborate with your team and ask questions if you
don’t know. Be amenable to refactoring - or rewriting - if something
gets discovered after the fact.
Don’t let the automation make you lazy.