Mike W. was fresh on a new project and looking through the code base, trying to get an understanding of the architecture and how the system does its things. I believe that "disappointment" was his official reaction upon discovering how the architects designed the system's framework. As it turns out, they were a bit uncomfortable using abstract classes; maybe some one, some day will want to create an instance of the class. And they flat out didn't like interfaces; I mean, really, who uses those things anyway? Instead, they created based classes comprised entirely of "unusable" virtual methods ...

/// <summary>
/// Base class for generating TPS Reports
///
/// ED: Yes, I anonymized with TPS Report to 
///     protect our brave submitter
/// </summary>
public class BaseTpsReportGenerator
{

  // ...

  /// <summary>
  /// <B>*** DO NOT USE!! (VIRTUAL METHOD) ***</B>
  /// </summary>
  public virtual TpsReport GenerateTpsReport
    (
    string ai_sProjectNumber,
    string ai_sAssociateId,
    string ai_sReportFile,
    out System.IO.MemoryStream ao_oTpsMemoryStream
    )
  {
    TpsReportGeneratorException v_oException = new TpsReportGeneratorException(
      this.GetType(),
      "Call to base class virtual method is invalid.",
      "a_sReportFile", a_sReportFile);

    ao_oTpsMemoryStream = new MemoryStream();

    throw v_oException;
  } 

    // ...

}

One big advantage to this approach is that errors from trying to use this "unusable" method are caught at runtime, not compile time. This ensures that the code will compile much faster and with much less errors.