Эволюционный по сравнению с одноразовой [закрытой] разработкой прототипа

Explicit interface implementation does not let you specify any access modifiers. When you implement an interface member explicitly (by specifying the interface name before the member name), you can access that member only using that interface. Basically, if you do:

System.Collections.Specialized.StringDictionary IWorkItemControl.Properties
{
    get { return properties; }
    set { properties = value; }
}

You can't do:

MyClass x = new MyClass();
var test = x.Properties; // fails to compile
// You should do:
var test = ((IWorkItemControl)x).Properties; // accessible through the interface

There are several use cases for EII. For example, you want to provide a Close method for your class to free up acquired resources but you still want to implement IDisposable. You could do:

class Test : IDisposable {
    public void Close() {
        // Frees up resources
    }
    void IDisposable.Dispose() {
        Close();
    }
}

This way, the consumers of class can only call Close directly (and they won't even see Dispose in Intellisense list) but you can still use the Test class wherever an IDisposable is expected (e.g. in a using statement).

Another use case for EII is providing different implementations of an identically named interface member for two interfaces:

interface IOne {
   bool Property { get; }
}

interface ITwo {
   string Property { get; }
}

class Test : IOne, ITwo {
   bool IOne.Property { ... }
   string ITwo.Property { ... }
}

As you see, without EII it's not even possible to implement both interfaces of this example in a single class (as the properties differ just in return type). In other cases, you might want to intentionally provide different behavior for individual views of a class through different interfaces.

и в ежедневном контакте с реальностью «в окопах» - они , скорее всего, почувствуют возможность для некоторых потенциальных инноваций, которые могут иметь реальное влияние, если они будут реализованы как «готовые к производству» программный проект. Продавцы, менеджеры по работе с клиентами, бизнес-аналитики, менеджеры по технологиям - все они в нашей компании часто подходят под это описание.

Но они НЕ собираются программировать на C ++, вряд ли вообще на Java, может быть, на Python, но далеко от них. "производственные" - действительно, они с гораздо большей вероятностью создадут умное доказательство концепции в php, javascript, perl, bash, Excel + VBA и множестве других "быстрых и грязных" технологий, которые мы даже не хотим мечта о производстве и поддержке навсегда! -)

Итак, называя свои прототипы "

Напишите прототип, а затем продолжайте его рефакторинг, пока он не станет продуктом. Ключ в том, чтобы без колебаний проводить рефакторинг, когда это необходимо.

Это помогает, чтобы несколько человек работали над этим изначально. Когда над чем-то работает слишком много людей, рефакторинг становится более трудным.