Features are Unimplemented By Default

Why does system X not include feature Y?

That is quite a common question. I think that Eric Lippert has en excellent standard answer to that kind of questions on C# at Stack Overflow.

Features are unimplemented by default; C# does not have that feature because no one designed, implemented and shipped the feature to customers.

Being a developer of custom business applications, I’d like to expand on Eric’s answer a bit.

Features are unimplemented by default; the system does not have that feature because no one listed it as a requirement, prioritized it, payed for it, tested it and deployed it.

What it all boils down to is that there is a lot of work and communication required to ship a feature and nothing is done without effort. To get good results, both the customer and the developers have to take responsibility for their part of the effort.

The Developers’ Responsibilities

The Developers’ responsibilities are to handle the technical issues and involve the customer.

  1. Make sure that they have understood the requirements and ask questions when things are unclear.
  2. Design a solution that is effective, efficient, stable and maintainable and explain it to the customer.
  3. Implement the feature with quality code and test it.

The Customer’s Responsibilities

The customer’s responsibilities are to be involved in the process. Before implementation starts they have to detail their needs and afterwards they have to test the delivered feature.

  1. Explain the problem in detail to the developers.
  2. Verify the proposed solution and ask questions when things are unclear.
  3. Test the delivered feature and provide feedback to the developers.

Shared Responsibility of Communication

1 of those 6 points above 1 is technical. 5 are about communication. Clear communication is the most important key to successful projects.

The customers have to be clear on what they want, they cannot assume that anything is automatically understood. A good customer presents detailed requirements based on well defined business processes. Projects that starts with mapping of the customer’s processes (both current scenario and goal scenario) are much more likely to succeed than those heading straight into the development phase.

The developers have to be clear in their communications too, not guessing when things are vaguely described. A good developer isn’t afraid of asking even the smallest, silliest question if there is any risk of a misunderstanding.

If either part fails communication, the project is doomed.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.