Some people in my company spent most of this afternoon feverishly running around because one person on our staff gave a customer more than they asked for; the “extra effort“ ended up causing problems and complications and boiled over into some colorful telephone “conversations“ and has yet to be resolved. I'm just a casual observer to this meltdown, but it got me thinking . . .
I don't want to go into specific details, so let's take a hypothetical situation where a developer creates an application to track business contacts. The application runs fine. The .Net framework makes building in SMTP support easy, so the developer has a little extra time and builds an extra feature for emailing messages and newsletters to the contacts; this feature is developer-defined scope creep and doesn't appear on any list of customer requirements.
The developer thinks they've gone above and beyond to please a customer, and in some respects they have, but when problems start with the SMTP function -- problems that impact the rest of the application (perhaps the program crashes when an SMTP Server is unavailable), how does one handle the support for this? Does the customer pay to fix a feature they didn't ask for, but now causes problems with their program? It's a sticky situation.
There are many development methodologies out there, but I'm not aware of any that advocate doing more than you're asked like this. For one, Agile Methods (Martin Fowler has a good resource on “Agile Methods” here) dictate you do the absolute minimum to satisfy the immediate customer requirement and don't program for future extensibility. This leaves a bad taste in my mouth, however, because I usually find a certain level of prior planning and foresight is wise.
For example, after our WeProgram.Net session a few days back, Brian Noyes (from IDesign and SoftInsight) shared his experience with the User Interface Process (UIP) Block and related how he developed a small program for a customer that could have used the UIP, but he chose to save the extra time effort (which means money to the customer). As often happens, the customer came back wanting to extend the application, and the UIP would've made that extension so much easier (and cheaper for the customer)!
My point is, sometimes customers deserve more than they ask for. A smart, extensible framework can be very valuable! Other times, a simple and direct approach to solving a problem might be the way to go.
How does a developer choose?
There aren't any easy answers. It's a combination of experience, communication with the client, and luck. If I had to assert some rules regarding these situations, I would offer:
- Always error on the side of simplicity and stick to the specs! Avoid over engineering -- not everyone is building the next Amazon.com!
- Check out the Application Blocks (UIP and others from Microsoft) and develop an organizational set of practices to ensure a measure of consistency in your applications. It really makes enhancements and debugging easier!
- Don't create functions the client doesn't request, unless it's behind the scenes and related to your intelligent framework. In my hypothetical example, the programmer shouldn't have added a full set of features never requested.
I wish I had a happy ending to wrap this up with, but I don't. The two companies are going back and forth over the issue. If there's anything worth sharing on this issue, I'll be sure to keep you updated!
Happy .Netting!