[This article is a little stab at the “state of the art” as it is often encountered in software development projects]
I enjoy reading books and articles about software engineering. Particularly I value the works of Tom DeMarco and Gerald M. Weinberg. There is clearly tons of advice available on how to improve team work, and how to create better software.
But I still have to find a project that adopts more than 20% of what is purported in the publications I read.
I mean – really. You can measure cyclomatic complexity according to McCabe, apply agile methods or RUP, but as long as code contains methods named “validateOrder()” that delete stuff in the database the primary problems lie somewhere else. Where to start?
You wouldn’t polish your car before you hosed down the mud from your last SUV trip through inner Iceland. You wouldn’t use fine grit sand paper when you still have to take off a millimeter or two from a table you built. You would start with the easy things that bring a lot of effect first!
So, begin with the 20% of the effort that gives you 80% of the result:
- Document design decisions to provide an overall picture for everybody (don’t waste your time with JavaDoc saying that “getFoo()”, well, “gets foo”)
- Give classes, methods, parameters, and members meaningful names (that will avoid a lot of explaining via JavaDoc)
- Keep methods and classes reasonably short (which furthers understanding, and will quite likely improve cyclomatic complexity, too)
- Ensure that humans can easily understand what’s going on in the code (no, it is not sufficient the compiler is happy)
- Remember: Programming is something that humans do (a lot of time is wasted when people have to reverse engineer unnecessarily difficult code)
These measures are easy to implement (especially since all IDEs support refactoring), and help a lot.