I like to say that developers are not code writers, but system designers. They’re not there to type code, but to provide a solution for a given problem.
An important detail is that a solution for a problem is not exactly the same as a solution that meets the requirements document.
Not too vague, not too detailed – about requirements
Not only developers, but also business analysts, product owners or whoever writes your requirements, try to provide value in what they do every day. Yet quality of specification has always been an open topic with undergoing discussion. Interestingly, too much specification can be even worse than too little.
When the requirements author tries too hard, the specification often turns out to be, well, literally to specific. It is not a rare situation when business people are so close to the product, that they ask for “just one if here and there and we’re good”.
However, what Bart Barthelemy and Candace Dalmagne-Rouge suggest in their article When You’re Innovating, Resist Looking for Solutions, jumping immediately from problem to solution significantly limits available options.
Let engineers do the engineering
When business people tell developers what data types they need or what conditional statement they require they step into the solution space and assume they know better.
Let’s put that into a simple story. Imagine that you’re responsible of maintenance of an old data-storage application. It stores very big backup files and as time goes by it appears that a size of a single file often exceeds the limit of what the application is capable of. It is quite likely that the business will some day appear with a requirement to split backups into smaller files so that it can be still handled by the system.
But note that splitting files is not what business actually wants. In fact, they expect the system still running without any change. What I believe the development team should do is not blindly acting according to requirements (jumping to solution space), but suggesting using bigger disks, compressing files before upload or maybe even some review and cleanup of what is actually uploaded (staying in problem space as long as possible).
In fact, the more difficult the problem, the more your organization will benefit from exploring problem space instead of solution space. We developers (not code writers), benefit from asking questions. Before you jump to any conclusion, try to explore the problem and try to find out if it has been explored by business in the first place.
Good solution works on any abstraction level
The approach of exploring problem space long enough to exhaust all reasonable options is not confined to solving problems on the edge of business and software. It is a generic approach that we should use every day.
It applies for writing actual code as well. A smart developer, when facing a difficult problem, will develop a simple and elegant solution that suits the situation. A wise developer will instead find out what class of problem are they working on, explore how other people have managed to solve it and use a well-known working solution.
What I want to say is that we’re not here to write code, but to solve problems. The more experienced developer you are the more you’re going to agree that best code is no code.