Amazon.com Widgets Software Development

Getting Giddy with Dependency Injection and Delphi Spring #9 – One Interface, Many Implementations

By Nick at November 07, 2011 11:27
Filed Under: Delphi, Software Development

So far, we’ve been registering interfaces and implementations in a one-to-one relationship.  Each interface has one implementing class registered against it.  But what if you want to implement an interface many different ways, choosing which implementation to use depending on user input or other external factors?

As always, you can download the Delphi Spring Framework from GoogleCode.

Well, lucky for us, the Spring Container lets us do just that.  The Delphi Spring Framework container registration system allows you to specify a name for any giving implementation registration, thus distinguishing different registrations from on another, even if you register multiple implementers for the same interface. 

If you register multiple implementers for a given interface without specifying a name for each one, then the “last one in wins'”.

So, for instance, you might declare a simple credit card interface as follows:

type
  ICreditCard = interface
    ['{6490640C-0E2B-4F7D-908C-0E6A74DCC0A0}']
    function IsValid(aCreditCardNumber: string): boolean;
    function ChargeAmount(aCreditCardNumber: string; aAmount: Double): Boolean;
  end;

There are any number of credit cards that customers might want to use, so you’ll need to have credit card implementations for the various common vendors:

  GlobalContainer.RegisterType<TVisa>.Implements<ICreditCard>('VISA');
  GlobalContainer.RegisterType<TMasterCard>.Implements<ICreditCard>('MasterCard');
  GlobalContainer.RegisterType<TDiscover>.Implements<ICreditCard>('Discover');
  GlobalContainer.RegisterType<TAMEX>.Implements<ICreditCard>('AMEX');

This code registers four different classes (TVisa, TMasterCard, TDiscover, TAMEX) for the same interface (ICreditCard) via the string parameter on the GetService call.  Once these are registered, you can pick and choose whichever credit card processing class you want as the implementation of ICreditCard.  You can even change the selection at runtime based on, say, user input or different orders being processed, etc. 

For instance, if you have four radio buttons that allow the user to select one of four credit cards, you can do the following:

var
   CurrentCard: ICreditCard

...

procedure TMultipleImplementationsForm.RadioButton1Click(Sender: TObject);
begin
  CurrentCard := ServiceLocator.GetService<ICreditCard>('VISA');
end;

procedure TMultipleImplementationsForm.RadioButton2Click(Sender: TObject);
begin
  CurrentCard := ServiceLocator.GetService<ICreditCard>('MasterCard');
end;

procedure TMultipleImplementationsForm.RadioButton3Click(Sender: TObject);
begin
  CurrentCard := ServiceLocator.GetService<ICreditCard>('Discover');
end;

procedure TMultipleImplementationsForm.RadioButton4Click(Sender: TObject);
begin
  CurrentCard := ServiceLocator.GetService<ICreditCard>('AMEX');
end;

The above code will assign an instance of the appropriate implementing object to the single variable CurrentCard depending on which radio button the user selects.  The proper object is returned based upon the string parameter passed to the GetService call.  That string value, of course, corresponds to the object registered with that same string as shown above. 

Thus, you can register by name and then use as many implementing objects for a single interface as you want.   This is obviously very powerful, as you can choose from any number of implementations as well as add new implementations anytime you want.

A sample application showing this technique as well as some other interesting features can be found in the samples that come along with the Delphi Spring Framework

Fun Code of the Week #2

By Nick at November 07, 2011 06:51
Filed Under: Delphi, Fun Code, Software Development
function RandomString(aLength: Integer; aInputChars: string): string;
begin
  Result := '';
  if Length(aInputChars) <= 0 then
  begin
    Exit;
  end;
  Randomize;

  repeat
    Result := Result + aInputChars[Random(Length(aInputChars)) + 1];
  until (Length(Result) = aLength);
end;

Getting Giddy with Dependency Injection and Delphi Spring #8 – Miscellanea

By Nick at November 05, 2011 05:03
Filed Under: Delphi, Software Development

So far I’ve covered a much of the basics of Dependency Injection.  There’s a lot more to it, and plenty more to discuss, but for this article, I want to stop and discuss a few items that I have kind of glossed over.  So without further ado, here they are in my beloved bullet form:

  • I have been, as you’ve likely noticed, encouraging you to use interfaces when coding, and registering classes as implementing those interfaces with the framework.  What I think I failed to mention explicitly is that all interfaces registered with the Spring Framework have to have a GUID associated with them.  You can add a GUID any time you want into your code by pressing CTRL+SHIFT+G.  If you try to use an interface that doesn’t have a GUID, you’ll get this error:  “Project <projectname>.exe raised exception class ERegistrationException with message 'Non-Guid Interface Services are not supported.
  • If you’ve looked closely at the code in the demos, you might have noticed that before you can do anything with the Spring Container, you need to call GlobalContainer.Build;  This method needs to be called before you can get anything out of the ServiceLocator.  The Build method is the code that gathers up all the registered classes and either creates them or enable them to be created on demand, depending on the lifetime type that you have selected.  If you get the error 'LifetimeTypeManager was expected.' when you run your app, it likely means that you have faced to call Build on your container.  And in fact, the Build method is really the main purpose of your DI Container.  You should call Build once, and at the root of your application.  For Delphi developers, this means that it probably ought to be called as one of the very first things in the DPR file. This also means that you need to register your classes as early as possible as well.
  • You don’t have to use the Global Container and the Service Locator provided by the framework.  You are more than welcome to create your own and expose the functionality as you want.  What we have done here at Gateway Ticketing is to declare an interface that is a complete abstraction of the notion of a DI Container, and then implement the interface ourselves using a TContainer descendant from the Delphi Spring Framework.  That way, if the framework changes (and it has since we started) or if we even decide to use a different container, our code is completely decoupled from any particular implementation.  Just another great example of “Code against abstractions, not implementations.” Smile
  • I feel compelled to point out that the whole concept of a Service Locator is considered an “anti-pattern” by some. I haven’t come to a firm conclusion on this issue myself.  Yes, a Service Locator is almost always a Singleton, but I personally don’t view read-only singletons to be bad as do some.  (A read-write singleton is really a global variable, and I think we can all agree that global variables are the Spawn of Satan.) However, there appears to be some dispute as to whether the use of a container is indeed a Service Locator. Also, if all of your dependencies are defined before execution is available to the user, then is a Container really a variable at all?  It remains a matter of debate. Ultimately, I guess I view a Service Locator as so valuable and useful so as to out-weigh any of the drawbacks they might have. 
  • There is a weakness here -- and which gets to the previous point – in that things are actually so decoupled and late-binding is so explicit that it is indeed possible to get a successful build and not know that you forgot to register a needed implementing class until runtime.  And, in a complex system, it might be a long time before anyone notices that the implementing class for a seldom used interface is missing.  If you follow the pattern that I have shown of registering an implementation in the initialization section of a unit, then you must use that unit somewhere in your app to actually have the registration take place. And as mentioned, if you forget to add it, and don’t actually include that unit in your app, the compiler won’t tell you and you will only find out at runtime.  This is a weakness and you need to be very careful to ensure that you don’t fall into this trap.  Strategies might include a single unit for doing all of your registration, or some type of static analysis that ensures that every call to GetService has a corresponding RegisterService call (or whatever your methods are called).  Something to be aware of.

Those are just a few things that you might want to consider as you integrate Dependency Injection into your coding techniques. I’ve said it before, and I’ll say it again:  If you aren’t doing Dependency Injection, you're doing it wrong. 

Delphi Mocks: The Basics

By Nick at October 16, 2011 12:41
Filed Under: Software Development, Delphi, Unit Testing

Introduction

As you may have noticed, I’ve kind of started to become a championship caliber pain in the butt about unit testing.  I walk the halls of Gateway Ticketing saying “If your code isn’t easy to test, you are doing it wrong”.  I keep giving my Unit Testing presentation to anyone that will listen.  But I feel justified – unit testing is critical to writing clean, maintainable code.

One of the reasons people seem to frequently give for not doing unit testing is that “My code requires <some external dependency> and it’s too hard to configure for simple unit tests” or something like that.  Okay, fair enough.  I won’t point out how you should be using Dependency Injection to decouple that code and enable you to insert a mock or a stub or a different class for testing purposes.  (Okay, I lied – technically I guess I did mention that.  Sorry.)  But I get that sometimes implementing a complete, formal TMockXXXX version of your interface (and you are coding against interfaces and not implementations, right?) is not something you want to do. 

Mocks

In their simplest form, a mock object is simply an alternate implementation of a class that provides “fake” responses to method calls.  For example, you have a class TCustomer that has a method GetCustomerName, and normally, that call goes to the production database and gets the name (a simple, unlikely example, I know, but you get the idea).  So to avoid the call to the database, you just create TMockCustomer, and implement it’s call to GetCustomerName and have it return “George Jetson” every time.  This enables you to test the class that is using TCustomer without having to hit the database at all.

But that can get a bit clumsy.  What if you want to return different values based on different inputs?  What if you find a bug based on specific input or output, and you want to create a unit test for that specific case?  Then a mock class as described above gets harried, complicated, and hard to maintain.

Enter a Mocking Framework

What if we could have a framework that would allow us to implement any interface, and define easily and exactly what the inputs and outputs should be?  That would be cool.  This would enable you to easily create a mock object that can respond to method calls in defined ways in a flexible, easy to set up manner.  This is what a mocking framework does.

Obviously something this flexible needs some powerful language features.  Such a framework would have to be able to flex to dynamically implement an interface.  It would have to be able to dynamically recognize method calls and respond accordingly.  Fortunately, Delphi XE2 is up to the task.  Delphi XE2 introduces the TVirtualInterface class that lets you dynamically implement any interface at runtime.  Combine that with the new RTTI, and you have the ability to build a very powerful mocking framework.

And that is just what Vince Parrett of VSoft Technologies, author of the wonderful FinalBuilder, did.  He has built a very cool and very powerful library called Delphi Mocks and released it as open source for all of us.  Very cool – thanks, Vince.   Delphi Mocks is available on GitHub under the very developer friendly Apache 2.0 License.  Vince has written a nice “Getting Started” guide, but I wanted to write  this article to build a very simple example of a pretty simple use case for mock objects.  So let’s do that.

An Expensive Service

A typical use case for using a mock object is to replace a service that is “expensive”.  Sometimes that means expensive as in “actually costs money”, but it will more likely mean expensive in CPU cycles, database connectivity, or anything else that requires an external dependency that causes your class under test to stop being tested in isolation and start being integrated with something else.   Since a unit test should always test something atomically and leave nothing (database entries, files, charges on a credit card) lying around, any time that will happen when running a unit test, you probably should consider a stub or a mock object instead.

By “stub” I mean “a class that implements a particular interface but doesn’t really do anything”.  It’s not exactly the same as a mock object in that the interface in question will normally not return anything but merely do things external to the class.  A typical example is a logging class.  If you are running unit tests, you don’t want your logging system writing logs all over the place every time you run your tests, so you create a Logger stub class that acts like your regular logger, but which actually doesn’t do anything.  You can call it in your code, but you get nothing from it – which is what you want. 

So let’s look at a simple, but “expensive” service.  Consider the following code:

unit uCreditCardValidator;

interface

uses
      SysUtils;

type

  ICreditCardValidator = interface(IInvokable)
  ['{68553321-248C-4FD4-9881-C6B6B92B95AD}']
    function IsCreditCardValid(aCreditCardNumber: string): Boolean;
    procedure DoNotCallThisEver;
  end;

  TCreditCardValidator = class(TInterfacedObject, ICreditCardValidator)
    function IsCreditCardValid(aCreditCardNumber: string): Boolean;
    procedure DoNotCallThisEver;
  end;

implementation

uses
     Dialogs;

{ TAdder }

function TCreditCardValidator.IsCreditCardValid(aCreditCardNumber: string): Boolean;
begin
  // Let's pretend this calls a SOAP server that charges $0.25 everytim
  // you use it.

  // For Demo purposes, we'll have the card be invalid if it the number 7 in it
  Result := Pos('7', aCreditCardNumber) <= 0;

  ShowMessage('You were just charged $0.25');
end;

procedure TCreditCardValidator.DoNotCallThisEver;
begin
  // This one will charge the company $500!  We should never
  // call this!
end;

end.

This unit declares two things, an ICreditCardValidator and a class that implements it, TCreditCardValidator.  It simulates deciding a credit card is bad by saying any card number that has the number ‘7’ in it is bad.  Otherwise, any string will be acceptable. It’s a demo class, obviously, but it illustrates a class that would be used only in production, as you get charged by a credit card validating service every time you call IsCreditCardValid.    Clearly, you don’t want to be calling that whenever you run your tests.  Thus, it seems likely that any collection of unit tests that wants to use this service would likely want to use a mock class.

A Class to Use the ICreditCardValidator

Mock classes really become useful when you are testing a class that consumes an expensive service.  Thus, we’ll declare the following class, TCreditCardManager, which consumes ICreditCardValidator:

unit uCreditCardManager;

interface

uses
      uCreditCardValidator
    ;

type
  TCreditCardManager = class
  private
    FCCValidator: ICreditCardValidator;
  public
    constructor Create(aCCValidator: ICreditCardValidator);
    function CreditCardIsValid(aCCString: string): Boolean;
  end;

implementation

{ TAddingMachine }

function TCreditCardManager.CreditCardIsValid(aCCString: string): Boolean;
begin
  Result := FCCValidator.IsCreditCardValid(aCCString);
end;

constructor TCreditCardManager.Create(aCCValidator: ICreditCardValidator);
begin
  inherited Create;
  FCCValidator := aCCValidator;
end;

end.

This class is really simple – it just takes an ICreditCardValidator in it’s constructor and uses it to validate credit cards.  As a demo class it is really simple, but a more complete class would have methods to make payments against the card, etc.  But if, when testing this class, you pass it in an implementation of the ICreditCardValidator above, you’ll get charged $0.25 for every test you run.  That’s not something you’d really want to do, so this class seems like a good candidate for using a mock object to replace the implementation of ICreditCardValidator

Testing TCreditCardManager Can Be Expensive

So, the typical way to test TCreditCardManager might look like this:

procedure TestTCCValidator.TestValidateCreditCard;
var
  ReturnValue: Boolean;
  ExpensiveCCValidator: ICreditCardValidator;
  ValidCard: string;
  BadCard: string;
begin
  ExpensiveCCValidator := TCreditCardValidator.Create;
  FCCValidator := TCreditCardManager.Create(ExpensiveCCValidator);

  ValidCard := '1112221'; // Rule is that a bad card has a '7' in it
  BadCard   := '6667666'; // ..so this one is bad

  ReturnValue := FCCValidator.CreditCardIsValid(ValidCard);
  CheckTrue(ReturnValue);

  ReturnValue := FCCValidator.CreditCardIsValid(BadCard);
  CheckFalse(ReturnValue);
end;

However, if you run this in the GUI test runner for DUnit, you’ll see this:

image

 

And of course, if you keep this up, the bill you get will not make your boss happy.

Testing with a Mock

So, to avoid the wrath of your boss, you should create a mock object that behaves like you want it to but that doesn’t end up costing anything.  The first way you might do it is to create a new class that implements the ICreditCardValidator interface, but that does nothing or returns set values.  But that is kind of clunky, and hard to customize.  What you really want is what I mentioned earlier, an extensible mock that can be created an configured on the fly.  That’s where Delphi Mocks comes in.

The Delphi.Mocks.pas unit declares a type TMock which takes a parameterized type, and which then can sort of morph itself into an implementation of that interface using the cool new-to-XE2 class called TVirtualInterfaceTVirtualInterface basically allows you to implement an interface on the fly at runtime.  Thus, you can create a generic class (or record, in the case of TMock) that can appear to be any interface you want it to be. 

Thus, we can create a TMock that looks and acts like an ICreditCardValidator:

var
  CCMock: TMock<ICreditCardValidator>;
 begin
  CCMock := TMock<ICreditCardValidator>.Create;
  ...
end;

Once we have that mock, we can tell it how to behave:

  ValidCard := '1112221'; // Rule is that a bad card has a '7' in it
  BadCard   := '6667666'; // ..so this one is bad

  CCMock.Setup.WillReturn(True).When.IsCreditCardValid(ValidCard);
  CCMock.Setup.WillReturn(False).When.IsCreditCardValid(BadCard);

This code uses a nice fluent interface to be somewhat self-explanatory.  It basically sets the mock up as follows: “When I pass in the valid string, return True.  When I pass in the bad string, return False.”  This is a basic definition that will allow your TCreditCardManager class to exercise itself with both good and bad input, allowing you to test your code with both kinds of responses.  We can determine exactly what the inputs and outputs are and ensure that the mock displays the correct behavior and follows the business rules set out in the “real” implementation.  Notice, too, that the When call, through the delightful magic of generics, is actually an implementation of the ICreditCardValidator interface, and thus is able to execute a real method call to the method from that interface.  You even get support from Code Completion in the IDE. 

Now, you can create the Credit Card Manager, pass it your mock object, and run tests with your mock input and output:

  FCCValidator := TCreditCardManager.Create(CCMock);

  ReturnValue := FCCValidator.CreditCardIsValid(ValidCard);
  CheckTrue(ReturnValue);

  ReturnValue := FCCValidator.CreditCardIsValid(BadCard);
  CheckFalse(ReturnValue);

This way, you can exercise the instance and test it  to your hearts content without incurring any of the expense associated with your “regular” implementation.  If you need to add additional tests, you can simply tell the mock class what the new input and outputs are, and then run the appropriate tests.

Ensuring Code Is (or Is Not) Called

When writing tests, there may be times when you want to ensure that a given method is called with a frequency that you want to specify.  Thus, you can write things like:

  CCMock.Setup.Expect.AtLeastOnce.When.IsCreditCardValid(ValidCard);

  // Ensure that the tests never call this.  It costs $500!!
  CCMock.Setup.Expect.Never.When.DoNotCallThisEver;

And then, when all the test are run, call:

CCMock.Verify;

on the mock object, and it will validate that the calls that you required were indeed called. 

So, in the above example, if I were to call:

CCMock.Instance.DoNotCallThisEver;

I would get the following dialog:

image

…which of course tells me that I called a method in my tests that should not have ever been called.

There are also methods on the call to Expect interface that ensure that a certain call is made a minimum or maximum number of times, between a specified  number of times, at least or at most a certain number of times, and as we saw, even never.  Also, you can specify that one method be called before or after other methods.  This enables you to dictate exactly how your object methods are called, and what should or should not happen when you run your tests.

Conclusion

So the Delphi Mock library is a very powerful tool for making it easy to write concise unit tests that don’t connect to “expensive” classes that could make testing difficult.  The goal of writing testable code is a worthy one, and Delphi Mocks definitely can make it easier to reach that goal.

Getting Giddy with Dependency Injection and Delphi Spring #7 – Controlling Construction

By Nick at October 08, 2011 12:47
Filed Under: Software Development, Delphi

As always, you can download the Delphi Spring Framework from GoogleCode.

By now you should be getting the idea about dependency injection – how you can use it to decouple your code and provide instances of your objects.  Hopefully you see the benefits of coding against interfaces and not implementations.  And if things are going really well, you are writing unit tests with ease because your code is easily tested. 

However, I bet by now some of you are thinking that this looks really cool and all, but there is just a touch too much “magic” going on – that there is a bit too much going on under the covers.

Well, you are right about that – there is a lot going on under the covers.  The Delphi Spring Framework does a lot of work for you, mainly by creating instances of classes using Run-time Type Information (RTTI).  It controls the creation, and can even let you manage the lifetime of those objects.

But I also bet that some of you are a bit uncomfortable with the notion of relying on all that magic.  While turning over that control will work in many cases, you don’t always want to give up control over the  creation of your objects. 

Well, you don’t have to.  The framework allows you to customize the way that your classes are created if you so desire.  Very often, if your classes are well designed – your constructors are simple, you aren’t doing much more than assigning values �� you don’t need to do anything special when you construct an instance.  But sometimes you do.  Sometimes, your class needs to be passed something dynamic – a class whose state can only be known at runtime.    For instance, you may have a given customer, and that customer has invoices, and you have a class that you want to pass that customer to, but you also want to completely decouple that class.  Your customer is dynamic – you may be running a query and need to perform this operation on every customer in your database. Or maybe the customer is doing something on your website, and so your customer object is specific to that customer.  In any event, the customer data is dynamic at runtime, and so the creation of an object can’t be cookie-cutter.  It has to be unique each time you need an instance of this object that takes action on the given customer. 

The code below comes from the Samples directory of the Delphi Spring Framework.  It’s part of the Demo.Spring.DelegatedConstructor project

The Spring Framework lets you control the creation of your objects through a method on the TRegistration class – the class used to register types against interfaces.  As part of registering your class, you can pass an anonymous method of type TActivatorDelegate, which his declared as:

TActivatorDelegate<T: class> = reference to function: T;

The TRegistration class uses the fluent interface, so you can chain together a number of things that you want to attach to any given registration.  So, for instance, if you have a project involving a TUser class, and the TUser class is dynamic, then a class (such as TUpgradeUser) which needs a TUser, might be registered as follows:

  GlobalContainer.RegisterType<TUserProcessor>.Implements<IUserUpgrader>.AsTransient.DelegateTo(
    function: TUserProcessor
    begin
      Result := TUserProcessor.Create(GetCurrentUser);
    end
  );

The TUserProcessor class is registered as implementing the IUserUpgrader interface.  The lifetime of the resulting class is set to be “Transient” meaning that the implementing class will live “normally”; that is, it will be destroyed when the interface reference goes out of scope.  (Note that AsTransient is the default lifetime.  We’ll discuss container lifetime management in a future blog post). 

Finally, the actual creation of the TUserProcessor class is “delegated to” an anonymous method – a function in this case, as noted above – that simply returns an instance of the TUserProcessor class.  The key here, of course, is that the anonymous method can call the GetCurrentUser routine which will inject the current, dynamic TUser instance into the resulting object.  You can do anything you want in this anonymous method, including creating and setting up the resulting object in any manner you choose.  You could set properties and even call methods on the resulting, implementing object. 

If you examine the code for the project, you’ll note, of course, that it doesn’t actually do anything other than write to the console.  The GetCurrentUser call is merely a singleton returning the same instance of TUser.   The code is merely illustrative, and so the “background stuff” doesn’t really do anything.  In a real application, a call to GetCurrentUser would do just that, return an instance of TUser that represented the current, dynamic state of the user in question.   The critical part to note is that you can control the creation of the TUserProcessor to as large a degree as you want. 

Finally, when you actually call the ServiceLocator to grab an instance, the Container will call your anonymous method and return an instance constructed exactly like you want it to be constructed.

So in the end, the Spring Container gives you total control – if you want it – over the creation of your objects.  If you need to, you can have a little control over the “magic” that takes place and sprinkle your own little fairy dust on the construction process.

Revenue Recognition and the Software Development Industry

By Nick at September 28, 2011 15:10
Filed Under: Delphi, General, Software Development, TechBiz

Before I start, I want to stress that I am not a lawyer.  I am not an accountant.  You’d be a total fool to base any business or legal decisions on anything I write here.  Consult a an attorney or a fully accredited CPA or some other person who truly knows what he’s talking about before deciding how to make any decisions whatsoever about anything having to do with money, the law, revenue, etc.  I don’t know anything, and if you listen to me, you are making a big mistake. 

Introduction

Developers and other people involved in the software business have heard a lot about “Sarbannes-Oxley” (SOX) and “revenue recognition” and how it effects what Embarcadero can and cannot do with respect to updates, upsells, promotions, and all kinds of issues surrounding selling and releasing Delphi.  SOX was a significant, game-changing piece of legislation here in the US, and it affects virtually every public company in the country.  It also affects private companies that might someday want to be a public company.  It affects software companies in particular, because software is not a physical good in reality, but “acts” like one in the marketplace. 

When I was at Borland/CodeGear/Embarcadero, it took me a while to come to grips with what SOX meant and how it altered our business and what we wanted to do.  Frankly, I found it all very frustrating.  On the face of it, the rules and limitations seemed ridiculous. At first I complained bitterly about it.  It took a while, but finally I came to accept them and realize that SOX and the ensuing rules were the “field we had to play on”.  Finally, I think I actually gained enough insight into it that I was able to come to grips with the new rules and understand why things work the way they do.  As a result, I thought I’d share a bit of that with you fine people.

What is Revenue Recognition?

First, it might be obvious, but let’s be sure we know what the term “revenue recognition” means.  Revenue recognition is the process by which a business says “Yep, we actually earned that revenue”.  Note, it most decidedly does not mean “We got the cash”.  In an accrual accounting system – common to businesses of almost any size – the receipt of cash can actually go down as a liability. Think of taking an advanced payment for services: If you take half the money up front for a job, you have it in the bank, but you still owe the services. Revenue can’t be “recognized” until you do in fact deliver that good or service for the money you’ve received.  So if you are a software company, you can recognize revenue only when the software you sell is actually delivered. But software is a strange product in this regard, as we’ll see. As a result, The rules for  revenue recognition for software are somewhat cloudy and definitely untested in a court of law.

Why it Became an Issue

When it comes to software, one of the main roots of the revenue recognition rules stem from the (previously) common practice of "pumping the channel".  Near the end of the quarter, firms would "sell" lots of stuff to their channel partners.  For example, lets say that there was a software company called TrollWare.  Selling for a given business quarter started looking a little thin, so TrollWare would "sell" $1,000,000 of product to their favorite online/catalog retailer.  (And remember, this was actual, physical boxes back in the day.)  Then, they'd claim $1,000,000 of revenue on their books.  Wall Street, creditors, and anyone else interested in a company's revenue would think "Hmmm -- that's $1,000,000 in revenue more than we thought!  Buy TrollWare stock!” Obviously, this wasn’t a real sale, and could actually end up being a net cost because of the need to actually ship (and maybe even actually destroy) physical boxes of software.  This was a common practice throughout the industry, and many companies that we have all heard of did this.

Of course, most often, TrollWare would only really sell, say, $100,000 of all of that "shipped" software by the end of the month and have to buy back $900,000 of it at some point, but hey, revenue is revenue!  Clearly this is not a practice laced with clarity, openness, and integrity with respect to people looking at the viability of Trollware.

New, Tougher Rules

This kind of thing was one of many reasons that prompted passing of SOX.  The results of SOX are varied, but the results of interest to us software developers were new Generally Accepted Accounting Principles (GAAP) rules for software companies that defined revenue as truly delivering something to the customer.  Now, for a hot dog company, it's pretty clear when a box of hot dogs has been fully manufactured and when that box has left the warehouse on the way to a consumer or a business, or whomever is the "end user" of those hot dogs.  For example, if you are a rake manufacturer and sell rakes to Home Depot, you can claim the revenue when the delivery truck leaves your loading dock heading to that big orange building.  Retailers of rakes like Home Depot can claim the revenue when the rake is scanned across the Point of Sale on its way to clear someone’s lawn.  In the first case, Home Depot is the "end user" and in the second case, the guy with the leaves on his lawn is.

But then the question becomes:  What does it mean to "deliver a completed software product to the end user"?  Well, that's tricky.  There are two things here, of course.  First, when is the product really “completely produced and manufactured”.  Is a beta good enough?  What if a promised feature isn’t quite finished? How about a feature that was promised but isn’t there at all? Second --  assuming that you can define the first item -- when is that completed software product actually delivered? Who *really* is the end user?  As it turns out, it’s not quite analogous to the rake manufacturer/Home Depot relationship described above.  Because software companies were actually fairly guilty of the dubious “channel pumping” practices described above, the rules about what constitutes “final delivery” of software are fairly restrictive, and certainly different than those dictating gardening tools.

There is a lot of accounting literature about this (I’m not thrilled about the fact that I've read a lot of it.  It’s not exactly scintillating).  For instance, do a Google search on “revenue recognition software licenses”  and start reading.   The rules are pretty complicated and hard to qualify exactly. And further complicating things, no software company has yet been brave enough to test these rules in court, so they are even murkier as companies work hard to stay well away from the borders of where the rules end and a call from the US Department of Justice starts. 

Thus, software revenue can only be recognized when said software is fully and completely delivered to the end user.  For a "normal" sale like most of us think of it, revenue can be recognized when the end user has the ability to install the software -- a license is delivered and the user installs it.  (For physical software, it's still the truck leaving the loading dock to the actual end user  and not merely the reseller). 

There's a catch, though:  It has to be the complete, finished package.  As mentioned above, revenue can only be recognized when a completed product is delivered.   If you deliver a "preview" of your product or even a feature of your product, this can imply a commitment to deliver something at a later date.  If you even implicitly promise that the purchase today will result in a delivery later, then that probably means you can't recognize revenue until that implicit promise is met.  Again, I say “probably” because this is turning out to be the common interpretation of the rules in a world where no one wants to test this in court.  This is a unique problem for software because no one normally buys a “preview lawn mower” with the promise of more functionality later.

An Example

So, for example: Troll Software delivers a Trollware 1.0 in mid-February.  Their spell checker isn't really quite ready, but they need to ship because their main competitor has already shipped a version with a spell checker. Or maybe the need to get some Q1 revenue to keep from not making any money and having to to massive layoffs is a driving factor in the decision.  So they ship the product with the label "Spell Checker!!! (Preview only)”.   Then, a week into April, they deliver their fully ready Spell Checker to all existing purchasers and update their downloadable ZIP file.

They sell $1,000,000 worth of Trollware by March 31, and think "Yay! We have $1,000,000 in revenue in Q1! Wall Street will love us!"

Oops, not really:  They actually have $0 of revenue in Q1 from Trollware.  That’s right:  $0 in revenue. All of those sales become Q2 revenue, because they didn't actually complete the delivery of any Trollware versions in Q1, but instead in Q2.(This brings about the interesting situation where a company can have $1,000,000 in the bank and $0 of revenue on 31 March for Q1).

Another example:  Say you are a Trollware subscriber, and sent them $1200 a year as part of your subscription, receiving updates, improvements, and new features during the term of the subscription.  Troll Software can only recognize $100 a month for the 12 month term of the subscription.  And consider this:  What iff Troll Software wanted to move exclusively to subscription model starting the first of the year?  They might have the same number of customers buying, but now their revenue for the first month would immediately be 1/12 of what it normally is, despite having a lot of money in the bank as noted above. 

Bug fixes to existing functionality is actually excluded from this -- this is why you normally don't see new features in bug fix updates.

The same might go for "Special offers to registered users".  Say they sell a bunch of Trollware in the first half of the year.  Starting July 1, they say "Free Grammar Checker to anyone that buys Trollware 1.0!" and in the small print it says "... and if you already have Trollware 1.0, you can have the Grammar Checker, too".

Well, now, if this is the case, have you actually delivered the software to the buyers who purchased before the special offer?

That's why I said "might".  As I understand it, this particular issue isn't exactly clear and hasn't been tested in court as far as I know.  And of course, no one wants to be the test case for the SEC or the Department of Justice.  So in the end, it seems that no one is willing to risk such a deal.

Revenue is King

And of course revenue is everything in business and finance, because it represents the value that you have actually delivered to customers.  Revenue is the only real way to measure the accomplishment of a company.  And that's fair if you think about it -- that is where Enron is a great example.  They weren't actually delivering anything to end customers, but still racking up revenues like crazy.  So in the end, measuring accurately what is really, no kidding delivered to end users is what finance people are interested in knowing.

Sarbannes-Oxley was sort of the root of this.  One of its main features was to actually hold the corporate officers of public companies criminally liable for their GAAP compliance.  The threat of prison time has a tendency to focus the senses.  As a side result of SOX, the definition of revenue recognition – and more importantly the desire to strictly follow that definition -- really became an issue, and the need to know a companies real revenue was one of the main fallouts.  CEO’s wanted to be 100% sure that they were recognizing revenue correctly because, well, they don’t want to go to jail.  Now, there is a lot not to like in SOX, and I personally would like to see it repealed, but the end result being that software company CEOs became far more focused on correctly recognizing software revenue.  It's still a bit unclear, and the software industry is still very wary of all of it, because it is untested in court, and as I said, no one wants to draw the attention of the US Government on the matter. 

In the end…

Every public company that produces or sells software has to follow the rules set up by SOX.   Any business that wants to get a loan from a bank or otherwise interact in the general community of businesses needs to follow GAAP.  It's not always  fun, but that is the way it works.  These revenue recognition rules can result in companies having to do some strange things and, more importantly, not being able to do things that they might want to do and which might even make good sense.  But in the end, all organizations in the software business have to follow these rules. 

However, in the end, I have no problem with their being clear, concise rules about what "revenue" really means.  Really, I think it is hard to disagree.  Revenue is a measure of actual, delivered value, and thus a measure of the real value provided by a corporation.  That's something that is really good to know.

Getting Giddy with Dependency Injection and Delphi Spring #6 – Don’t even have a constructor

By Nick at September 24, 2011 04:54
Filed Under: Delphi, Software Development

Introduction

Article Four in the series had a couple of rules to follow, one of which was “Keep Constructors Simple”.  In the last article we saw how you can use the Spring Container to hold interfaces with specific implementations so that you don’t have to create anything, but instead ask the container for an instance of an interface. 

Well, in this article, I’m going to go a step beyond even that, and show you how the Delphi Spring Framework can make it so that you don’t even need to have a constructor by automatically injecting implementation instances when they are needed without you having to do a thing. 

A Side Note

In the previous article, I had you create a unit called uServiceLocator.pas that provided a central location for registering and resolving interface implementations. Since then, the Spring codebase has changed to provide a similar functionality.  The Spring.Services unit contains a singleton function ServiceLocator that is used for getting services (and indeed the call has changed from Resolve to GetService).  The Spring.Container unit contains a similar function GlobalContainer that is used to register the interface/implementation combinations.  All items registered into GlobalContainer are available for retrieval via ServiceLocator

A Little Review

One of the common things that happen in a constructor is the creation of other needed things.  In the past few articles, we’ve talked about the need to reduce dependencies by not creating things you need but instead asking for them in your constructor.  The reason that you don’t want to do much at all in a constructor – why you want to pass stuff in to it instead of actually creating things – is to limit what happens when you do create objects.  Consider this code:

constructor TOrderProcessor.Create;
begin
  FOrderValidator := TOrderValidator.Create;
  FOrderEntry := TOrderEntry.Create;
end;

This code looks pretty normal – you are creating some instances of classes you need to process an order.  But there are a couple of problems here that need to be avoided:

  • You are stuck with TOrderValidator.  That’s the only class that TOrderProcessor can use.  You can’t choose to use a different class or implementation.  That’s it. Same for TOrderEntry.
  • Not only are you stuck, but you are coupled to it.  If TOrderValidator changes in ways that you don’t like, you might never know.  Because you are using the unit that it is declared in, you might get careless and start calling other stuff in that unit.  Pretty soon and before you know it, your code is hopelessly joined to those other classes in ways that  may make it difficult or impossible to disentangle.  And being tangled up with another class is bad.
  • There is no way of knowing what a TOrderValidator does, creates, or otherwise allocates.  It could be in and of itself creating thirteen other classes, allocating huge blocks of memory, accessing a database or even firing up a nuclear weapon.  Who knows?  The downstream effects of merely creating TOrderProcessor class can be pretty much something out of your control  And it could change as other parts of the code is worked on by other team members. 
  • Along those same lines, you don’t know what will be left around after you use these classes. They might write records to a production database. TOrderValidator might go off and incur a charge of $0.50 at your credit card validating company.  (Imagine your boss getting that bill after you run your unit tests with this code a couple of thousand times….)  In the end, you are tightly coupled to those classes.  That is bad.

So we could use the Spring Container to have it so that we don’t even have to call Create on the helper classes:

procedure DoOrderProcessing;
var
  Order: TOrder;
  OrderProcessor: IOrderProcessor;

  OrderValidator: IOrderValidator;
  OrderEntry: IOrderEntry;
begin
  GlobalContainer.Build;
  Order := TOrder.Create;
  try
    OrderValidator := ServiceLocator.GetService<IOrderValidator>;
    OrderEntry := ServiceLocator.GetService<IOrderEntry>;
    OrderProcessor := TOrderProcessor.Create(OrderValidator, OrderEntry);
    if OrderProcessor.ProcessOrder(Order) then
    begin
      WriteLn('Order successfully processed....');
    end;
  finally
    Order.Free;
  end;
end;

 

Note that we are still calling Create on the TOrderProcessor itself, but we’ll show how to tell the Container exactly how to create our class in the next article.

So in this way, we are able to completely decouple the classes from each other, and we are able to ask the container for implementations.  Thus, if we wanted to, say, implement mock objects for these interfaces, we could easily do this by simply choosing to register mock classes against those interfaces instead of “real” classes.

Never Call Create

But  if we have to have to be really careful about not doing too much stuff in a constructor, how about just not having a constructor at all?  How about if we had a way of initializing everything that needs initializing while merely relying on the default constructor from TObject?  Impossible you say?  To that I say – bah!  Let’s do it! 

I should note that often a class’s constructor will require other assignments to integers, strings, and other non-class types.  That will, of course, require a constructor, but the point here is to illustrate that you can decouple your classes so much that you don’t even have to create them.

Getting Rid of the Constructor with Field Injection

Field injection is the solution for getting rid of constructors altogether.  Field Injection is the ability to inject the implementation of a dependent class directly to a field reference without actually calling Create manually.  The Delphi Spring Framework provides two ways for doing field injection.

Consider the following class declaration:

type
  TOrderProcessor = class(TInterfacedObject, IOrderProcessor)
  private
    [Injection]
    FOrderValidator: IOrderValidator;
    FOrderEntry: IOrderEntry;
  public
    function ProcessOrder(aOrder: TOrder): Boolean;
  end;

Note first that the class has no constructor.  It still contains references to the two internal interfaces that we saw above, but there is no formal constructor.  The second thing to note, of course, is the [Injection] attribute.  This is the key here.  This attribute tells the Spring Framework – “When you first encounter this identifier, go to the Container and grab the implementation for that interface and assign it. “ Basically, it tells Spring to do everything for you, including creating an instance of the implementing class for the interface. 

Thus, for our TOrderProcessor class, we can have no constructor, but freely use the interfaces declared as private fields:

function TOrderProcessor.ProcessOrder(aOrder: TOrder): Boolean;
var
  OrderIsValid: Boolean;
begin
  Result := False;
  OrderIsValid := FOrderValidator.ValidateOrder(aOrder);
  if OrderIsValid then
  begin
    Result := FOrderEntry.EnterOrderIntoDatabase(aOrder);
  end;

  {$IFDEF CONSOLEAPP}
    WriteLn('Order has been processed....');
  {$ENDIF}
end;

The above code will run just fine, despite the fact that at no time does the code itself ever explicitly create a class for the interfaces. 

But wait, you say – what about FOrderEntry?  It doesn’t have the [Injection] attribute.  You are right.  Instead, we do field injection directly as part of the interface/class registration process.  In the initialization section of the declaring unit, the registration looks like this:

initialization
  GlobalContainer.RegisterComponent<TOrderProcessor>.Implements<IOrderProcessor>.InjectField('FOrderEntry');

 

At the very end, you’ll notice that there is a call to InjectField(‘FOrderEntry"’); which tells Spring the same thing that the [Injection] attribute does.  In fact, the [Injection] attribute actually invokes the very same code to ensure that the reference is correctly assigned.  (You can see the whole unit here in BitBucket).

So there, we did it:  We created a useful class that uses two other classes and we didn’t create anything and we didn’t couple anything to anybody.  Pretty nice, huh?

Conclusion

Okay, so now we are able to write classes that is so decoupled from each other that they don’t even have to create instances for use!  We used Field Injection to automatically get references to objects that implement our interfaces without doing anything at all.  These classes are so decoupled that you don’t even have to include the units that implement the classes in any uses clause other than your application’s *.DPR file.  And as we said at the start, “Decoupling is good and coupling is bad”.  (If I didn’t say that, I should have, right?) 

Gateway Ticketing Needs Developers

By Nick at September 12, 2011 10:05
Filed Under: Delphi, General, Software Development

My company, Gateway Ticketing, is hiring. Things are going really well, and we need to expand what we are doing. We are looking for developers -- Delphi developers specifically, but we are mostly interested in smart people that know what they are doing when developing high-quality software.  We love Delphi and C#, but in the end, those are just languages and we know that it doesn’t ultimately matter what tool you know, but whether you really know how to write clean code.

We also need Automated Test Engineers who want to help enhance our products  to be the highest quality software in the business.

Here are some reasons why you should consider working for Gateway:

  • We are a great place to work.  I love it here.  That this is a great place to work was so obvious to me that I moved my whole family clear across the country to join this team. 
  • We are serious about being serious about software development.  We aren’t messing around here.  While we have a large legacy code base, we are all about doing the right thing the right way with the right tools.  We insist on unit tests for your code.  We insist that you keep up with the latest innovations in writing code.  We insist that you view coding the same way that Rembrandt viewed painting.   We are not messing around here.
  • We love Delphi, and we live and  breathe it here.  We are doing cool things like using the Delphi Spring Framework and other fun stuff.
  • We use C# and ASP.NET for our eCommerce solution and all the cool stuff that goes along with that.
  • We are located in beautiful Boyertown, Pennsylvania.  This a great place to live and raise a family.  We are close to everything but have that great small town feel.  I love living here, and you will too.
  • Our customers are some of the greatest and most fun places on earth.  We sell systems to the largest amusement parks, zoos, water parks, and museums all over the world.  This is a cool industry.  Who doesn’t love a good amusement park?

Okay, look – everyone says they want to hire “rock-star developers”.  Shoot, even we do it.  That’s all well and good, but the bottom line is that we are setting our standards really high.  And if doing that scares people off, well so be it.  We don’t want people who are scared off by high standards.  We want people who are looking for places with high standards.  We expect and demand your very best – anything less and you should find a job writing VB code. We really are creating a world-class place to build software, and we want folks like you to be a part of it.  You are up for that, right?

Relocation assistance is available.

And of course, here are the obligatory caveats.  We are definitely looking for people to live and work here in the Eastern Pennsylvania/Greater Philadelphia area.  We aren’t currently considering remote workers.  Naturally, you must be eligible to work in the United States We can sponsor H1B visas.  We don’t care where you are from or who your parents were or what color your dog is or anything like that.  We are really only interested in what you can do.  And of course, we want you to know what we can do for you, too.

If that sounds like something good to you, please contact me.

Limiting Scope

By Nick at September 09, 2011 16:02
Filed Under: Software Development, Delphi

As a general rule, developers should limit the scope of variables as much as possible.   Keeping the notion of limiting scope in every way possible, from the big things (never, ever, ever use global variables)to the subtle little things a language can do (declare const parameters whenever possible) all can contribute to clean, easy to test code. 

Limiting scope has all kind of benefits.  First, limiting scope of a variable reduces the number of places that a given variable can be modified.  The reason we rightfully abhor global variables is there is no telling where or when a given variable might be changed.  A global variable hangs out there like that last donut in the break room.  You know you shouldn’t touch it, but oh my, it’s so tempting, and it’s so easy to just grab that variable and use it for whatever you need to do.  Limiting the scope of a changeable thing reduces the chances that it will be changed in a way that it shouldn’t be, or worse – in a way that you don’t even know about. 

Limiting scope is also, by definition, a main feature of object oriented programming.  Encapsulation is probably the first thing you thing of when you thing of OOP, and it’s basic purpose – it’s whole reason for existing, really – is to formalize the process of limiting scope.  They don’t call it “information hiding” for nothing.    The term “information hiding” really means “Hide the scope of your variables so much that they can’t be changed except in the exact way you let them be”.  Encapsulation enables you to ensure that data you don’t want exposed isn’t exposed.  And if it isn’t exposed, it can’t be changed.

Limiting scope also limits the ability for people to depend on code that they shouldn’t be depending on.  Loose coupling – the limiting of the dependencies with in a system – is a good thing.  Tight coupling is a bad thing.  Limiting scope makes it harder for one class to latch on to another class and create dependencies that make code hard to test and hard to maintain.  It also makes it harder for changes in one area of code to have secondary effects in other, coupled areas.  There is nothing worse than changing code in (metaphorically speaking) New York City, and having that change cause a bug in code all the way over in Los Angeles.  (This is commonly called “Action at a Distance” and is something that should be avoided like a bad burrito.)  

There are big, well known ways of limiting scope – objects, making a variable local to a method, etc. – but there are a lot of smaller, more subtle ways to limit scope as well.  I’ve tried to list a number of ways that you can limit scope in your Delphi code:

  1. No global variables.  None.  Zero.  -- This one isn’t so subtle, but it’s really, really important.  It’s really easy to make sure that you never ever declare a variable as global.  In Delphi, you can do it, but you never should.  In languages like C# and Java, you actually can’t, strictly speaking, declare a global variable – everything has to be in a class -- but you can create a field on your main class that is pretty much the same thing.  Delphi is more flexible and will let you declare a global variable.  But just because you can doesn’t mean you should.  So don’t.
  2. Don’t create anything. Instead, ask for what you need.  This topic is a big one unto itself and gets into the question of dependencies and dependency injection.   But if you try to never actually create anything in the constructor of your class and instead, pass the constructor existing instances of what it needs, you can limit the scope of a given class.  Better yet, if you use a full blown dependency injection container, you can very severely limit the scope of your classes and still benefit fully from their functionality. 
  3. Put everything you can in the implementation section of your units.  The implementation section is the friend of a Delphi developer trying to limit scope.  Things in an implementation section can’t be seen outside the unit. If you can put a unit name in the implementation uses clause, do it.  If you can declare a class definition in the implementation section, do it.   Putting something in the implementation section of  a unit ensures that it scope doesn’t expand beyond that implementation section. 
  4. If a variable can be local to a routine, do it. This goes along with “No global variables ever”, but it needs to be said. If you can declare a variable in the scope of a single method, do it. 
  5. Use constants whenever possible.   If you are never going to change the value you assign to a variable, why make it a variable at all?  Get in the habit of making something a constant, and then only making it a variable if it needs to be.  Do this even inside your methods. 
  6. If you can declare a parameter as const, do it.  A const parameter can’t be changed, and thus declaring it as such means you are limiting its scope. 
  7. If you can make a variable private, do it.  If you can’t, make it protected. If you can’t do that, make it public.  Only make something published if it has a very specific reason to be.  This one is a little trickier, because there are OOP principles to be considered.  But generally, make field variables private, and give access to them through protected members.  This way, while the data can be changed,  the actual storage device itself is not directly accessible.  In addition, you can control the ability to change the internal data through a setter method.
  8. Provide notification systems in your setters to monitor changing data.  Sometimes, you might have data that needs to be changeable, but is sensitive for some reason.  As as result, you want to perhaps monitor and maybe even prevent the changing of your internal data.  You can use something as simple as an event in the setter method, or something more robust and flexible as the Observer pattern. 
  9. Don’t reach into another class.  Or even better, don’t create classes into which someone else can reach.  This gets into the Law of Demeter, which I’ve discussed before

That’s just a list I came up with this week while working on this post and thinking about this topic.  What are other little methods and techniques that you all use to limit the scope of your variables?

The Iron Triangle and Quality

By Nick at August 16, 2011 02:28
Filed Under: Software Development

More from my Embarcadero Blog.....


Another great article called "The Iron Stool" by Jeff Atwood, and on a topic near and dear to my heart these days.

I talk a lot about quality when I’m on the road and visiting with customers.  I consider the quality of the product to be the #1 feature going forward.  When I talk about "quality", I’m talking about speed, performance, and stability all wrapped up into one thing.  I know that no matter what the feature set for a given release, if the perception is that the product lacks quality, it will not be as well received as it might otherwise have been.  You all have been very clear that quality is important, and we are taking that very seriously.

Jeff’s article talks about the classic "Iron Triangle"of Time, Resources, and Features and how they interact to limit what you can do on any given software project.  Increase one, and the other two are affected.  Decrease Time, and you get fewer features.  Increase Resources and you get more features.  It’s a constant tug and pull between the sides of the triangle.  You have to keep the triangle balanced.  You can’t pad up features without adding in more resources or more time.

Well, actually, you can, right?  You can add features to a project, without increasing time or resources.  But of course, when you do, something else has to give, and that something is quality.  Give people a fixed feature set, limited resources, and a set date to finish, and you’ll probably get the product — but at the cost of that quality of the thing delivered (assuming that the time constraint is limted, of course).

Jeff then point’s out a co-workers analogy that it can be compared to a three-legged stool.  It took me while to figure out what she meant, but I stewed on it a while until I realized that if you shorten one or two of the legs of the stool, the "quality" of your sitting experience will be less than perfect.  To maintain a good sitting experience, you have to keep all three legs balanced.

But I don’t agree entirely with that analogy, because if you expand time, (that is, increase the amount of time allotted to complete the features even with fixed resources), you’ll get more quality.  Increased time is the one thing that should almost always improve quality.

One of the commenters to the post pointed out that some people view Quality as the area of the triangle. Pull on the corner of any triangle, and it’s area will increase.  Push on it and it’s area will decrease.  But that breaks down because adding more features will not help quality – doing so just creates more things to break and less time used up to test for and fix bugs.  Adding resources or time to a project will increase it’s quality, as long as the resources are added a the beginning.  Time can be added, well, any time.  ;-)

Another way to think about it is to make the three sides be Time, Quality, and Features.    Much of the time, resources are relatively fixed. That is the way we operate here — we have a team of developers, the size of which changes only marginally.  Brooks Law states that you should be less inclined to increase a team’s size the farther along the project is.  Since resources should only be altered very early in a project, Resources are to a large degree not a variable entity in the equation.  Features and Time are variables that can be adjusted much more easily along the way.

So it’ isn’t entirely clear how the "Iron Triangle" analogy holds.  I do know this — spend more time on quality and you’ll get quality.  And that is what we plan on doing for the Highlander release.

Greatest Blog Post Title Ever?

By Nick at August 15, 2011 03:51
Filed Under: Delphi, General, Software Development

Okay, more from my Embarcadero blog. This is kind of becoming a greatest hits combined with a trip down memory lane. I particularly remember this conversation-turned-blog-entry. It was the result of a late-night, late-in-the-development cycle conversation that had us all laughing very, very hard.


  • Okay — so I’m reading Steve Trefethen’s blog, and he links to what, in my personal opinion, is the greatest single title for a technical blog post ever —The Windows Shutdown Crapfest.  Doesn’t get any better than that.
  • So I read the thing, and it’s, well, amazing.  They have a whole team of people that do nothing but work on the Start menu.  That team had a whole team of people that works purely on the Shutdown experience. 
  • This fact above led to a discussion here on our release team about whether there is one guy on the C# compiler team who works only on the opening curly brace feature.  Does he have pair programmer that works purely on the closing brace?  When they work together, do they have to face each other? Does the Opening Curly Brace guy always have to sit on the left of the Closing Curly Brace guy? And what if Opening Curly Brace guy wants to keep working, but Closing Curly Brace guy wants to go home?  Does this result in a syntax error?  I have to know these things.
  • Now, if you think the above sounds ridiculous, then I think you’d should actually read the whole article.  It’s an amazing tale of Kafka-esque development processes.  Dude had to wait up to three months for his code to actually reach the product. 
  • And I thought that we had a convoluted release process here.
  • Yes, we are getting a little giddy.

(Note: this blog post was written by a committee).

Ten Things That Really Bug Me

By Nick at August 09, 2011 14:13
Filed Under: Software Development, General

I found this on my Embarcadero blog from 13 April 2009.  I wanted to preserve it here…


I was cleaning up my hard drive and I found lying around in an old HTML file.  The date on the file was from April of 2006, before I came to CodeGear.  I can’t remember if I ever put this up on a blog somewhere, but I thought it was a pretty good rant, so I’m posting it here. :-)

  1. Message boxes that ask a Yes/No question, but give you Ok/Cancel buttons. I mean, come on. If you are asking a "Yes or No" question, how tough is it to tell the dialog to have Yes and No buttons? Not tough at all, that’s how tough it is.
  2. Ok buttons that are enabled when a dialog is not properly filled in.   This is basic User Interface design. If pushing a button will result in an error message, don’t let the user push the button.
  3. Non-sizable dialogs.  Argh. This one drives me nuts. It’s especially galling when there’s a list box or something that is so small you feel like you are looking at it through a straw.
  4. Dialogs that don’t remember their size and position. Related to the previous item. Sometimes a dialog is too small, and when I size it, I want it to stay sized. Sometimes it blocks stuff I want to see. It should stay where I put it.
  5. Windows that insist on putting themselves in front when I am doing something else. This is absolutely, unequivocally the most irritating thing about Windows. I decide what I am looking at, not some shareware programmer from Wisconsin. If I am typing or otherwise working in a Window, no other application should ever be able to steal the focus, unless it’s warning me that my house is on fire or something.
  6. File directory trees the size of postage stamps. Related to the issue above. Ever get one of those slightly older applications that won’t let you size the directory lookup tree? With ever expanding hard drives and increasingly complex file directory structures, looking at your harddrive through a fixed size treeview that’s only 150 pixels square feels like being shoved in the trunk of a Yugo.
  7. Crappy error messages, especially when they are sentences and don’t end in a period. "Item not found". Great — which item? The name or even type of the item has got to be known by something in the app, otherwise, how could it be looked for?  Tell us for crying out loud! Or how about the old favorite "Error 332322". This isn’t a problem for me personally because I have, of course, memorized all the error codes for your application.
  8. CAPSLOCK keys. The person who thought putting the CAPSLOCK key above the SHIFT key and right below the TAB key should be rubbed vigorously with rough sandpaper and then placed in a bathtub full of lemon juice. [Ed:  Solution can be found here]
  9. Unnecessary modal dialog boxes that I have to click when it doesn’t make any difference. I love these. "You’ve done something really stupid. Press Ok to continue". Great. Thanks. I couldn’t have made it through the day without that totally, utterly meaningless and pointless message.
  10. Dialog boxes that have the negative answer on the left and the positive answer on the right. OK buttons go on the left. Cancel buttons go on the right. Don’t put the Delete button on the left and the Approve button on the right. It’s a gross violation of the laws of nature.

Nick’s Public Code Repository Update

By Nick at August 09, 2011 05:42
Filed Under: Delphi, Software Development

Some of you may remember the TextScrubber project I was writing about back on my Embarcadero blog.  (I’ll update that page really soon, like today…).  I’ve made two changes with that project:

  1. I’ve updated it to allow you to set it to run automatically on Windows startup.
  2. I’ve moved the repository from SVN and SourceForge over to Mercurial and BitBucket.

Now this may be a bit of an inconvenience to some of you, and I apologize.  First, if you don’t have the Mercurial command line tool installed, you should.  I’d venture to say that if you don’t have at least the command line tools for SVN, Git, and Mercurial installed, you can’t really call yourself a  true developer.  Second, I’m a Mercurial guy, and BitBucket is Mecca for Mercurial guys.  So you can get the code there.  Third, since I am now a Mercurial guy, SourceForge is no longer my cup of tea.  I’m going to move all my code there over to BitBucket.  (Note – this will not include the TurboPower projects, which I don’t consider “my code”….). 

My intent is to make my BitBucket page a central location for my code. I’ve created a “NickDemoCode” project to publish code I use to demonstrate things.  I’ve got a couple of other small projects there as well. I’d like to do what Marco did and have it be part of nickhodges.com, but I can’t seem to figure out how to do that.  (Anyone have any ideas? My ISP is pretty unhelpful, and this is not my area of expertise….)

So, if you are into great, awesome code, I’d recommend checking for updates to my public repository every 15 minutes or so.  You don’t want to get left behind.  Winking smile

Flotsam and Jetsam #40

By Nick at July 27, 2011 07:50
Filed Under: Delphi, Flotsam and Jetsam, Software Development, TechBiz

Getting Giddy #4 Fixed

By Nick at July 10, 2011 11:52
Filed Under: Delphi, General, Software Development, Unit Testing

Okay, so I was getting all these emails about the fourth article in my “Getting Giddy” series of articles.  You guys kept saying it was missing and I kept saying “Hey, it’s right here!”.  And then finally I noticed – #4 and #5 were identical.  I must have done something stupid somewhere.  Well, I was able to track down the original article on my hard drive and restore it.  So now, the fourth article is as it should be, and all seems well with the universe.

Sorry for the confusion, and I appreciate the interest that these articles have generated.

My Book

A Pithy Quote for You

"There are no such things as limits to growth, because there are no limits to the human capacity for intelligence, imagination, and wonder"    –  Ronald Reagan

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.