Widgets Delphi

Flotsam and Jetsam #55

By Nick at February 08, 2012 09:02
Filed Under: Flotsam and Jetsam, Delphi
  • Marco notes that Embarcadero has put out a press release announcing a 54% increase in revenue in 2011 over 2010.  This is unequivocal, clear, unassailable good news.  No amount of Chicken Little whining will take away from the fact that this is very, very good news.  (It didn’t take long for Marco’s commenters and the Nattering Nabobs of Negativity in the non-tech newsgroups to try to find a way to make this something other than great news.)  The most important thing that the EMBT Executives care about is the bottom line – and that is how it should be.  And the bottom line for Delphi apparently looks pretty darn good – good enough for them to brag about it.  When the bottom line of Delphi looks good, that is good for Delphi developers. 
  • Hey, I noticed that I’ve gone over 1000 comments here on my blog (actually it’s more like 3000  if you count spam that I’ve deleted.….).  Thanks to everyone who posts comments.  I appreciate you reading this stuff I write, especially when you go to the trouble of writing something up and adding to the conversation.  Lately some of the discussions on my technical posts have been really good – I’m grateful.
  • I am not myself able to go this year, but I’m quite happy that three of my team here at Gateway Ticketing will be attending Delphi Developer Days this April in Baltimore/Washington, DC.  I was there last year, and I can tell you that it was a really valuable experience, and I recommend that you attend this year if you can.
  • Jason Southwell’s ApeSuite for FireMonkey has a new beta out with a bunch of new features.
  • More FireMonkey components are now coming from TMS Software as well – they have a cool set of instrumentation components as well as a TableView control that will be popular for folks writing mobile apps in particular.
  • And Even More FireMonkey: As previously noted, I haven’t played with FireMonkey  much, but I have to confess, it is cool to think that this demo app – as described by Anders Ohlsson in his EDN article – is written in Delphi and will run on the Mac (and even iOS I guess…?) as well as on Windows.  Pretty slick.  And while you are at it, check this one out as well.

…Wherein I Rant Vigorously About Mobile Twitter Clients

By Nick at February 04, 2012 15:23
Filed Under: TechBiz, Tech Stuff, General, Delphi

I am now going to go on a rant about Twitter clients – mobile Twitter clients in particular (though some desktop clients are rant-worthy as well).  I am going to do this because I can’t understand why they are such a pain in the ass and work so badly, when they could so easily work so well.

Okay, first, don’t get me wrong.  I really like Twitter.  (If you want, you can follow me, I’m @nickhodges --  no surprise in that handle, eh?)  I like it because it’s a great place to keep up on news, find interesting articles, read funny stuff, and to post your thoughts in short, pithy statements of 140 characters or less.  It’s also a great time killer.  If you are waiting at the doctors office, it’s a much better way to pass the wait than looking at a two and a half year old copy of People Magazine.  It’s interesting, fun, never the same thing twice, and frankly, I’m a little addicted.  I do almost all of my twitter reading on my phone or on my wonderful Amazon Kindle

But yet reading Twitter on my mobile devices drives. me. crazy.  When it comes to mobile Twitter clients, I’m not addicted -- I’m inflamed with a rage that burns like the heat of a thousand suns.

I’ve tried just about every one out there. They all drive me insane.  And so here is  my rant:

  • A twitter client should never, ever, ever, under any circumstances, for any reason, at any time, ever, ever, EVER move my “cursor”.  EVER. And by “cursor” I mean my location in my Twitter stream.  I determine where my cursor goes, not you, you blasted twitter client that thinks you can just show me whatever you want when you want to.  If I am reading Twitter on my phone, leave off on a funny Pauly Peligroso post, go away to another app, and then I come back, you darn well better have my twitter client looking right at that same stinking Pauly Peligroso post when I come back.  I don’t care if I’ve been gone for five minutes, five hours or five years, you flipping better have your cursor right there where I Ieft it. Not anywhere else.  Where. I. left. it.  Leave a gap if you have to. I don’t care, just leave it. Don’t try to do me a favor and “catch me up”.  If I need catching up, I’ll get myself caught up. Give me an option to get caught up, fine.  But for the love of Adam Sandler, DON’T MOVE MY POSITION IN MY TWITTER STREAM.   Ever,  ever, ever, never, ever, ever. 
  • Second, if you tell me that there are “143 new tweets”, and I say “Great, some new tweets”, put me at the freaking START of the 143 new tweets, not at the current time!!!!   Why in the name of sweet baby Dick Van Dyke would I ever, ever, ever what to start at the most recent tweet out of those 143 new tweets? Why would you tell me that there are 143 new tweets and then start me out at the point where there are zero new tweets? Why do I open up the fracking client and see some tweet from three seconds ago, when I want to read the 143 new tweets?  Why do I have to manually scroll down and try to figure out where the new tweets start?  What is that, some kind of sick, twisted joke?  Really?  I have to scroll?  Seriously?   I mean this is basically a variation of the “Never move my cursor spot”, but come on, this is ridiculous.
  • Third – stop trying to shorten my shortened URL’s.  I’m smart – I can shorten my URL’s myself.  It’s nice you want to do that for me, but at least let me opt out of it.  Nothing says “wasted time and resources” as a link that is a Twitter shortened version of a link that started out as a link.  I mean, come on, I can keep my twitter posts under 140 characters myself.  I don’t want your help.  I don’t need your help.  Stop it.

Bottom line: Mobile twitter clients stink and they make me want to bash public monuments with a sledgehammer. (I’d never do that, really, but I want to when I go back from checking my mail and the stupid TweetCaster moves me to  a tweet that was posted 23 seconds ago.)

Phew, okay, I feel better now.

An Interface Implementation Pattern for Consideration

By Nick at February 03, 2012 14:42
Filed Under: Delphi, Software Development

So I’ve been writing about Interfaces, and mostly talking about how you should use them.  But as important as designing and using the interfaces themselves is how you implement those interfaces.  I talked about the basics in the previous article, but there are some things that you can do to make implementing an interface a little easier.

I’d like to show one way that you might go about it for the purpose of starting a discussion about the technique.  I’ve seen the method I’m going to describe below used in a number of places, most notably back in WebSnap. (Remember that?  WebSnap was actually a pretty cool library of code, doing a lot of things in a somewhat MVC fashion  before MVC and web development was in, well, fashion.)

Anyway, here is how the implementation pattern I’m talking about here works:  You create a “base” class that implements each member and property of the interface. Then, you add a virtual, abstract method that corresponds to each interface method with a naming convention of DoMethod.  You then call that virtual, abstract method inside the implementation of the interface methods. 

This base class then becomes the parent for any class that implements the interface.  In essence, you create an easy-to-inherit class that easy implements the interface so you don’t actually have to worry about implementing the interface over and over again. 

Naturally, this is hard to explain, so a code example is in order.

Consider the following simple interface:

  IDemoInterface = interface
    procedure ProcessSomething;
    function ProcessData(aString: string; aInteger: integer): Boolean;  

Nothing fancy, and obviously illustrative. 

To do what I’m talking about, you’d implement this interface as follows:


  TBaseDemoInterfaceImplementor = class abstract(TInterfacedObject, IDemoInterface)
    procedure DoProcessSomething; virtual; abstract;
    function DoProcessData(aString: string; aInteger: integer): Boolean; virtual; abstract;
    procedure ProcessSomething;
    function ProcessData(aString: string; aInteger: integer): Boolean;

procedure TBaseDemoInterfaceImplementor .ProcessSomething;

function TBaseDemoInterfaceImplementor .ProcessData(aString: string; aInteger: integer): Boolean;
  Result := DoProcessData(aString, aInteger);

So, what you have now is a class – TBaseDemoInterfaceImplementor – that can be used to really implement the functionality of the IDemoInterface.  You have an abstract class to inherit from, and two methods to override to implement the functionality. 

So, of course, the class that you’ll actually use would look something like this:

  TRealDemoInterfaceImplementor = class(TBaseDemoInterfaceImplementor)
    procedure DoProcessSomething; override;
    function DoProcessData(aString: string; aInteger: integer): Boolean; override;

function TRealDemoInterfaceImplementor.DoProcessData(aString: string; aInteger: integer): Boolean;
  ShowMessage(Format('I am processing the following data: %s and %d', [aString, aInteger]));
  Result := Random(2) = 1;

procedure TRealDemoInterfaceImplementor.DoProcessSomething;
  ShowMessage('I am processing something!');

What happens is that the implementation becomes much less painful once you have the base class defined with the details of implementing the interface neatly tucked away.  You are doing simple class inheritance at that point. 

Now I’ve thought about this pattern for a while, but I’m not sure about it.  I’m very interested in hearing what you all think.  I guess one downside is that the class doesn’t clearly declare that it implements a given interface.  Perhaps a naming convention would do that? 

On the one hand, it seems a nice way to create a class library that implements an interface.  To me, it seems like a good use of polymorphism. There may be times when you want a large chunk of your library to implement a “basic” interface, and using this inheritance trick can make that easy.  Once you create a base class, you can now build a class hierarchy based on that class, with all the classes implementing the interface with much less hassle and more cleanly.  In addition, it makes it easier to create any number of descendants  from the base class if you want to have a number of different implementations for the interface.  For instance, if you had ICreditCard, you might create TBaseCreditCardImplementor, making it easy to descend from and create TVisa and TMastercard, etc. 

Pattern? Anti-pattern?  Maybe I’m crazy and this is a really silly idea.  Maybe this is a known pattern already and I’m just ignorant.  Maybe this is the coolest idea ever. 

What do you guys think?

Okay, So When Should You Call Create?

By Nick at January 30, 2012 14:27
Filed Under: Delphi, Software Development

Okay, I want you all to notice that in my previous post about the use of Create,  I was pretty careful not to say “Never call Create”. And near the start I said “For the most part”. So let’s be clear – just as I didn’t say “Never ever call FreeAndNil”, I’m not saying “Never call Create”.  And while I am at it, I didn’t say “Use interfaces everywhere” either.  Those of you who are accusing me of saying so are wrong.  Incorrect. Inaccurate.  You should be ashamed and you should correct yourselves. You should also read more carefully and think more precisely.

Enough about what I didn’t say.  What am I saying?  I’m saying “Architect your code so that you avoid calling Create, because doing so causes problems”.

Problem number one is that your code becomes difficult to test.   This is a fact:  When you call Create – when you create more than just an instance of a specific instance of a specific class – you are tightly coupled to that class and it’s entire dependency graph. (If you don’t know what a dependency graph is, you can find out more here.)  Some classes have huge dependency graphs.  That is, the creation of that class cause a cascading of creation of other classes which can initiate any number of things:  Connections to databases, locking of files, attachment of limited resources like turnstiles or cash registers – who knows what? 

Classes that have dependency graphs are classes that should not be manually created, but instead should be created by a class that can control if and when that class is created.  The creation of such classes should be definable and controllable.  They should be referenced by an abstraction and they should be created in a configurable way.  If you want to test the dependent class, then you can have your system create a mock instead of the real thing.  If you call Create on that class, you can’t do that. 

How should we refer to these types of classes – classes that have dependency graphs of any sort?  Let’s refer to them as “complex classes”.  (I looked for the commonly accepted term here, and couldn’t seem to find one.  I haven’t the slightest doubt that one of you will tell me what the “right” term here is. I’ve seen the term “volatile” used, but I don’t like that because of the keyword volatile that some languages use.) So for the purpose of our discussion, a complex class is one that has a dependency graph; it’s a class that, when created, brings in other external dependencies.  Sometimes those external dependencies are easy to define, and sometimes the dependency graph gets so complex it is hard to know what is happening exactly when that class is instantiated.  For instance, think of TForm.  When you create TForm, holy mackerel – a long, complex host of other things are being allocated – Windows handles, other VCL classes, fonts and this and that and the TKitchenSinkTForm is most definitely a complex class.

But, what about something like TStringListTStringList has, as far as I can tell, no real dependency graph.  Create one of those, and you really aren’t creating a host of external dependencies.  TStringListis basically self contained.  It is a known, limited entity. (Look at it’s constructor and the constructor of TStrings.  It basically doesn’t create anything, so it really can’t have any dependency graph.)  It can be created without worrying that you are going to end up calling some charge-money-every-time-you-use-it web service.  It’s simple, clean, and limited.  It’s not a complex class.  It’s a simple class.

So, to answer the question posed in the title of this post – you can (and should) call Create on what I’m calling simple classes.  Generally, these will be classes defined in the RTL that clearly are stable or simple in that they don’t have dependencies that are non-deterministic, unknown, or complex.  Classes like TStringList, TStringBuilder, TList, the classes in Generics.Collections.pas, and many others are examples of classes that you should feel fine about creating.  These classes are know and proven by virtue of being part of the RTL.  You probably have many similar classes in your own library – classes that you have bathed in unit tests so you know that they are isolated, stable, and simple.  You can determine the complexity of such classes by looking at the constructor of a given class.  (And note: The use or lack of use of Create in those classes indicates whether they are complex or simple.  Hmmm.)

You should feel safe creating such simple classes because you know that you aren’t dragging in the TKitchenSink when you create them.

So that should answer the question, eh?

Flotsam and Jetsam #54

By Nick at January 28, 2012 01:06
Filed Under: Delphi, Flotsam and Jetsam
  • I like FireMonkey.  Actually, I confess that I don’t know much at all about FireMonkey, but I like that it exists.  I don’t use it, but I like that it is there, broadening the appeal of Delphi and generally advancing the cause of the tool we all love so well.  So I was pleased to see that the nascent market for third-party FireMonkey controls continues to grow.  The latest offering is from Jason Southwell’s Arcana with the cleverly named “ApeSuite”.  ApeSuite is in beta, but you can get in early at a special price.  Jason has been updating the library pretty regularly. I’m glad to see people getting a good start on what will hopefully be a thriving marketplace, and I tip my cap to Jason for jumping in.
  • Alex Ciobanu – formerly of the Delphi RTL/VCL team – has made a few changes to his outstanding open source offerings.  First, his DeHL project has been discontinued.  I’m sorry to hear that – there are some really interesting things in there.   But second, he has done a brilliant job with a new project that is, to a certain degree,  a replacement, Delphi Collections.    He says it is “on hold” but it appears that he is actively working on moving it forward.  Alex is a really, really good programmer, so I keep a close eye on what he is up to.  His contributions to the Delphi community are very large, and I’m very appreciative of what he does.  Lots to learn there.
  • How to Get Your Comments Deleted:  This is my blog, and what ends up on on it is up to me.  I’ve noticed that some of you have been trying really hard, though, to get your comments deleted with a modicum of success – and I’ve been helping to make sure that you succeed in this endeavor when appropriate.  I thought that you all might want to know for sure how to get your comments deleted.  The best way is to be a jerk and write a content free but insulting comment that adds no value whatsoever.  Do that, and you’ll get your comment deleted.  Hope that helps.
  • Eric Grange pointed out that there has been a marked uptick in activity on open source projects involving Pascal.  It’s nice to see numbers attached to something that I’ve kind of felt to be the case.  The addition of generics and anonymous methods to Delphi really opened the language up to some really cool and really powerful frameworks, and things like Alex’s code above, the Spring Framework, Delphi Mocks, and all kinds of other frameworks.  It’s a really good time to be a Delphi developer.  (And Ohloh is a pretty interesting site – worth poking around.)
  • What and how things are named in our code is a really important part of being a good developer. That’s why I thought this post was interesting – “Interface naming: prefix 'Can-' vs suffix '-Able'”    We tend to create interface names with –able (ISerializable, IDisposable, IEatable, whatever….) and maybe that isn’t always the best convention?

Life is Too Short To Call Create

By Nick at January 27, 2012 09:52
Filed Under: Delphi, Software Development, Unit Testing


Okay, so the whole FreeAndNil thing has been going on for a while.  Some folks are understandably sick of it, but I’m not.  Winking smile I think it is an important discussion that actually reveals a much deeper issue – sort of like how a fight with your spouse over the toothpaste tube is usually really a fight over something deeper and more serious.

I think in this case, the “fight” (I don’t like that word for this particular case, but we’ll roll with the metaphor…) is really about the approach one takes towards memory management – specifically, how one views the role of class creation (and thus memory allocation) when writing code.  In my Dependency Injection Series (which I really need to continue…), I spoke about the notion of creating classes without constructors (other than the default one, of course).  In a sense, this post might be considered part of my DI series, because in this post I am basically making the case for using a Dependency Injection container.  In this post, I’m going to argue that for the most part, you should not call Create.  And you should design your code in such a way that you don’t need to call Create

Life Too Short?

Okay, so I was watching a terrific video by Neal Ford (a former Delphi guy, actually – ) in which he introduces the notions of and “way of thinking” behind Functional Programming.  It’s a great video, and you should watch it.  Near the end of it, Neal says something that I’ve been pondering a while:  “Life is to short to call malloc”. He doesn’t think he should have to worry about memory management anymore.   This somewhat provocative thought stream-lined with a notion I ran across as I was investigating and thinking about unit testing – the idea from Misko Hevery where he is deeply suspicious of the new operator, Java’s equivalent of .Create.  At first, this seems like a really weird notion, particularly since Delphi is a native language, and many Delphi developers appreciate the ability to control the lifetime of their objects and directly manage memory .  But I started to see the wisdom in it, and have finally come to agree with Neal – Life is too short to call .Create.  I don’t want to be spending my limited thinking and coding time worrying about memory, particularly since there are now frameworks and language features that can do this automatically.  In languages like Java and C# (among others), developers use garbage collection to manage memory.  We don’t have garbage collection in Delphi, but we do have ways of making memory management something that isn’t a huge concern. 

And hey, if you are a Delphi developer, and you want to completely control your objects lifetime manually, they hey, you can. More power to you.  But again, I’m going to show you how you can spend less time worrying about that and more time doing the things that we developers really are trying to do -- which is come up with solutions and products. 

This isn’t the first time that I’ve thought or mentioned all of this stuff:

I’m Lazy

First, I am not the sharpest knife in the drawer and I have a limited number of CPU cycles in my brain.  If I don’t have to, I don’t want to spend them doing repetitive “busy work”.  And calling the Create/Free cycle is, to a large degree, busy work.  We all do it – we carefully ensure that if we call Create, we code the try…finally block and call .Free.  If we create an instance class variable in a constructor, we immediately call .Free in the destructor.  Those are all good practices, and bravo to you for following them, but I think we’ve now gotten to the point where we don’t always have to do these kinds of tedious, wrote coding activities anymore.  If we can spend time thinking more about higher level solutions and less about lower-level intricacies, we are more productive.  (One could argue that the entire field of computer science has been nothing other than a giant march towards spending time on higher level solutions and away from tedious, low-level coding…)

Don’t Cause Dependencies

But that is more of a basic, low-level reason in itself -- the idea that you can save brain power.  There are some deeper technical and practical  reasons why you should eschew creating anything.  The first is that calling .Create creates more than just an object instance -- it creates a dependency.  If you actually create a class instance your self and use that class via a direct class reference, that is, do something like this:

procedure TMyWidget.DoSomeSprocketWork;
  SomeSprocket: TSprocket
  SomeSprocket := TSprocket.Create

you are dependent on that class and that class alone.  You’ve created an unbreakable dependency on that particular implementation.  You have to include that classes unit in your uses clause.  You’ve very tightly coupled yourself to a specific means of getting something done.   If you want to change it, you actually have to go and alter the code itself.  Yikes! If you want to test it, your tests have to rely on the entire dependency chain of TSprocket, and who  knows what the heck that entails?  And I hope we can all agree that tightly coupling yourself to specific implementations is bad, right?  (If we can’t, I’m afraid that we can’t be friends anymore.  Alas.)

As I’ve been preaching for a while now, you should reference classes and functionality via interfaces.  Interfaces allow you to, at the very least, reference specific a functionality rather than a specific implementation of that functionality.  But even in you use interfaces exclusively -- that is do something like the below instead of the above --

procedure TMyWidget.DoSomeSprocketWork;
  SomeSprocket: ISprocket
  SomeSprocket := TSprocket.Create

you are still creating a dependency on that particular class. Your uses clause still has to include the unit for that class, and your code is explicitly tied to that particular implementation.  Using the interface is a step in the right direction – using an interface makes you not have to worry about memory management – but you still end up with dependency on a specific implementation.  And we agree that a dependency on a specific implementation should be avoided, right? 

So, we agree that calling Create causes a hard-coded dependency and that it is bad.  And if you think about it, anytime you call create in one class, you create a dependency.  One reason such dependencies are bad is that it makes your code hard to test.  True and proper unit testing means that each class should be able to be tested in isolation.  If ClassA is irrevocably dependent on ClassB, then you cannot test ClassA without invoking ClassB.  You can’t easily provide a mock class for ClassB either.  Thus, a call to Create can make your code hard to test. 

Following SOLID

But there’s yet another reason to avoid calling Create – the ‘S’ in the SOLID principles.  The ‘S’  stands for the “Single Responsibility Principle” which is “the notion that an object should have only a single responsibility.”  If your class has a mission and it is creating stuff to do that mission, then it actually has multiple responsibilities – doing its mission and  creating stuff.  That’s two things, not one.  Instead, let your class do it’s main mission, and leave creating stuff up to another class whose main mission it is to create stuff.   Plus,  if you have dug into the SOLID principles, you know that the ‘D’ stands for the “Dependency Inversion Principle” which is the notion that “one should depend upon abstractions [and] not depend upon concretions.”  Or, as you might have heard me say say “Program against abstractions, not against implementations”.  (And of course, it wasn’t me that said that – it was Erich Gamma of  “Gang of Four ” fame.)

And where does that leave us?  Well, right back with not calling Create, and having a class whose specific, single purpose in life is to create stuff for you.  Sound familiar?  It should, we just described either a class based on the Factory pattern, or a Dependency Injection container. 

So, in the end, the code you’d write would end up looking like:

procedure TMyWidget.DoSomeSprocketWork;
  SomeSprocket: ISprocket
  SomeSprocket := SprocketFactory.GetSprocket;
  // Or maybe something like
  // SomeSprocket := MyDIContainer.GetImplementation<ISprocket>('Basic');

That way, there is no Create call, and thus you aren’t creating any dependency other than on the interface.  You get instances of your objects from a Factory or from a Dependency Injection container  -- and either one can produce any implementation you want or ask for without creating a dependency.   Either way, it gives you control over how the interface is implemented without coupling to that implementation. You could even add a parameter to the GetSprocket call to ask for a specific kind of Sprocket implementation, and even that wouldn’t cause you to be dependent on that implementation.  

In the end, calling Create merely causes a dependency, takes brain cycles, and violates the SOLID principle.  No wonder you shouldn’t use it much!

So then the question becomes, When should you call Create? Well, I’m glad you asked. I’ll answer that in a future post.  Winking smile

Why You Should Be Using Interfaces

By Nick at January 22, 2012 12:15
Filed Under: Software Development, Delphi

I’ve been railing on why you should be coding against interfaces, and a number of you have been asking me to write an article about it, so I did.  It turned out to be pretty long, so rather than make it a blog post, I turned it into an article.

Why You Should be Using Interfaces and not Direct References

The Bookstore of the Future

By Nick at January 08, 2012 15:17
Filed Under: Delphi, General, Tech Stuff, TechBiz

Bookstores are Cool

I love bookstores.  A lot of people love bookstores.  I love hanging around in a bookstore and seeing what is new, what is popular, and what is available.  I love seeing the cool games and other non-book stuff they have.   I love how most bookstores now have wireless, a café, and plenty of large cozy chairs to sit in if you want a closer look at a book. Bookstores are very cool, and I like having a good one nearby.

There are more than just superficial reasons to like bookstores.  First, they provide instant gratification.  If you want a book, you can get it immediately.  You can hold it in your hand and walk out of the store with it.  Another nice feature is the ability to browse – you can wander around, look around, and perhaps find a title that you didn’t know you wanted.  In addition, the ambience of a good bookstore is appealing and valuable as well.   The addition of café’s, music, and other products have also made bookstores much more appealing.  Clearly there is demand in the marketplace for bookstores, since whenever I go to one, there are always people there. 

Bookstores are in Trouble

But bookstores clearly are struggling.  Big player Borders recently went out of business (Anyone else notice where goes?)  Many smaller, independent vendors have been driven out of the market as well , though some of superior quality to survive (For instance, my sister loves Wild Rumpus, near her home, and they seem to be doing very well).  Online retailing has affected brick and mortar sales.  In addition, used book stores seem to have grown as well, putting market pressure on retailers of new books.  The Books-4-Less store near my house is a pretty good source of reasonably priced books, and they have a very nice selection.  They also accept “trade ins” for store credit, so you can clean out your basement and get a few new books at the same time. 

But people shopping online in the comfort of their own homes at sites like Amazon can get a much wider selection, recommendations, reviews, and all kinds of information available.  Online retailers can offer reviews, an almost infinite range of other books to “browse”, recommendations, and more.    If you know what book you want to get and aren’t feeling an urgent need to have it at this exact moment, dialing it up on Amazon’s site and ordering it with (often free) super-saver shipping can be a great time saver.  Plus, there’s non tax, and you save the gas and time of a trip.  I don’t have specific numbers, but I’m guessing that the ease of buying books online has hurt bookstore sales more than anything else.  For instance, books are always a popular gift, and the convenience of Amazon’s gift giving capabilities make giving a book as a gift vastly more convenient.  Amazon gets the book, wraps it in gift paper, and takes it to the post office for you.  Very convenient.  I’m guessing that I’m not telling you people something that you haven’t already figured out yourselves -- you are taking advantage of them in increasing numbers.

And if that isnt’ bad enough, adding to the online competition for bookstores are devices like the Amazon Kindle and other similar electronic reading devices.  Sales of Kindles and Nooks continue at a brisk pace, and every one of those represents countless book purchases that won’t be made in a bookstore.  Digital books don’t need a bookstore at all (Can you even have a bookstore of digital books?)  I know people that have Kindles who have bought many books, but haven’t held a new book in their hand in a long time – a fact good for Amazon, but not good for the brick-and-mortar retailers.  Why  even go to a bookstore?  Your friend at the local Starbucks can recommend a book and you can be reading it in just a couple of minutes – not something the owners of Borders were happy to realize. 

The Kindle is cool, but there are a few things I don’t like about it.  The top one is there isn’t any easy way to “peek ahead”.  Surely you do this – you are lying in bed reading, and you start feeling tired.  Do you just quit now, or is there a natural breaking point coming soon – a chapter ending, a sub-chapter break?  You can’t do that easily with a Kindle.  Second, (and this is why Amazon is so up on it), you pretty much have to pay for everything you want to read.  You can’t easily loan books to friends (the time limit is no fun – what to do if you have two chapters left when the time runs out?) Borrowing books from the Library has the same problem.  Amazon Prime does offer a lending service, but again, you pay for it. (See why Amazon likes the Kindle? Winking smile)  There’s a lot to like about Kindle’s, but there are a few things not to like as well.

The Current Model Costs A Lot

One of the largest struggles of the average bookstore – and the broader book industry – is costs.  The current business model is staggeringly inefficient.  Huge boxes of books – most often more books than will ever sell – are printed at a central location, loaded onto trucks and shipped to bookstores all around the country.  Those boxes are opened, and books put out on the shelves.  The rest are stored somewhere at the bookstore “in the back”.  After a while, a certain percentage – hopefully a high one, but not always – of the books are sold.  The rest are put into the “bargain bin” and sold at a discount.  Eventually, the remainders end up at those sad little bookstores at the mall or destroyed.  The costs of transporting books – they are heavy, as anyone who has moved house knows – is high.  The waste of printing books no one wants is high.  Trying to figure out the right number of books to go to the thousands of different locations – some books may be more popular in Topeka, KS than in New York City – is pretty difficult to predict.  It’s the common problem of centralize planning – who can know?

The bottom line is that the costs involved with the current bookselling/bookstore business model are simply too high.  It’s no wonder Borders went out of business – they were a day late and a dollar short with their eReader – and it’s a wonder that Barnes & Noble have kept their stores, too.

Emerging Technology

Despite the aggressive onslaught of online retailing and eReaders and very high costs, I still think there is a future – a pretty cool future -- for brick-and-mortar bookstores. However, they are going to  have to change a bit, and adapt to some new and emerging technologies.

That key emerging technology bookstores need to learn to leverage is on-demand printing.  On-demand printing is a relatively new technology, but one that can be a positive and powerful inflection point for bookstores.  On-demand printing is the ability to print a book – cover, contents, everything (even hardcovers) – immediately and on demand.  Think of it as a copy machine for books.  I’m not intimately familiar with the current technology, but I understand that it is getting to the point where a book from an on-demand printer is virtually indistinguishable from a “real” book.  Services like and other retailers enable authors to publish any content completely unencumbered by the established publishing houses.  Because books are printed as ordered, they don’t care about volume. 

In addition, the margins on book sales are much better, and so authors can make more money – much more money – on each book sale.  Delphi authors like Marco Cantu and Bob Swart have leveraged these services to bring you high-quality content while making more money in the process.  Sweet for everyone.  On demand printing is clearly an technology that will require some adjustments to business plans throughout the bookselling business.

The Bookstore of the Future

In the future, I envision a bookstore working very similarly on the surface, but very differently behind the scenes.  Bookstores will become a retail outlet for on-demand printing. On the outside and to the casual observer, bookstores will appear to be much the same – books on shelves, cafés, calendars, music, videos, etc.  But a closer look will reveal some differences brought about by on demand printing. 

First, a bookstore will have the ability to print immediately any book.   The shelves will be full of books as now, but a customer will also be able to ask for, and get, any book in the publishing system.  This feature will help bookstores match the online retailers by allowing a book buyer to get almost anything they want.  The ability to print any book immediately will be a big feature that will enhance a bookstore’s market appeal. 

And not only will a customer be able to get any book they want, the bookstore could offer any number of customizations to a book.  Kids could get copies of the Twilight series with a selection of different covers of their favorite characters.  Readers could choose font type and size, and perhaps even different colors of paper.  Each feature could cost extra, increasing margins.  I can foresee computer kiosks at the store allowing users to pick features a la carte.   Heck, I can even foresee bookstore branded kiosks at grocery stores much like RedBox.

The second subtle change that will take place is that the books available on the shelves will consist of fewer duplicates.  Since the books are printed onsite, they don’t need to stock up on multiple copies, leaving room on the shelves for a wider variety.  This will improve the browsing experience.  And of course the store can keep the shelves fully stocked.  The point of sale system would record each sale, and a book is sold, a replacement can be immediately and automatically printed. Efficient printing and stocking would mean that the shelves would be full, and a wider variety of books would be available on the shelves almost constantly. 

And of course, the printing of books right in the store means no more distribution costs – no more centralized printing with the subsequent distribution inefficiencies. New books will be distributed electronically of course.  Book stores will still need paper, glue, ink, toner, etc., but t’s much easier and less costly to distribute supplies than it is boxes of specific books.  And the waste of printing books that never get sold will be reduced because inventory will be wider and flatter with little over-stocking.

How it Will Happen

The transition to this new model will be interesting.  I don’t think that you’ll see it come from existing chains like Barnes & Noble.  Generally, a radical, disruptive change like this needs a fresh, upstart business to challenge the existing firms.  I also suspect that existing chains are too tightly tied to the existing publishing houses to allow them to be this flexible.  And I’m pretty sure that the existing publishing houses will not embrace this new model. The music industry has been glacial in accepting and understanding the changes brought by digital music, and I suspect that the book publishing industry will have a similar reaction. 

However, I think it will eventually happen.  The current bookstore model is clearly in trouble – even Barnes & Noble is having trouble in the marketplace despite the lost of major competitor Borders.  But in the end, the demand for the things that bookstores offer is strong.  The industry will be fine once they figure out how to leverage the advantages that on-demand printing offers.

More on FreeAndNil

By Nick at January 02, 2012 05:03
Filed Under: Software Development, Delphi

I love a good, testy comment section in a blog post.  Winking smile  The discussion in the comment section of my FreeAndNil post has been interesting and lively.  In addition, the thread in non-technical continues apace, with new threads springing up!  Along the way, a couple of interesting points were made that I’d like to highlight here because I think they are germane.

  • First, I can sum up the article as follows: “Don’t use FreeAndNil.  If you feel the need to use FreeAndNil, then your code almost certainly needs to be refactored to limit the scope of your references.”.    People arguing for it’s use are, in my mind, simply saying “I don’t know how to or don’t care to control the scope of my pointers” 
  • Second, I want to stress again that I totally get that sometimes you have to use FreeAndNil. Sometimes you maintain old code that played fast and loose with pointer scope, and didn’t contain things like we now know you should.  I get that.  But those situations should cause you shame and embarrassment, and should motivate you to refactor your code to control references and make the need for FreeAndNil go away.  The reason that I totally get this is that I manage such a codebase.  The point isn’t about maintaining legacy code, it’s about how to write new code the right way.  And if you are writing new code while feeling the need to FreeAndNil stuff, then you aren’t doing it right, quite frankly.
  • Jolyon Smith wrote the following in the comments: “Surely you must also admonish everyone to write code that never requires the use of if Assigned(someReference) then…”  Well, yes, I suppose that is exactly correct in most cases, unless you are doing lazy initialization, which I wouldn't recommend using anyway.  If you are using Dependency Injection -- and you should be -- there is never a reason to be worried about your references not being assigned. 
  • John Jacobson writes: “Reference-counted interfaces are what you should be using anyway, keeping your actual class implementations private and hidden in the implementation section of their unit.”  He’s absolutely correct. Ultimately, you should be coding against abstractions, not implementations.  If you are doing that – and of course you should be in Delphi via reference-counted interfaces – then you shouldn’t be freeing anything other than local, non-volatile variables, and you should never need to FreeAndNil those.

By now many of you all are probably saying “This guy is a nut!  Get over the FreeAndNil thing already!”  Well, okay, I agree I’ve beaten this drum quite a bit.  And I agree that I’m pretty much a nut. But I really think that it represents a critical point that we all need to understand in order to move forward:  Code needs to be under control.  Good development dictates that we limit the scope of references.  And finally, out of control references are the cause of many, many bugs, and are the cause of 100% of access violations.  The use of FreeAndNil is a blatant symptom of this problem.

Here’s the bottom line, and I’ll be blunt: If you are arguing in favor of using FreeAndNil, what I really hear you saying is “I learned to code in 1991 and haven’t learned a thing since.” 

Okay, that’s a little harsh.  I’ll put it a bit softer:  Worrying about pointers and references is, well, an old-fashioned way of thinking.  There are ways to code so that worrying about whether a pointer is valid or not is no longer something you have to worry about.  This way of coding is more productive, cleaner, and more effective.  It produces high-quality, testable code.  

Doesn’t that sound enticing and intriguing?  Why wouldn’t you want to learn more?

Produce More, Consume Less

By Nick at January 01, 2012 03:59
Filed Under: General, Personal, Delphi

The world seems to be bent more and more on input.  The internet company sells you almost exclusively on the download speed they provide, and couldn’t care less about the upload speed.  Heck, we don’t care about upload speed much.  We are migrating towards devices that don’t have physical keyboards.  The whole idea of tablets is as media consumption devices, designed to bring data to our fingertips, where ever our fingertips may be.  (My favorite place – more on this – seems to lying down somewhere….). 

It’s never been easier to dial up a TV show or movie and watch it.  Shoot, you can even pick specific episodes for your viewing pleasure.  You can track the every move of your favorite celebrity.  You can buy almost anything to want without getting up off the couch.  You can watch replays of ever game and every highlight. You can read the thoughts of millions of 14 year old girls.  Advertising is customized to your specific interests.  It all comes at you in a slickly packaged, conveniently laid out format. 

And all you have to do is (as the airlines seem to be required to say) sit back, relax, and enjoy the flight. 

So this gets me to my New Years Resolution:  To produce more and consume less.  First, I have to give full credit to Scott Hanselman for inspiring me.  He posted this on Google Plus last night: “#1 Productivity Tip: Spend 10% of your time consuming and 90% of your time producing. Make more stuff. Watch less. Read less. Do.”

And it hit me that this was exactly what I needed to do.  I spend a lot of time consuming. A lot of time.  I watch a lot of TV shows on Netflix that I don’t need to watch. I  read a lot of RSS feeds that I don’t really need to read. I poke around on the internet way too much. Along side of all that consumption, I feel like to don’t do a lot of the things I want to do.  I have a million ideas for blog posts, but I never seem to write them.  I have a ton of ideas for writing code, but I don’t write it. I have a lot of ideas for trainings and presentations, but I don’t prepare and give them.  I sit on my butt instead of walking the dog.  Generally, I just consume and I don’t produce nearly as much as I could be. 

So that is my resolution for this year.  To produce more and consume less.  That means, specifically, I’m going to:

  • Write a substantive post on my blog once a week.  At least.  Probably more.  I want to get my “Blog Post Ideas” list down to zero and keep it there.  This blog post is the first of hopefully more.  No one might care what I have to say, but hey, at least I said it.  Winking smile
  • Find an open source project and work on it.  I’ve made some furtive efforts to support the Delphi Spring Framework project, and I intent to renew that effort at producing value for the Delphi community.
  • I’m going to get off my butt and walk.  Once I lose weight, I’m going to start running again.  I’m going to produce some better health for myself.  And my dog, too.  Winking smile
  • I’m going to write a book on coding in Delphi.  I’ve got it outlined, and I’m going to write it.  I think it will be good.  It’s been hard to get started, but that is the “big goal” for the year.  If I can produce a book in 2012, that will be a big win. 
  • I’m going to be deliberate and purposeful in what I read.  I’m going to read less (I have a lot of writing to do!) but I’m going to get more bang out of the time I do spend reading.  I’m going to focus on business books and development books.
  • The same is true for movies and TV shows.  I’m going to be deliberate and plan any watching I do.  No more just dialing something up on Netflix because I am bored.  I will be purposeful in managing my Netflix queue.
  • I’m going to remove FreeCell from my phone.  We all have that app that we use when we are – ahem – “indisposed”, and I’m going to replace FreeCell with my Bible Reading plan.  A little thing, but hey. Out with the bad and in with the good, right?  (Sorry, couldn’t resist….)
  • I’m going to spend time selling stuff on eBay.  I have a lot of stuff I don’t need but that is still valuable to somebody.  I can produce a little wealth for myself and my buyers by selling on eBay.  Last month, my awesome wife turned a bunch of stuff in our basement into over $1000 cash.  This is a productive endeavor. 

That should keep me busy this year, and that is sort of the point, right? I’d love to hear from you guys about what you are doing to produce more and consume less. 

I’ve gotten lazier over the last few years as I’ve gotten older, and it is time to reverse that trend.  It’s a gorgeous day here today in Pennsylvania, so I’m going to post this and go walk the dog. 

Flotsam and Jetsam #52

By Nick at December 31, 2011 07:59
Filed Under: Flotsam and Jetsam, Delphi
  • Many of you have headed over to the Delphi UserVoice page and voted on your favorite new feature for Delphi and RAD Studio. (Feel free to go over and vote for this one or this oneWinking smile) I’m still an Admin there, and have been, well, doing a bit of administering.  One thing I’ve been doing is marking as “Declined” a lot of “Laundry List”  and the “Too Quick” requests.  A Laundry List request is one that has multiple requests in it on a general topic.  I’m closing these because they can’t ever really be “finished”.  It might be that three of the four requests get done, but it can’t be marked “Finished” because of that last item.  Instead, one should enter a single item for each request.  “Too Quick” requests are requests without any content, and that can’t possibly ever be completed (or could be marked completed anytime) – things like “Better support for <some feature>”.  What the heck is that supposed to mean?  Anyway – you may have a few more votes as a result, so feel free to go over and cast them again, or enter better formed requests.
  • Has anyone besides me noticed that Embarcadero has done a pretty large buy with Google AdSense? I’ve got Delphi ads popping up while I’m watching YouTube videos and even reading political articles. I also get a Delphi ad on many of the pages I see over at StackOverflow.    I like it myself – I’m always happy to see advertising tailored to my specific wants and interests. Plus, I’m glad to see that the marketing folks are In any event, Google has figured out that I’m a big Delphi fan.
  • DevExpress has updated their VCL subscription to support Delphi XE2, including 64-bit Delphi.  The post even included kind words about Embarcadero from Julian Bucknall about XE2, so you know that something has to be going really well with Delphi XE2. Winking smile
  • I love a man who writes about Dependency Injection.  Brings a tear to my eye. I’m getting to the point where I think that Dependency Injection is the only way to code – that if you are calling Create and otherwise insisting on a particular implementation of an interface then you are just writing back code. 

Using FreeAndNil

By Nick at December 13, 2011 16:39
Filed Under: Delphi, Software Development

There has been a large and ongoing thread in the Delphi Non-Technical newsgroup about the proper use of FreeAndNil.  It’s been contentious and a tad touchy, too -- just as I like it.  Winking smile  The discussion falls out into two schools of thought:  Those that use FreeAndNil liberally and almost everywhere, and those that use it not at all or only in very rare, specific cases.  The former argues it is “defensive coding”, while the latter argues that it is the coding equivalent of spraying perfume on a skunk. 

I am in the latter camp.  I am in the the latter camp for a very good reason:  because the latter camp is right.  Winking smile There’s almost never a reason to use FreeAndNil in the new code that you write. 

And I want to be clear about that – I’m talking specifically about new code.   If you have old code that was designed in such a way that the scope of your pointers wasn’t tightly contained, than yes, you’ll probably have to use FreeAndNil to make that code work right.  But if you are doing that, I hope that you recognize that it is a problem and plan to refactor the code to contain the scope of your pointers.   I’m totally aware that legacy code may very well require that you nil pointers because the scope of those pointers is not well managed.  I know this because our system has such code, and thus contains calls to FreeAndNil

So, anyway, here’s an explanation why I think that FreeAndNil should only be used very, very sparingly. 

Before I start, I want to add that this blog post is heavily influenced by the eloquent wisdom and excellent explanations of a number of people who participated in the thread, including Bob Dawson, Wayne Niddery, Rudy Velthuis, Joanna Carter, Mark Edington, and Pieter Zijlstra.  Any profundity, excellent examples, pithy similes, or clear descriptions of things are very likely a result of me reading their posts in the thread.


FreeAndNil is a function declared in the SysUtils unit and was introduced in Delphi 4, if I recall correctly.  I myself suspect that it was added more because of customer demand than because the R&D Team felt some need for it, and I’m reasonably sure that if they had it to do over again, they would not have added it at all.  But there it is.

The code for FreeAndNil is as follows:

procedure FreeAndNil(var Obj);
  Temp: TObject;
  Temp := TObject(Obj);
  Pointer(Obj) := nil;

That does seem a bit weird looking – you might expect it to look like this:

procedure FreeAndNil(var Obj: TObject);
  Obj := nil;

But it doesn’t.  It looks the way it does for a couple of reasons.  First, the parameter passed needs to be a var parameter because two things need to happen.  The object referenced needs to be freed, and the reference itself needs to be altered  -- that is, set to nil.  Thus, you need the freedom to change both the reference and the thing being referenced that the var parameter gives.  Second, the parameter is untyped because when you pass a var parameter, “Types of actual and formal var parameters must be identical.” Given that, if you declared the parameter as a TObject, then you could pass only a TObject to the method and not any of its descendants.

For instance, the following code will not compile:

program WontWork;




  TMyClass = class(TObject);

procedure Foo(var Obj: TObject);

 MyClass : TMyClass;

  MyClass := TMyClass.Create;

I should point out that the use (or non-use) of FreeAndNil is not an insignificant and uncontroversial issue.  The thread that spawned this is typically long.  Allen Bauer, the Chief Scientist at Embarcadero, blogged about it, and quite a discussion ensued in the comments – so much so that he felt the need to blog about it again.  StackOverflow has a whole bunch of questions on the subject.  The VCL uses FreeAndNil in places that I wouldn’t necessarily approve of.   I think that in most places its use indicates, uhm, an “older” design choice that probably wouldn’t be made today, given newer language features.  In any event, clearly folks have strong views on this and that the use (or note) of FreeAndNil is not “settled science” (though I believe it should be…). 

Okay, So When Should You Use FreeAndNil?

In my mind, the answer to the question “When should I use FreeAndNil?” is “never”, or at least “Almost never, and if you must use it, make sure that there is a really, really good reason to do so and that you clearly document that reason”.  I myself have never (to my best recollection – I fully expect someone to find some obscure reference to code I wrote years ago that uses it….) used the procedure and see no possible scenario where I would want or need to in the code I write.  My recommendation is that you never use it either, because I don’t believe that you are writing code that needs it either (unless you are on the Delphi R&D team working in the bowels of the RTL, I suppose). 

Why I Don’t Use FreeAndNil and Why You Shouldn’t Either

There are a number of reasons why I don’t use FreeAndNil

First, a call to Free is sufficient. It gets the job done.  Free will, well, free the memory associated with your reference.  It does the job completely and totally.  Can’t do any more.  Setting a pointer to nil doesn’t get you anything.  The memory isn’t going to be more free or freed faster as a result of calling FreeAndNil.  Since it’s always a good practice to use exactly the right tool and nothing more, there’s no need to make the extra call.  Consider this – there’s no SetToZero call for integers, and if there were, why would you use it?  All code should be written with “considered intent,” and the indiscriminate use of FreeAndNil shows a lack of consideration and intent.

Second, using FreeAndNil where Free alone will do just fine obfuscates your code.  Using a call that executes unneeded instructions sends a message to future readers of the code that shouldn’t be sent.  A subsequent developer maintaining your code might look at the call and say “What the heck?  Why is FreeAndNil being used here and not just Free?  Is something going on here that I don’t know about?”  Time might then be wasted investigating, and a satisfactory answer may never be found.   Code that uses Free and FreeAndNil as exactly the same thing has reduced the amount of information that your code can convey.  And when you are dealing with something as important as memory management, you certainly don’t want to reduce the amount of information your code can convey.

FreeAndNil has a clear meaning – it is a very clear indicator that the pointer being freed has meaning outside of the scope where it is used.  If it doesn’t say that, then you shouldn’t use it.  If you use FreeAndNil when that is not the case, then you’ve sent a bad message to future maintainers.  Clarity in code is paramount – nothing should be done to decrease that clarity.  Code should be intentional and there for a reason.  Code that is there that doesn’t need to be can be misleading and distracting.  Misleading and distracting are not two thoughts that developers want crossing their minds while maintaining code. 

Free has meaning as well – it clearly states that the use of that pointer reference is now done and over with.  As noted above, there’s no need to call anything else.  The indiscriminate use of FreeAndNil fails to draw the clear distinction between Free and FreeAndNil.  Losing clarity in your code is bad, right?

Third, one of the justifications for using FreeAndNil is that it is defensive and that it protects against using a pointer at the wrong time.  The claim is that if a pointer is nil, and you then use that pointer, then you’ll know right away, and the bug would be easy to find. Thus, if you feel the need to use FreeAndNil to ensure that you don’t misuse a pointer somewhere, then it is very likely you have a design problem:  the scope of the pointer in question is larger than the use of that pointer in your code.  Or, in other words, the scope of a pointer and the scope of the use of that pointer aren’t the same and they should be.  If they aren’t , you are simply begging for trouble. 

If you want to really be persnickety, a variable that is broader in scope than it’s use is a form of a global variable.  And I would hope that we agree that global variables are bad.  If we can’t agree on that, well, then we can’t agree on anything.  Winking smile

Maintaining proper scope is critical to good, clean code.  I’ve discussed this before, and so I won’t go on about it here.  The germane point here is that if the scope of a pointer is of the “laying around waiting to be used”, then there is no limit to the mischief that this wayward pointer can cause.  So, if you don’t “leave a pointer lying around”, you can’t misuse it.  So, well, don’t leave a pointer lying around.   If you don’t leave roller skates at the bottom of the stairs, you can’t go careening down the hallway.   Keep your pointers and the use of those pointers in the same scope and you can’t misuse a pointer.  And you won’t feel the need to use FreeAndNil

And if you do use it for defensive reasons, you have to use it everywhere.  You have to use it in ever single place it is needed and you can’t miss a single place.  And, every single maintainer of the code after you has to as well.  One instance of not using it basically removes all the reasons for using it.  It’s a much better plan to simply control your scope and never feel the need for it. 

So, in the end…

In the end, I guess the argument for using FreeAndNil seems to boil down to:

“Of course I use FreeAndNil – it protects against bugs and makes other bugs easy to find, and besides, what’s the harm?”

Well, it would seem that none of those reasons is really true.  The real argument is:

“If your code requires you to use FreeAndNil to reveal and easily find bugs, then your design is wrong.  Good, clean code never feels the need to worry about errant pointers.”

Hey, look: design your code however you like. However, if you were to ask me, I’d say to design your code in such a way that FreeAndNil sends no signal, doesn’t find any bugs any sooner, doesn’t protect against anything, and thus becomes utterly superfluous.

Flotsam and Jetsam #51

By Nick at December 12, 2011 00:51
Filed Under: Delphi, Flotsam and Jetsam, Software Development, Three Sentence Movie Review
  • If you missed CodeRage 6, or you didn’t get to every session that you wanted to see (hear?), it is now all online.  That link also points to the latest offers and ways to find out more about XE2.  I love XE2, and think it’s the best Delphi ever.  And I say that not even using the FireMonkey/cross-platform stuff – so it’s even better than I think.  Winking smile
  • I was digging around in my boxes in the basement – we’ve moved a ton, and so I’ve got stuff scattered all over – and came across a CD labeled “Website”.  I opened it up, and lo and behold, there was a copy of one of my very first web sites, built with NetObjects Fusion.  It was fun to poke around and see some of my really old content.  (As a point of reference, the homepage has “This site was last updated on  Tuesday, December 18, 2001” at the bottom.  Remember when we used to do that?) Actually, I think some of the stuff will end up on my current site.  Winking smile  Not all the links work, but if you’ve been around a while, you might remember some of it.  Most of it was hand-maintained, but you can see where I tried to integrate in some early Delphi-based CGI stuff.   I actually still like the colors and the template.  Winking smile
  • The Generics.Default.pas unit is an interesting one – you may never have cause to use it directly, but it contains a lot of interesting stuff in support of the classes in Generics.Collections.pas.   It’s worth poking around in.  I was doing just that, and came across some interesting code – a function called (and I quote) BobJenkinsHash.  It is used rather extensively throughout the unit, and appears to be a general purpose hashing code.  Who is Bob Jenkins, you may ask?  Well, apparently he’s a guy that wrote a very powerful and useful hash function, and Embarcadero has utilized it as part of their generics library.  And here’s the interesting part – they created it using a set of GOTO(!!) statements whose use , well  -- I seriously can’t believe I’m actually saying this – actually kind of make sense.  The C code depends on the “fall through” nature of C’s switch statement, and the GOTO calls actually mimic that rather nicely.  I’m open to suggestions on how it might have been written better.  Winking smile (Again – I can’t believe I just said that, but there it is.)  And to redeem myself, I’ll chastise the author for not defining his interfaces in their own unit.  (Sorry, Barry – I had to do something to restore my street cred for actually liking the way the GOTO’s worked…..) Anyway, interesting little find in the bowels of the Delphi RTL.
  • I’ve added a new category, Three Sentence Movie Reviews.   I watch a lot of movies, and have all these aspirations of writing up movie reviews when I watch, but I never do because it takes too long.  So I thought I’d simply limit myself to three sentences in reviewing the film, and that way I might actually get the review done.  I might have to get a bit creative – sort of like keeping tweets to under 140 characters.  Should be fun.  If you read this blog via DelphiFeeds, you won’t see it as I’ll not be putting the Delphi category tag on them. Just another reason to subscribe to my real feedWinking smile

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

My Book

A Pithy Quote for You

"To see what is in front of one's nose needs a constant struggle."    –  George Orwell

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.