Amazon.com Widgets November 2011

One Right Thing at a Time

By Nick at November 24, 2011 13:44
Filed Under: Delphi, General, Software Development, TechBiz

Wherein I discuss how to do things that you should be doing and how not to do things that you shouldn’t be doing….

Sometimes you tweet something and it makes sense to you, but then you realize that it also kind of begs for more discussion. 

For instance: “Things move so quickly that doing the *one* most important thing means it's less likely that you'll do the wrong things in the long run.” 

I thought that a little more explanation would be in order.  Let’s say you have ten cool features on your “Things Customers are Screaming For” list.  There are two basic approaches you can take to getting them done: You can do them in series or in parallel.  If you do them in parallel, you’ll get them all done sooner, but you may not get them done as thoroughly.  If you do them in series, it will take you longer to do them all, but you’ll likely get each one done more thoroughly.

However, doing them in series – that is, sequentially doing only the most important remaining item – has an added benefit:  It can help you not do things that you shouldn’t do.  You may have ten things on your “We need to get these done right away”, but as time passes, some of those things may prove to be not needed, overtaken by events, or just plain dumb ideas.  Doing things in parallel may mean that you get everything done sooner, but it also means that you might do something that proves to be a waste of time later on.

For example, if you have a team of five folks, and you have five ideas that take six man months each, you might give each person one idea to work on, and then six months later, you have all five ideas done. Great!  But uh oh! -- as it turns out, over the course of those six months, things changed and events transpired in such a way that two of the ideas weren’t really good ideas after all, and at the end of the six months you regret ever starting on them.  So in the end, you have three things done that needed doing, but have wasted your time on two ideas that you should have left undone.  Furthermore, since you only had one person working on each idea, you may not get a fully fleshed out solution, but instead, one that may have missing features or is not complete in some way.

But consider what happens if you work on them in series: say that instead of starting in all at once on the entire list,  you pick the single most important of the ideas on the list.  You focus your whole team on doing that one idea.  You will likely be able to get it done somewhat sooner, say in one or two months instead of the six months in our example. (Five team members working on a six man-month project will likely take a bit longer because of transaction costs.)  In addition, you will get a “five-headed” solution instead of a “one-headed” one, and thus the solution would likely be more complete, fleshed out, and feature rich.  In other words, you might very well end up doing one thing properly and thoroughly instead of doing five things not so completely. 

The added benefit comes when, after doing the most important project, you realize that one of the ideas you had originally thought was awesome isn’t really that awesome, and that you can take it off the list and not waste time on it. You might add another item to the list, or another item that was on the list suddenly becomes vastly more important than it was at the start of the first project.  Instead, you can repeat the process and start working on the next most important thing.  You end up with a very nice implementation of each project you do undertake, and you don’t do the projects that shouldn’t be done.

In a rapidly changing technical environment, that which looks like a no brainer in January might be old news by July.  Obviously you want to avoid working on that project.  A practical example might be that you are a software tools vendor, and people are pressing you to do, say, a development tool for Windows Mobile 6.  You could choose to add staff and get that request done sooner, or you could stay the course and do more important things, only to discover with massive relief that you didn’t do Windows Mobile 6 at all when Windows Mobile 6 becomes a legacy technology.  (Sound familiar? Smile

Now, I’ll grant that if you follow this plan, you’ll end up with fewer features in the long run.   But you’ll also end up with more complete features with less wasted effort.  You won’t have spent time on things you ultimately should not have.  It might take a little longer to get any particular feature to market, but in the above example, you’ll end up with three really solid features and no time spent working on things that you should not have worked on at all instead of five half-baked features, two of which were a waste of time.

Repeat this process enough, and it becomes much more likely that you will end up with a product that has the right – and fully rendered -- feature set.  In many ways, inefficiencies are the result of choosing to do the wrong thing.  If you keep your choices finely grained – that is, always put your efforts only into the things that are obviously the very most important thing to do do right now – you will end up doing the right thing every time, even if there is slightly less of it. 

It’s often been said that knowing what you should do is easy; it’s knowing what you shouldn’t do that’s hard.  If you repeatedly focus on and complete the one single thing you absolutely should do and do it well, it will be more readily clear what those things are you should not do. So, I guess ultimately, you have to choose: More features done less thoroughly with time spent on things that turn out to be a waste, or fewer, more complete features with fewer projects that you shouldn’t have done.

Flotsam and Jetsam #50

By Nick at November 23, 2011 03:32
Filed Under: Delphi, Flotsam and Jetsam, Software Development

Flotsam and Jetsam #49

By Nick at November 09, 2011 04:46
Filed Under: Software Development, Flotsam and Jetsam, Delphi
  • Hallvard Vassbotn has been sighted in the wild! Hallvard is an amazing developer and a great writer, and I’m delighted at the prospect of him starting to blog again, especially given his propensity to stretch Delphi language and RTL features to the limit.  Given all the new things that have happened in these areas since Hallvard’s last blog  post, one can only hope for really interesting stuff.
  • Fun to see people taking up the Dependency Inject mantle – here’s an article by Yanniel Alvarez Alfonso on a simple example of DI using DelphiDean Hill has a very good article about Software Flexibility that discusses how Dependency Injection can make your software more flexible and adaptable.   If my efforts have sparked an interest in Dependency Injection, I couldn’t be happier.  I’ll say it again:  If you aren’t using even the most basic form of Dependency Injection, then you are doing it wrong.
  • ninite.com is a really cool site that provides a valuable and helpful service.  It allows you to create a single install for a pretty broad and selectable collection of popular software.  This is particularly useful when setting up a new machine.  There’s always a million of these things that you want to install – Skype, Chrome, Firefox, your favorite IM client, media players, various utilities, etc. --  and Ninite.com allows you to select all of these and get a single installer for them all.  It does all the “smart” things that you want it to like get the 64-bit version if possible, ensures you have the latest versions -- and best of all -- it clicks all the “Next” buttons so you don’t have to.  Sweet.
  • I tweeted this notion this week -- “Crazy Idea of the Day: Every class that raises an exception unique to itself should have it's own exception type to raise. “ – and I thought that I’d expand a bit on it here.  One of my pet peeves is unclear error messages.  Somewhat of a corollary to that is the irritated feeling you get when an exception is raised, but you can’t tell right away where it came from. Thus was born the notion above – that if your class is raising an exception unique to itself (i.e., not something “normal” like EConvertError or EFileNotFoundException or something like that….) it should be raising an exception type defined specifically for the class itself.  This way, you can put a very descriptive error message in the exception, and the developer or user seeing the exception can know exactly where it came from. In addition, it allows anyone using  your class to easily trap exceptions specific to your classes.  I’ve been doing this for years, but have never seen anyone in the Delphi community really discuss it.
  • Every once and a while, I like to remind folks that they can go to the Delphi UserVoice page and vote for their favorite new features in Delphi.  This is totally unofficial, but it is interesting.  I’m still an admin there, so it’s always fun to mark items done as they get shipped. (I confess that it is also fun to close and/or reject requests that are……. not well thought out…?)  Currently, this item – “Better GUI separation and abstraction” -- is the top voted thing on the whole site, and I’m wondering if that really is indeed what the Delphi community wants the most.  In any event, you can certainly go there and vote and perhaps influence the future of the product. 

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. 

My Book

A Pithy Quote for You

"Good judgement is the result of experience ... Experience is the result of bad judgement."    –  Fred Brooks

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.