Solving the Unknown
As a developer, I run into new things everyday. I mostly work with Microsoft .Net technologies and it feels like an endless pit of information. Most developer’s feel confident about what they know, and tend to leave the unknown alone until they need it. Although I feel pretty knowledgeable about .Net, I have no problem admitting there are many areas of the framework that I do not understand or probably even know about. Not knowing an aspect here or there does not make a bad developer, it just means I may not have a need for that information at this time. What if I did need that information, but I just didn’t realize it? How does one know that they need to learn what they don’t know when they feel confident that they know enough to solve the problem? Confusing right? This is a very tough situation to be in. In development, there are a lot of ways to do everything. Some ways are simple, while others are very complex. When I receive a defect to work on, I do my best to solve the problem the best way I know how. This is a good effort on my part, but what if the solution is not whole because I don’t understand a portion of the defect? I may fix the code, run my tests, and consider the defect resolved, but do I really know if it is completely resolved? I guess that experience and working with other good developers is a good response to that question. We learn from our experiences and take those with us down the road.
I have thought a lot about this topic lately because I have come across defects that are not completely resolved. They passed the unit tests, but the tests do not wholly cover the problem. This is not due to a lack of effort from the developer working on the defect, just a lack of understanding of the true issue. So how do we solve the unknown? I think that doing a more thorough analysis on the defect is the beginning. Many times, the defect is reported and assigned and it is up to the developer to determine the cause. The next step is having someone that fully understands the issue and resolution to be involved. Finally, getting multiple resources together to review the final solution. Some solutions may require resources from different departments. Maybe someone from the business unit will be required, maybe someone from infrastructure. It is important to be able to identify the resources needed to correctly resolve defects the first time.
Comments
Follow Us
