Programmers and managers are obsessed with finding the best way to solve a particular challenge. This is a good thing because that is what quality is all about. Sometimes, though, it can be taken to extremes and the project gets stuck in discussions of minutiae.
I was reminded about this when I read about the Chandler project in Scott Rosenberg’s “Dreaming in Code“. Much of the book is about the innumerable discussions that the team members had about requirements and design which lead to the project being at standstill for significant periods of time. Also how they kept second-guessing themselves and changing decisions in mid-stream.
This is not unique to Project Chandler. Projects go through this phase where the programmers need to understand their end goals and how they plan to get there. The question is how much time do you plan to spend on it and how soon you can make decisions to get on with the construction phase? Where is the point at which you have diminishing returns from further analysis?
I wrote a post sometime back about the pitfalls of soft coding, which is writing an application in such a way that the user can configure its features ad infinitum. Soft coding exists, in part, because the team could not make a decision about what the user wants. Instead, the project team kicks the decision to the user’s court.
You can also see this in design, where there is a lot of hand-wringing about writing loosely coupled code. The idea is that you should be able to remove any class or library at any time, plug in a replacement and just have to change one line in a configuration file without compiling. So much engineering effort goes into writing such maintainable code, when in reality, most of the code will never be changed again in the lifetime of the product. And most of such decoupling is quite unnecessary because it could easily be substituted by someone taking two minutes to change the code.
Now, you may think my previous paragraph is stupid. How dare I promote tightly coupled software? But there lies the problem. Many programmers have been bitten by bad code written by bad developers that they have gone into over-engineering mode. Instead of having to change code, let’s make it so that the users can dynamically change the behavior of the software. Instead of having to recompile code, let’s make it so that some administrator can change an XML file.
Sometimes, I feel that programmers are stuck creating compilers when they should be creating applications. Compiler, as in, give users the ability to specify in minute detail how the application should behave at run-time and allow them to change their minds whenever they wish. Whatever else an application may do, you can guarantee that the “Settings” module of the application will grow and grow, as programmers delegate decisions to users.
This tendency to favor configuration over convention is perhaps due to a fear of being wrong. It is less risky to allow users to make the choice than find out what the more intuitive way of doing something is and implement that. So keep on building indirection upon indirection.
We need to break out of this cycle. Keep the application as simple as possible. Follow best practices, but don’t beat them to death. Start coding sooner. Build prototypes to validate your requirements. Build pilots to validate your design approach. Channel user feedback into refactoring the application. But just don’t sit there re-examining your decisions and trying to come up with the perfect design.