For the last couple of years I have been working to improve the speed with which my extended team deals with platform support issues. It’s sounds straightforward but in reality the system is complex, multi-layered and and has core that is a dozen years old. One of the biggest problems is understanding how apparently benign changes can have unexpected consequences on the whole system, it requires a thorough understanding of not just what, but the why? Why is everything!
This is important because when dealing with large legacy systems spanning multiple technologies and architectures a simple request can quickly transform into a mini redesign and frankly no one wants that. So what we have been trying to do is ensure that our engineers understand the rudiments of the system design and that every avenue is exhausted before we talk about redesign.
Part of this process is about training the API consumers to ask the right question and provide the correct details. This sounds simple, but it is almost impossible to stop well intentioned developers from attempting to provide a detailed answer, rather than a detailed set of questions. Our development jobs hard wire us to think in solutions, rather than a well defined problem. It creates a situation where we lack the ability to see past the narrowest of concerns.
For me then I prefer to see well articulated problem rather than well intentioned solution.
Case in point this week a really talented DBA started to suggest changes to the database which were in fact correct, however, he had no idea what the application was doing or why. Without a sustained engagement with those ideas under a variety of conditions and circumstances you have no context. In essence we were provided a solution with no understanding of the ramifications of the problem.
This lack of a story means we have to do more work to create one, and then define parameters and tests to ensure that we understand the lasting impact on the platform.
This well intentioned developer gave me way more work because he could not properly define the question. This is one of the many reasons why I have started expanding my definition of programming (vs coding). I think there are many people upstream of “coders” who are essentially programming by ensure that correct questions are being asked in systematic way, they are technical gate keepers who unfortunately do not get the prestige that “coders” do, but none the less provide value by ensuring platform users define the problems correctly and precisely.
Comments are closed.