Scott Lawrence
SPHERE OF INFLUENCE, INC. – software studios and services
In the race to build more features faster we often overlook the need for build vs buy tradeoffs. As a result, we may implement functionality using agile methods when better alternatives may be available. While the introduction of third-party dependencies to an application can create challenges as well, the right choices of third-party functionality can greatly enhance our ability to deliver quality applications to customers more quickly.
On the .NET platform, user interface controls are the third-party component we use most readily as developers. Unless there are really specific requirements, we use the textboxes, dropdowns, radio buttons, and other controls provided by Microsoft, Infragistics and other vendors instead of creating our own. Unfortunately, this willingness to use third-party functionality in the user interface does not always extend to lower tiers of our applications.
At a fair number of previous employers, development teams I was part of spent time implementing custom validation, logging, and search. In virtually every case, the time spent building custom implementations and writing unit tests for this functionality would have been better spent working on features that were truly unique to our projects. This is especially true in the case of logging.
Logging is one area where a number of frameworks are available that make it easy to add this functionality to your enterprise application. In the case of log4net (ported from log4j) and the Logging Application Block of the Enterprise Library, the functionality is available at no cost. In addition to being well-documented, both frameworks are open source. While there is a learning curve to the successful adoption of any third-party functionality, the robustness of both frameworks argues strongly in favor of using one of them instead of writing and debugging custom logging code.
There may still be an argument for a custom logging implementation, but a number of questions should be answered before proceeding down such a path:
- Is the level of effort needed to implement custom logging less than that needed to learn one of the existing frameworks?
- Is there logging functionality needed that an existing framework doesn't provide by default that couldn't be implemented through a plug-in to or customization of an existing framework?
- Would the custom logging implementation be enough of an improvement over existing frameworks that it could be reused in other applications?
If the answer to any of the questions above is no, then one of the third-party logging frameworks is probably the right choice. Asking similar questions about other functionality that isn't at the core of an application's purpose may yield a wealth of options that allow a development team to spend their time building truly innovative functionality into their products.