Flotsam and Jetsam #96

  • Quote of the Week: “In general, you should always strive to eliminate the passing of null rather than checking for null.” – John Sonmez
  • #DelphiWeek was fun.  I followed the hashtag on Twitter,  and saw all kinds of fun stuff, from people posting pictures of their old versions of Delphi (all the way back to floppies that held the very early versions of the beta.  I still have some of those –) to Ray Konopka’s Borcon buttons.  I was also honored to be interviewed for the event, talking about the early days of TSmiley and something I’m still proud of to this day – the fact that I was at the original launch event for Delphi.  It’s hard to believe that as I type this, that was twenty years ago today, but there you have it.  Delphi really is twenty years of continuous innovation, and it continues to prove worthy of that moniker. 
  • Rob Love has a really nice article on the Parallel Programming Library and using TTask properly.  Good example of how tricky parallel programming can be.  I’m working on that chapter for my new book and it is indeed a challenging topic, but one worth the effort.  Good reason to upgrade to XE7.
  • Andy Hausladen dog-fooded a new JSON parser for Delphi.  Worth a look, for sure.  I downloaded it, looked at the unit tests, and now I know how to use it.  See?  it really works that way.

Coding in Delphi $10 Off During #DelphiWeek

To help celebrate #DelphiWeek and 20 years of continuous innovation, my book, Coding in Delphi, is $10 off for the next week.  Just use the link below to receive the discount:



Flotsam and Jetsam #95

  • Last week I sang the praises of Stefan Glienke.  Well, he has done it again.  He’s released TestInsight – an IDE integration for unit testing.  This is really cool – you can run your tests automatically right in the IDE.  Give it a look – very, very nice stuff.   Plus, it works with all the major unit testing frameworks.
  • Tweet and Quote of the Week:  “As long as managers think programmers are young interchangeable pizza-fed cheaply hired commodities, buggy software will rule the world.”
  • Glad to see that this website is still alive and kicking: http://www.isdelphidead.com/ Hehe.
  • Work on my new book continues apace.  I’ve just started showing chapters to my “beta testers”.  I’m grateful for all the feedback I get.  If you are interested in reading rough drafts of my chapters, you can join the Coding in Delphi group.  It’s a private group, so I’ll have to approve your entry, but that’s usually not a problem.  I welcome and am grateful for any help in making the book better.
  • Next week is Delphi Week.  You can register to participate.   Hard to believe it’s been twenty years.  Seriously?  Great that the product is still rolling along as strong as ever.  I’ll have few thoughts, tweets, and other things to offer as we celebrate.  Keep an eye on this space and the #delphiweek hashtag, as well as the presentations from Embarcadero.  Should be fun.
  • Jim McKeeth does a nice interview with Darren Kosinski, who is a member of the FireMonkey R&D team.  Darren is a friend of mine from my days at Embarcadero and a good guy as well as a brilliant developer.  Give it a listen. 

Targets and Estimations

We’ve all been there.  “How long will this take to get done?”.  The answer they are looking for is “by this afternoon,” but most often the real answer is longer than that, often much longer.  In fact, the real answer is “I don’t know”.  But you have to give an answer.  This is where you hear tales of people rolling dice or making something up or saying “six weeks” no matter what.  In the end, you can’t know for sure because you’ve never done that project before, and so you make your best guess and it works out somehow most of the time.

But a lot of developers and managers fail to realize that there are really two different kinds of answers you can give.  If it is Monday, you can say “I’ll have that done by Friday”.   Then you work like crazy, and just before you go home on Friday, you deliver what you promised. 

The other type of answer you can give is “That will take 40 hours.”  And so if it is Monday, and you say that, then the manager will hearI’ll have that by Friday”.  So then you go and you work like crazy, and just before you go home on Friday you deliver what you promised.   But when you’re done clocking all your time, you put in 50 hours to get the project done.  That’s a 25% overrun, and your manager wants to know what happened and why you took so long.

There are a lot of things going on here – but the point I want to make is that there is a difference between an estimate and a target.  An estimate – “How many hours is this going to take?” – is very difficult to get right.  There are always unknown unknowns that enter in to make the total number of hours that something will take.  We are notoriously bad at making estimates.  There are a lot of reasons for that, but the fact remains that we are not really capable of making accurate estimates.  But “I’ll have that by Friday” is easier to say because you have flexibility in the amount of work it takes to hit that target.

But note well that an estimate is not a target.  A target is when you say “I’ll have that by Friday”.  Saying that on Monday morning is not the same thing as saying “It will take 40 hours to do”.  In fact, it’s a very, very different thing.  Saying “I’ll have that by Friday” actually means “I’ll do whatever it takes – put it however many hours it takes – to get this done by Friday.”  It might take 20 hours.  It might take 60 hours.  But you didn’t say anything about how many hours it would take, you gave the target point when it would be delivered.

So if you are a manager, recognize the difference between a target and an estimate.  If you are asking for an estimate, understand that software estimation is still something even the most seasoned developers do very poorly.  If you are asking for a target, realize you may be asking someone to put it a lot of hours to hit that target.  Or not – maybe they say “Friday” and it only takes half an hour.  Who can say for sure?  If Friday is good enough, then you shouldn’t care how many hours it ends up taking either way.

And the one thing you shouldn’t do is ask for an estimate, take it as a target, and then get upset when the developer hits the target but runs over on the hours. 

Targets are not estimates, and estimates are not targets.  Understand the difference, and you’ll have happier developers and happier managers.