You are going to pay for bug fixes. And you’re going to like it.

The day is coming when you are going to have to pay to get bug fixes.  You won’t like it at first, but that is the way things are heading.  And you should like it.

I can remember the day when software came with free support.  You had a problem, you called up the company and spoke to a tech support representative who would help you with your problem.  For free.  For hours if need be.  It was expected.  Of course a company should support a product that they sold.  If it wasn’t easy to use or didn’t work right, they need to make good on it. 

You might, at this point, see where this is going.

Then, of course, economics caught up with the marketplace, and companies began to charge for support, sometimes upwards of $100 an hour. People didn’t like it at first.  But even that became uneconomical as the internet appeared, and people stopped paying for support when they could get free support on the internet.

I can remember the day when software came with a stack of manuals, sometimes two feet high.  Anyone remember the Borland C++ 4.0 box? It was so big it had a handle built into it.  (I looked for a picture of it, but couldn’t find a good one…)  Of course the company should supply physical documentation with their product!

Then, of course, economics caught up with the marketplace, and companies couldn’t afford to ship all that paper with the product, and the documentation became digital and shipped with the DVD.  Hard copy documentation fell by the wayside.  People didn’t like it at first.

I can remember the day when software came on DVD’s, and when you ordered a new version of your favorite software package, they mailed you a DVD with a nice case.  (Shoot, I can remember when they mailed you 3.5” floppies, but that’s another story.) Of course the company should send you a physical copy of the software.  You paid for it, damn it, and you should get a disc! 

Then, of course, economics caught up with the marketplace, and now, you don’t even get that DVD.  Instead, you get a download link for an ISO file and you burn your own DVD if you want a physical backup. Or you just download an installer.  More likely you simply stored the software file on a backup hard drive or, now, in the cloud.  People didn’t like it at first.

You definitely should see where this is headed now. 

Pretty soon now, we’ll all be looking back on the day when you actually bought a stand-alone license for your software, and you got bug-fix updates with that single purchase.  Of course a company should give bug-fixes for free – the product should work right in the first place, and so why should I have to pay to get bug fixes?

But the economics of that are going to catch up with everyone, and soon companies are going to stop selling licenses and start selling only subscriptions.  And in order to get updates – including bug fix updates — you will have to have a subscription.  People won’t like it at first. 

The future is already here for many software tools.  Adobe sells only subscriptions for their highly popular graphics tools.  Office 365 is sold as a subscription.  And if you own either of those, you are – surprise! – paying for bug fixes.  This is a trend.  Microsoft and Adobe are not small software vendors.  You will see more and more software tools being sold this way.  It’s inevitable, as economics and the marketplace do their thing and technology enables new business models.

A pause for some thoughts:

  • It’s a silly thing to believe that the complex software that you buy should be bug free.  No non-trivial software is bug-free.  All software is buggy.  Everyone knows this.  Developers, in particular, should know this.  Yet people still argue that the product should be bug-free and that they should be entitled to free bug fixes because they “paid for a product that should work out of the box”.  Well, I hate to break it to you, but no software “works right out of the box” and there is nothing that developers can do about it.  I’ll say it again:  all non-trivial software has bugs and there’s nothing to be done about that.
  • Even brilliant developers develop code with bugs in it.  Even a clairvoyant QA team won’t find all the bugs. 
  • All software development requires intense human labor.  Bug fixing requires intense human labor. Companies cannot afford to do things for free.   Good developers and QA people are not cheap. 
  • Thus, as we saw with free support, documentation, and DVD’s, something has to give.  And that something is the notion of “buying a single, stand-alone license” for your software.  It’s going to go away.  Software companies are slaves to the marketplace just like every other business in the marketplace, and they are being driven to a subscription model just like they were driven away from free and then paid support, as well as stacks of paper for documentation and DVDs for software distribution.

People won’t like this at first.  But they should. 

First, the overall cost of a subscription will be less than purchasing upgrades.  Subscription fees have so far proven to be a remarkably good deal.

Companies will have vastly more flexibility to add features on a more frequent basis rather than in yearly (or longer) upgrade cycles.  Companies that sell only subscriptions can also talk more freely about their future plans because – and I am mentioning this with great trepidation – they won’t have revenue recognition issues with regard to future-looking statements.

And yes, companies will be more motivated to fix bugs – perhaps even bugs in previous versions.  Because they will have a steady stream of revenue and because they will be off the “one big release” mentality, they will have more leeway to fix bugs.  Because they can bring features to market sooner than they might have before, they can spread the pressure of releasing new features over longer, less focused periods of time.  Removing shipping pressure increases quality. 

Some will argue that a subscription model incentivizes companies to care less about quality.  This is nonsense.  It will incentivize them to care more about quality, because there will be no more excuse not to increase quality.  If quality doesn’t increase, people won’t renew their subscriptions.  And companies will be very, very interested in renewed subscriptions.  Low quality will not be a good business model while providing subscriptions.  Since feature pressure will be reduced, quality can become more prominent.

Yeah, people won’t like this change.  You are probably firing up the comment dialog box as I type this.  But I think we all see the benefit of free internet support like StackOverflow, online documentation like wikis, and software downloads that get you your software immediately.  Those were changes that we didn’t like at the time, but that we see the value in now.

And so it will be with software subscriptions.  So, yes, you are in essence “paying for bug fixes”.  But bug fixing is both inevitable and costly.  However, you’ll also be getting more frequent updates, more frequent new features, higher quality, and more openness about the future.  You’ll always have the latest and greatest version of your software package.

Who doesn’t want that?

Fun Code of the Day #1

 

Flotsam and Jetsam #101

Flotsam and Jetsam #100

  • Well, here we are; one hundred Flotsam and Jetsam’s.  I started this series just after I left Embarcadero. Here’s a link to the very first one on July 17, 2010.  Short and sweet it was.  Took almost five years to get here to one hundred.  Thanks for hanging with me.  Here’s to another 100, eh?
  • Delphi XE8 is out. The main feature appears to be the Apple-mandated 64-bit iOS support.  It has Castalia integration as well as an interesting new tool called “GetIt” that will install a various – and presumably expanding – list of third party component sets and frameworks.  That’s pretty nice.  The Data Sheet can be found here and the Feature Matrix is here.  Give it a look.  “Support and Maintenance” is now called “Update Subscription”  which has the following interesting text in it:  “…on-going maintenance on previous versions for up to 2 years from release..”   That sounds intriguing. There is also a tool to migrate your settings  from previous versions.  I know I’ll be using that. Here’s the list of new things in XE8 – it’s pretty long.
  • SD Tmes has a review of RAD Studio XE8.  Lots of talk about IoT – “The Internet of Things’”.  And here’s the article from The Register.  My favorite quote from that article: “I ran up the RAD Studio XE8 IDE and one obvious benefit is the speed and responsiveness of the IDE compared to Visual Studio.
  • For some reason, VCL developers always seem to feel slighted by recent releases.  No reason to feel that way, though:  Marco has a nice list of things for VCL developers in XE8. I especially like the improved TField performance.

Flotsam and Jetsam #99

Trailer Hitches and Software Development

When I was in the Navy, I had a friend named Tom.  Not only a great naval officer, aviator, and all-around good guy, he was also a good husband.  And by good husband I mean that he modified his beloved Ford truck to include a tow hitch for his wife’s horse trailer.  It was a big horse trailer and he had to get one of those hitches that was attached into the bed of his truck.  It was a major change.

Being the wise man that he was, he went to get some estimates.  The first one he got was a reasonable price, but the second one was twice what the first one was.  Tom asked why, since the first price wasn’t small, and the second guy’s price was pretty hefty.  The guy said “Well, you can pay me to do it the right way, or you can pay that guy and then have your hitch rip off and have your horse trailer go careening off while you are cruising down the highway”.  The point, of course, was that there is an upfront cost to doing things right that can prevent even more costs down the road (literally, in this case). Needless to say, Tom went with the second guy.

“It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.” — Max Kanat-Alexander

This quote came from a book I read yesterday called Code Simplicity: The Fundamentals of Software
It’s a short book – I read it in a couple of hours – but it is a good one.  Full of wisdom about software development, it makes the point that no matter what, your software is going to change.  And when it changes, you will introduce defects, so you need to make it as easy as possible to change your code in order to minimize the bugs you introduce when changes occur and decrease the difficulty of adding new features. It’s a really good book – give it a read.

The bottom line of the book: – In order to manage complexity in the large, you need to code for simplicity in the small. Complexity is the key, and how you manage that will dictate the long-term success of your project.  It’s amazingly easy to create complexity, and it takes a lot of work to create simplicity.

So code is like the trailer hitch – you need to put your costs up front in order to avoid disaster in the future.  As Kanat-Alexander says – we need to put effort into the implementation of our code in the beginning so that costs are minimized during the maintenance period.  We need to plan for the long haul, designing our systems up front to be flexible and changeable and composed of simple modules.  You can build complexity by combining simple modules into a complex system.  Simple modules are easy to maintain.  You can also build complexity by combining complex modules, but complex modules are difficult to maintain.  

There is no up side to the “Get it done quick and we’ll worry about fixing bugs later” way of doing things.  “You can pay me now or you can pay me later” is how the old saying goes, and it’s as true for software as it is for horse trailer hitches. 

Flotsam and Jetsam #98

  • I’ve been whining about my difficulty in writing a book chapter about the Parallel Programming Library.  I’m getting the hang of it, though, and it is as cool as it’s been touted to be.  In fact, I’d venture to say that once you start using it, you’ll never really need to use TThread again.  The PPL is a nice abstraction of threading, with the notion of a TTask/ITask taking over the role of TThread.  You can pretty much parallelize anything you want with ease.  Very much worth the upgrade, if you are still on a pre-XE7 version.  And completely cross-platform – with nary an {$IFDEF} to be found. 
  • As many of you know, I work on my book at my local Burger King on Saturday and Sunday mornings.  As a result, I drink a lot of iced tea.  This is fine – I enjoy a good caffeine buzz – but the down side?  All that iced tea makes me cold, despite the fact that I have a heavy fleece jacket on most of the time.   And the iced tea in the container is warm, so you have to use a lot of ice to get it cold, because no one wants warm iced tea.  I wonder if I could give myself hypothermia.  I mean, I drink a lot of iced tea while I’m writing, and I am definitely lowering my body temperature.
  • Here’s a wish that I have for Delphi:  That the default behavior for many of the VCL components be changed to not include the caption in the initial component.  Does anyone want the TPanel caption to be anything other than blank?  Does anyone want “Memo1” in a TMemo? “Edit1” in an edit?  Maybe there was a time for that, but how tough can it be to change that and save us all the aggravation?  VCL team – make this happen!
  • I get the sense that Delphi folks don’t make use of environmental variables like they should. Am I right?  When I find a new library that I want to use, I put it in a directory called c:\code.  For instance, I have c:\code\duckduckdelphi.  Then, I create an environmental variable called “DUCK” that equals the source directory for DuckDuckDelphi.  Then I add $(DUCK) to my Delphi path.  That way, it keeps the path short and sweet and less awkward than a hard-coded path.  In team environments, this works great too, because then people don’t all have to have exactly the same directory structures.  Do others do this?  How do you guys handle your Delphi paths?

Flotsam and Jetsam #97

  • Well, the next release of Delphi must be getting close.  The Delphi Insider has information about Skill Sprints that will show some of the new features.  Mitov Software has an interesting screen shot that looks like it has some sort of multi-view for mobile apps.  Cool.  Here’s a community post on what it is – the Multi-device Preview.  The Code Sprint are showing off new features as well.  Marco has a video about EMS Notifications.  EMS is a very under-appreciated feature if you ask me. 
  • I endeavor to write clean code. I hope you do, too.  One nice measure of that the Embarcadero has given us is “Can Castalia properly parse your code?”.  I submit the following statement:  If Castalia has trouble parsing your code, then the first place you should look to solve the problem is in your code. Code that gives Castalia – which has a pretty good parser – a hard time is maybe just a touch over complicated or not well formatted.  Just a thought. Just my personal thought.
  • Yesterday I attended the Philly.Net Code Camp.  There were at least 500 people there, including a larger percentage of women than I’ve seen before – or at least it seemed that way to me.  I spent the entire day in the same room on the “Scripting” track, learning about node.js,  “this” in Javascript, more about what TypeScript is, and what is coming in ECMAScript 6.  It was a good time and I learned a lot.  These events occur twice a year, and the Philly.net crew do an amazing job putting the event together.  Did I mention that these events  are totally free?  I’ve spoken at the event in the past, mostly on non-technical topics.  I’ll try to do that for the next one.  In any event, it was a good event.  If you are in the area (people came from as far as New York), I’d recommend it. 
  • I’m plugging away on my next book.  Two areas that are giving me – ahem – “challenges” are the Parallel Library and MVVM.  Coming up with good examples leads the difficulty.  Just getting my head around all the stuff in the Parallel Library is proving difficult, I must confess.  I don’t want to do any code with Sleep in it, so finding a good example of code that take up time is hard.  MVVM is proving difficult to find a good example using LIve Bindings, and actually doing the “true” MVVM way as defined by Rob Eisenberg. I also have to get this chapter past Stefan Glienke, too. Hehe.   In any event, I promise by the time I publish, you’ll have a good solid chapter or two on those subjects that will make you smarter for reading them. 
  • As I mentioned above, I’d like to learn Typescript, mainly because you can apparently not have to learn many of the vagaries of Javascript while being able to achieve the same result.  However, Amazon seems a little thin on books. Anyone got any good resources for Typescript?  I found some good resources for node.js, the avenue that I want to approach Javascript from, but the resources on Typescript are a bit lacking. 

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:

https://leanpub.com/codingindelphi/c/delphiweek

Thanks!

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.

Flotsam and Jetsam #94

Flotsam and Jetsam #93

  • In my post about my new book, I mentioned that I thought my outline was a little thin, and indeed it was.  I left out a large topic about which I planned on writing – “Writing SOLID Code”.  Add that in, and things seem a bit more fleshed out.  The silly thing was that I was working on that chapter when I put together the outline and wrote the blog post.  Anyway, the outline has been updated and all is well.  Thanks again for the support.  If you want to keep up with the book’s progress, help out answering my silly questions, and generally be supportive, you can sign up at the LeanPub site, or you can join the Google Group
  • Here’s some food for thought for my post about not using nilThe Null Object Pattern.  Yet another reason never to return nil.  Instead of doing that, you can return a null object that won’t cause an access violation and yet won’t do anything.  You can check if the object is a null object if you need to.  Win all around.
  • So the rumors were true – Embarcadero has bought the main products of TwoDesk Software.  Jacob Thurman has stated that while he’s not now an Embarcadero employee, he will be working on the Delphi IDE.  I guess it’s none of our business exactly what the relationship will be, but if Jacob is working to improve what the IDE can do with code and to improve developer productivity in the Code Editor, I’m very happy.  I know that Jacob has had a lot of things that he wanted to do, but found it difficult as an “outsider”.  Now that he’s an “insider”, I hope he can do them.  I think we’ll see some fun stuff coming out of this deal. Congratulations to Jacob, who I hope was well remunerated, and to Embarcadero for the wisdom to see and acquire Jacob’s skills.
  • True words tweeted by me: “There are two things that developers love to do: Make pronouncements, and point out the exceptions to other developers’ pronouncements.”  I like to make pronouncements as you’ve probably noted.  I’m always trying to learn new things and new ways of doing things, and I don’t want to be held back by the “well, we’ve always done it that way” way of thinking.  I believe that the way software is developed is evolving and improving, and that we’ve found new ways of doing things better.  I try to learn those things and blog about them.  That’s what I’m trying to do here.  If you disagree with what I say, I welcome your comments. But I ask you to consider that maybe I’m actually on to something.  I’d encourage you to take the same path I have – the path of learning these new things that developers are finding and doing.  For instance, I don’t ever intend on writing another Delphi application without utilizing MVVM.  But ten years ago, such a thought would have occurred to almost no Delphi developer.  I encourage you to study the SOLID principles, to read Clean Code, to find better ways to decouple your code, and to generally seek out new thinking about software development.  I’m a firm believer that there is always a better way, and I encourage you to think so as well.

On the Use and Acceptance of nil

Yesterday I made the following tweet:

and it started and interesting little discussion on Twitter.  (I was actually honored that the great Mark Seemann himself entered into the fray…) Naturally, the conversation tried to point out why I was wrong, and all the ways that it was fine to use nil.  That’s okay – if there it is one thing developers like better than making pronouncements, it’s finding exceptions and arguing against other developer’s pronouncements.

Well, I remain unconvinced and stand by my statement.  No surprise there, I know.

There are two parts to what I said and I’ll argue them one at a time.

First – “never pass nil to a method”.  Now people freak out about “never”, but it’s Twitter and you don’t have a lot of room for caveats.  First, sometimes I guess you have to pass nil to some methods  — ShellExecute  comes to mind —  but I’d argue that those methods are poorly designed (as I’ll talk more about in a minute), and that you should pass nil only very, very reluctantly.  Again, I’m talking about your code, not other’s code.    You should never send nil to a place where a valid object will be accepted.  Never do that to someone’s code.  Returning nil is always a bad design decision.

The Robustness Principle states, in part, that you should be very precise in what you pass, and passing nil is not precise.  It misses the mark by as much as you can miss the mark.  The target is a valid, working instance of whatever the method is asking for, and passing nil is like turning 180 degrees around and firing your arrow away from the bulls-eye.  Nil should not be used as a “signal”, leaving the class you passed it to in a state where they can’t make use of what you’ve given them.  You should avoid like the plague allowing a  class to be in a state where it can’t do what it is designed to do, and if it asks for a object in a method or constructor, you are obligated to pass a working, constructed object that it can use without error.  To do anything else is to invite an exception or worse, an access violation.

The second part is this:  “Don’t let your methods – especially your constructors — accept nil as a parameter value”.  Your classes should never let themselves get into an unusable state, and blindly accepting nil as a parameter will do that.  Instead, your classes should carefully guard against being passed nil and quickly – no, immediately – fail if passed a nil reference.  There is even a pattern – the Guard Pattern – that is employed to ensure that a program won’t continue unless things are acceptable.  Getting nil is not acceptable:

Every single time you accept an object as a method parameter, you need to use the Guard Pattern to prevent your object from being placed in a bad state where it can’t do what it is supposed to do. Fail fast and tell the user exactly what they did wrong and what they need to do to fix it. In fact, if a nil reference sneaks in, you’ll eventually get an access violation when you try to use this nil reference, right? Sure, it’s work, but it is time well spent.  Knowing that your references are always valid makes for easier code, and actually can reduce the amount of nil checking that you have to do.  Who wants to check for nil every time you use an object?

Don’t pass nil references.  Don’t accept nil references.  This seems obvious to me and I confess I don’t understand objections to this aphorism that only results in cleaner code.   Why would you ever want to accept a nil object?  Why would you want your code in a state that is begging for an access violation to occur?  Insist that your objects are valid, and never impose invalid objects – nil – on others.  Seems blatantly obvious to me.

So I am going to guess that this will not make some of you happy.  So here is my challenge:  Show me code that you have written where nil is acceptable.  Don’t show me code that calls the Win32 API or the VCL, show me code you have yourself written where nil is acceptable and useful as a valid method parameter.  I’d love to see it – and then point out the problems that it will cause.  🙂

Delphi and #Code2014

Hey, Delphi ended up really well in the #code2014 survey.  Sure, it’s self-selected and thus statistically dubious, but it definitely is nice to see Delphi in ninth position with a prominent circle.  (If you add Delphi and Pascal together, we’d be in sixth place.  Yes, I can see the comments already…)

If I were part of EMBT’s marketing team, I’d be shouting this one from the mountain tops.  I know that technically it’s not statistically significant, but the whole chart “feels” right.  The languages at the very top seem like the right ones.  And Delphi at the ninth position seems right too.  Why?  Because I think there are a lot more Delphi developers out there than people know.  Is it more popular than C/C++?  Maybe not, but then again, maybe it is.  No way to know. 

The part that bums me out is the community members that are so quick to point out that the survey “doesn’t mean anything”.  I most strongly disagree.  I think it means a lot.  I think it shows that the Delphi community is real, it’s bigger than folks think, and it’s willing to speak up and be heard.  All I know is the Delphi community sure came out of the woodwork and made Delphi rise into a prominent position in a poll that many developers will see. That can’t be bad.  It is good.

If you are a Delphi developer, you should be happy about this, and you should be doing what you can to show people the results.  I took a screen capture of the results in case the URL goes away (www.code2013.com is for sale for a mere $3095).  If you are a Delphi developer and are poo-pooing the results, I say “Lighten up, Francis”. 

This is good.  Enjoy it.  Use it.  Delphi is still here and going strong, almost twenty years after it launched.  We’ve had our ups and downs, but the bottom line is that you have nothing to be ashamed of when you say “I am a Delphi developer”. 

Flotsam and Jetsam #92

  • We have a vibrant .Net community here in the Eastern Pennsylvania/Philadelphia area.  Philly.Net runs events once or twice a month at the Microsoft campus, and semi-annual Code Camps that are usually attended by well over 700 people.  I attend whenever I can.  But I’ve noticed something interesting over the last year or two:  almost all the coding topics are now Javascript-based.  I see them doing very few C# – based presentations.  This event is pretty typical.  (I am going to be attending this one, by the way…..) Anyway, just an observation that I think is interesting.
  • If you aren’t satisfied with the RAD Studio IDE’s bookmarking system – and you shouldn’t be as it leaves a lot to be desired – you might be interested in the free IDE plugin called Parnassus Bookmarks from David Millington.  It works great, is totally free, and is a solid replacement for the existing system.   Download and install is recommended.
  • Well, Delphi has done really well in the #Code2014 survey.  Thanks to everyone who tweeted.  It’s nice to see Delphi up near the top in a very respectable position.  As of this writing, Delphi is only 19 tweets behind C++ – nothing to blow your nose at.    Javascript continues to dominate in a pretty big way, nearly doubling the second place Python.  (See my comment above).
  • New Project of the Week:  Another gem from the inestimable Malcolm Groves – TStateMachine.  From the README:  “TStateMachine is a framework for declaring and running state machines in Delphi. It supports generic types for states and triggers, anonymous methods for Guards and Effects (State.OnEntry? and State.OnExit?), and a Fluid interface for configuring the State Machine.”  Very interesting and worth a look.  Maybe even worth a new chapter in my book.
  • Cary and Ray have set the agenda for their Delphi Developer Days conference.  Again, this is always a high-quality event, and I try to make it every year.  Word of advice: Don’t ever miss Ray Konopka when he is speaking.  He’s very, very good.

More Coding in Delphi

First of all, I want to once again thank all of you who have purchased, read, or otherwise supported my book Coding in Delphi.  I’ve said it before and I’ll say it again  — the response has been overwhelming and humbling.  The book has been more successful than I could have ever hoped for.

It’s so successful, in fact, that I’ve decided to write another one – More Coding in Delphi.  I am once again using the LeanPub publishing platform.  LeanPub is really an interesting tool – it makes it really, really easy to produce a book. Highly recommended.  You write the book in Markdown, and they take that and turn it into PDF, MOBI, and ePUB files for you.  Easy as pie.  I’ve been using MarkdownPad for writing the book.  It does a nice job of helping you write Markdown text. 

By default, LeanPub uses DropBox.  First, I granted LeanPub access to a shared folder on Dropbox.  Then, when I go to publish a preview or the real thing, LeanPub looks in that folder for a file called “Book.txt” which describes the format of the book by pointing to *.md files.  It then accesses those files in the shared folder and creates the book. 

This time around, though, they’ve added a new feature where you store the book in GitHub and they pull from the repository to get the files for the book.  Cool.  When the book is ready for proofing by any of you interested in doing so, you’ll get access to the manuscript by pulling it from the private repository on Github.  So if you want to help out, you’ll need to brush up on your Git. SmileIt also means that I get the benefits of a DVCS, and you guys can make pull requests if you have improvements for me. 

Right now, the outline for More Coding in Delphi is currently:

  • Four Thoughts on Coding Before We Start
    • Encapsulation, CQS, Postrel’s Law, Compostion over Inheritance
  • Duck Typing
  • JSON
  • Aspect-oriented Programming
  • Design Patterns
    • Observer Pattern
    • Adapter Pattern
    • Decorator Pattern
    • Another Pattern to be named later
    • Another Pattern to be named later
  • Parallel Programming
  • Model-View-ViewModel

That feels a little thin to me right now, so I am seeking more topics.  If you want to suggest anything, I’m all ears — either comment here on this post, or join the Google Community for the book.  Remember the philosophy of the book, though – it’s all about the code.  I’ll write about code frameworks, RTL type stuff, etc., but I don’t want too many screen shots of forms in the book.  There will be some in the MVVM chapter, but the idea is that the book covers code and how to write good code.   That’s what I want to focus on.  I’m also open to turning “Four Things” into five or six or seven things, so if you have small topics – a page or two, not enough for a full chapter — I’d love to hear those as well.

Okay, so now the real work begins.  It’s a lot of work to write a book. My hope is to have the book published by the end of this year.  I know that I can’t do it without your help – you guys made the first book possible.  Again, I’m grateful to all you readers and supporters. 

Flotsam and Jetsam #91

  • It’s #Code2014 time again! Time to tweet out what languages you used for the year.  Just list your languages and include the hashtag #code2014, and they’ll do the rest.  Of course, you can include Delphi all you want.  I won’t mind.
  • Looks like Ray Konopka will be replacing Dr. Bob this coming year for Delphi Developer Days.  If you haven’t heard Ray speak, he’s excellent.  Really excellent. I’ve been to DDD three or four times, and it’s always great.  Adding Ray this year will maintain the high standards that it has always had.  Looks like Dr. Bob is just taking some time off from traveling, and Ray is stepping in.  Sounds great.  And as Cary notes in his blog post, you can get a reduced rate if you register early!  Smile
  • In a recent post, I talked about IncludeTrailingPathDelimiter and why you should always use it with your path strings.  I should have mentioned that there is also a ExcludeTrailingPathDelimiter that is part of the RTL, too, which does what it says – takes off the trailing path delimiter if it is there.  I’m not sure why you’d want to do that, but hey, there it is. 
  • Happy New Year, everyone.  I hope that 2015 has everything in it that you want and hope for.  In case you were wondering, my New Years Resolutions are to finish my new book and 1920×1080.

Never Assume Your Paths Have Ending Delimiters

I think I’ve mentioned that I have a “challenging” codebase that I deal with in my day job.  It’s a classic Delphi legacy app, worked on by numerous different people over the years with multiple different styles and techniques. Part of the product includes the use of an Address Engine – a third-party utility that “scrubs” addresses and ensures that they exist and that they are in a Post Office acceptable form.

Recently, we’ve had to change Address Engine providers.  It should have been easy – I had created an interface to isolate the engine before the switch.  So I got the new engine all plugged in, ready to go, and it all should have worked.  But try as I might, I couldn’t get anything but garbage data out of the engine.  Argh.  It simply wouldn’t return any data.  Now mind you, the DLL in question was written in C, and I had a translation of the *.h file that I was pretty confident in.  It all should have worked.

But the problem was much simpler than that – the *.ini file that had an entry for the path to the postal data was missing an ending backslash.  That was it.  I put the trailing backslash on the entry (why didn’t the installer do that?) and it all worked.

Which brings me to the point of this blog post:  Always assume that your paths don’t have that trailing delimiter, and that it is your responsibility to put it there.

In fact, the RTL provides a routine that allows you to do that very thing:

IncludeTrailingPathDelimeter will place either a backslash or a forward slash on the end of a path, depending on the operating system’s definition of a path delimiter if there isn’t one there.  If there is, it will do nothing.   You should use it to ensure that every path string you use has a delimiter on the end of it.  Your code should thus assume that all paths have that trailing backslash on it.  If you have code that looks like this:

this should be changed to

The former code can be buggy – what if SomePath already has a trailing delimiter?  You’ll end up with an invalid path.  The latter code has no such problem.  It is safe both ways – with and without the trailing delimiter.  This is especially necessary when your paths come as a result of user input, such as that *.ini file above.

The moral of the story:  Never assume that your path variables have a trailing delimiter, and always wrap them up with IncludeTrailingPathDelimiter to ensure that they do.