Amazon.com Widgets November 2012

Blast From the Past: Stuff that Bugs Me

By Nick at November 29, 2012 23:03
Filed Under: General, Blast from the Past, Delphi

I don't know what I ate on April 1, 2006, but apparently it didn't sit well.

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

Blast from the Past: Why You Should Choose Delphi

By Nick at November 29, 2012 00:01
Filed Under: Delphi, Blast from the Past

Another classic for the Blast from the Past file, this time from CodeFez on November 27, 2004.  Eight years is a long time for Delphi to be dying.  Winking smile

 

People are always asking “Why would I use Delphi when I can use C#? Why would I go with Borland's tool when Visual Studio and clearly closed the gap?” I think that is totally the wrong question to ask. The real question is “Why should I be using C# when I could be using Delphi?”. Here's some of the reasons why the latter is the real question to be asking:

    Delphi is easier to read. Delphi thankfully isn't a C-language descendant and so it doesn't use the ugly, horrible to read C-like syntax of say C# or Java. It uses easy to read works like 'begin' and 'end' instead of hard to read symbols like '{' and '}'. It uses a readable, sensible syntax in 'for' loops. It requires that you declare variables before you use them, ensuring that the definition and type of variables are easy to determine. It forces you to declare classes and routines in the interface section of a unit, making for much easier analysis of already written code.

    You already know Delphi – if you are currently a Delphi developer, Delphi has you covered in .Net. There isn't a single thing that can be done by other tools in .Net that you can't do in Delphi.

    Delphi has better data access. The BDP – Borland Data Provider -- provides a much cleaner and well designed interface to ADO.NET than the FCL does. The FCL doesn't provide enough abstraction over ADO.NET to even provide a single set of components to access data with ADO.NET. Access to Oracle and SQL Server require completely different sets of components and types, making providing a single-source, common front end to data impossible. The BDP, on the other hand provides that single interface, even provides components that allow you to mix data from differing databases into a single dataset. Other languages and tools don't even pretend to provide this advantage.

    Delphi is cross-platform. Delphi code can be cross-platform between .Net and Win32. Code bases can, with a bit of work, even be used in those two platforms plusLinux. Delphi is the only .Net language that provides that level of compatibility between Win32 and .Net.

    Delphi can expose .Net functionality without COM/Interop – this is an unsung feature of Delphi. Want your Win32 applications to have access to encryption? Regular expressions? Anything else in the FCL? Delphi can provide it without COM.

    Delphi can link .Net code into your EXE – Delphi provides the ability to link code into a single EXE instead of having to worry about deploying all the right assemblies in all the right places.

    Delphi handles and names events the right way. Is there anything more confusing in the .Net framework that delegates and how they are used to handle events? No, there isn't. Delphi handles this all the right way, hiding the silly, confusing way .Net does it. Instead of the confusing C# syntax, Delphi uses the model that has been proven for over ten years. Need to add an event to a component? Delphi does it clearly and simply – like it does everything.

    Delphi does IDisposable correctly. -- Only slightly less confusing than delegates is the concept of IDisposable. Do I call Dispose? Do I need to? How do I know? As long as you follow the time-test method of calling Free on any object you create that doesn't have an owner, you'll be fine in .Net. If Dispose needs to be called, Delphi will call it. If not, it won't. No more guesswork, and your code will even be compatible on the Win32 side of things.

    Delphi has been doing “Avalon” for ten years. The hot new thing over at MS is “Avalon”. Avalon is a system for storing properties and information about forms and objects in a text file separate from the silly InitializeComponents call in your code. Sound familiar? Yeah, thought so. (Side note: Partial classes crack me up. Only Microsoft could invent a “feature” solely for the purpose of making up for a gross shortcoming in their language.)

    Delphi has datamodules. Is there a bigger oversight in all of the FCL than the lack of a datamodule-like class? Sure, you can 'simulate' datamodules, but it's a poor simulation at best. Put your database controls in a datamodule, and add the datamodule's unit to your uses clause and the Object Inspector is smart enough to see the components in the datamodule when looking at another form or whatever. Datamodules let you decouple data access and other abstract concepts from the user interface of your application. In other words, datamodules rock, and other tools and don't have them.

    Delphi's third-party market is way more mature than the .Net market in general. Sure, there are tons of components out there in the .Net market. But Delphi component builders have been at this for a decade, and have the years of experience needed to build excellent components the right way. Are you going to try to tell me that Ray Konopka and the DevExpress folks don't have it all over the johnny-come-lately folks that have been building components for a year or two?

    ECO II – Delphi has a mature, existing, shipping model driven architecture that is written by people who truly understand object-oriented programming. Microsoft doesn't. They have some thoughts and ideas outlined on a web-site somewhere and promises of functionality that they don't even really understand yet. Delphi is light-years ahead in this area, and there is no reason to believe that they won't stay that way.

    Borland's ALM solutions are here now, not “in the vaporware pipeline”.Microsoft is touting Team System or whatever they are calling it. Sounds great and all, but of course Borland is selling that technology right now, not just talking about it..

And that is just scratching the surface.  You'll probably add even more reasons right here in the comments. Personally, I can't understand why anyone would ever choose C# or VB.NET over Delphi.

How about you?

Blast from the Past: Delphi Books and the Publishing Market

By Nick at November 27, 2012 02:21
Filed Under: Delphi, TechBiz

Yet another Blast from the Past.  This one was originally posted on May 2, 2006 and is another one that holds true six and a half years later.   It's fun to note that the number of Delphi books out there appears to be increasing as it becomes easier to publish and the bookstore becomes practically the last place you'll go to get a Delphi book.

I'm nearing the end of a pretty big project at a client very near our office.  I've been going in ever day full-time for the past few months.  I've really enjoyed working there, as the folks are nice, the development process is very professional and quite good, and the camaraderie quite enjoyable.

Now that the project is winding down, I've had a chance to actually do a bit more visiting and kibitzing with the folks there about general topics concerning development (plus various forays into the Civil War, American Idol, etc.)  The topic of Delphi books came up, and one of the guys, Randy, made a good point.  He noted that the reason that there aren't that many Delphi books out there is that there doesn't need to be that many good Delphi books out there.

The books that are out there are complete, comprehensive, and well done.  For instance, there are really two books out there right now for Delphi:  Delphi for .NET Developer's Guide by Xavier Pacheco, and Mastering Borland Delphi 2005 by Marco Cantu. Once you've bought one (or both) of these books, you've got pretty much everything you need.  Xavier's book covers pretty much everything you need to develop in Delphi for .Net, and Marco's book covers both .Net and Win32 development.  If you have Marco's book, for instance, you really don't need any other books.

Another factor in limiting the market for Delphi books is that Delphi is a mature product.  It's users are to a large degree familiar with the language and the tool, and thus the demand for books that cover the basics is limited.  There just aren't that many folks out there that need to buy a book about Delphi anymore.  (Now, we can argue that we all need to figure out a way to increase the number of folks that want to buy books, but that is another blog post.) And since there are so many facets to Delphi, any book on an advanced topic would be of limited interest.  And for topics like ASP.NET, there are so many C#/VB.NET based books out there, the content of which is 99.9% useful to a Delphi developer, that there's little reason for a publisher to go to the effort of putting out, say, an "ASP.NET for Delphi Developers" book -- as much as I'd like to see such a thing.

In addition, the presence of resources like http://groups.google.com makes finding answers to questions and problems easy.  It's a rare day indeed when I can find an answer to a question using the newsgroup archives.  This is an invaluable resource, when you stop to think about it.  Shoot, just Peter Below's responses alone are worth their weight in gold.  Smile  It might very well be that the excellent support received in the newsgroups has limited the market for Delphi books as well.

The bottom line, it seems to me, is that there aren't that many Delphi books out there because we just don't need that many Delphi books.

So what is the future of Delphi books?  I think it's with something like lulu.com.  Lulu.com couldn't be easier -- you send them a PDF, and then they'll print out a real book whenever someone pays for one.  No muss, no fuss.  Basically you are 100% in charge of the PDF, and you get 80% of the selling price. Someone like Ray Konopka, who sells his class Delphi Component Development book online as a PDF, would be perfect for something like this.  You want to publish your own Delphi book?  There you go.  The size of the audience matters not.  You want to buy a book?  Encourage authors to use a service like Lulu.com to publish their materials.  Heck, publish one yourself.  The overhead costs seem quite small, and overall, it seems pathetically smart and simple.

I suspect that services like lulu.com will florish and only get better and cheaper.  The stack of Delphi books at your local Borders (weird -- that link basicall goes to amazon.com...) might not be that tall, but the amount of information available to Delphi developers is still staggering.  I've never been a big believer in the "books on the shelf equals market strength" theory -- at least in the sense that I think Delphi's market strength is much, much stronger than one might conclude from a trip to Barnes & Noble.  Delphi book publishing need not be dead, it just needs to shift to a new way of doing business.

Blast from the Past: Takes One to Know One

By Nick at November 25, 2012 13:15
Filed Under: Delphi, Leadership, Software Development, TechBiz

This one is a Blast from the Past -- I originally wrote and posted it on December 15, 2005 -- but it is as true today as it was then.  I even considered palming it off as fresh material. Smile

It's a standard Dilbert joke that managers are idiots.  One doesn't have to hang around programmers too long to find out that many of them work for managers that don't have a clue about developing software and thus make many a nutty decision based on profound ignorance.  Plenty of  Delphi fans have had a boss that follows the "Nobody ever got fired for choosing Microsoft Development tools" rule and choose Visual Basic as a corporate standard. <shudder>  And the old adage states that programmers make crappy managers.

So, I guess, based on the above, it's impossible for someone to be a good manager of programmers.  If one doesn't know anything about programming and has never been a programmer, then apparently, he will suck as a manager.  And if one has been a programmer, and is so good at it that he gets promoted to be a manager, he,too, will suck as a manager.  Sounds like a lose/lose situation all around --   programmers doomed to a life of sucky supervisors.

Well, I'm not buying it.  Surely somewhere, somebody is managing programmers well.  Somebody has to be leading folks to build some of the insanely good software projects that are going on out there.  So, what does it take to manage programmers well?  Good question.  I'd say that such skills and capabilities exist.  I'd also say that they are, sadly, in relatively short supply.  Too many Dilbert strips end up on too many cubicles in software development shops.

First, to be a good manager of programmers you have to be,well, a good manager.  That's easier than people think, really.  Here's my basic list of things one can do and not do to be a good manager:

  • Place the careers of the people that work for you above your own.  Never, ever, ever, ever, ever take a dump on an employee to make yourself look good to your boss.  Always let the boss take a dump on you instead of your employee. Take responsibility for everything bad that happens under your watch.  Dole out all the credit for good things that happen to your people.  If you have some bizarre, overwhelming need to impress and brown-nose your boss, let your employees make you look good.  It's your job to make your employees happy and productive.  It's not your job to get promoted.  (And do I need to say that if your employees are happy and motivated, then they'll do a good job, which means you are doing a good job?)
  • Place the needs of the employees over your own.  What's the quickest way for a Marine Corps officer to be considered the biggest jerk since Josef Stalin? Get in the chow line ahead of his Marines.  Officers don't eat until the troops do.  Take the same attitude, and your people will love you and work hard for you.  Give them the good computers.  Give them the good chairs.  Don't take a perk for yourself until they all have it.  Believe me -- they will notice this.  Another way to state this is don't ask your employees to do anything you yourself aren't willing to do. If you want your folks to work 12 hours a day, you need to be there 13 hours a day.
  • Recognize that your employees know what they are talking about and might actually know more about some things than you do.  (If they don't know what they are talking about and they don't know more about some things than you do,  then you need to get new employees).  If your employees seem to think that the WonderWidget is a much better solution to a problem than the SuperSprocket, then, hey,  maybe, just maybe, they are right.  Just because you read about the SuperSprocket in some magazine that takes $4.6 million dollars a year in advertising from SuperSprocket, Inc., doesn't mean that is the way to go. 
  • As a follow on to that, don't try to impress your employees with your knowledge.  Don't spout buzzwords unless you know what they mean. They probably are going to think that you are an idiot anyway, so feel free to appear to be ignorant about things that, well, you are ignorant about.  If you don't have a clue about what the best printer is for the needs of your team, then let the folks on your team that do know about such things choose the printer.  If you don't know the answer to something, say so.  The quickest way to be thought an idiot is to try to act like you know what you are talking about when you don't.
  • Manage yourself out of  a job.  The best managers are the ones that sit in their office all day surfing the internet because they've set things up so that their people can take care of everything and thus they don't have anything to do.  People love being the ones with the power, authority and skill to do the work. If you are in their shorts all day, making all the decisions, doing all the work, and taking all the credit, you will be a crappy manager.  Once you've managed yourself out of a job, then, besides surfing the net, you can spend all your time making things even better for your employees and protecting them from the foibles of your boss. 
  • Encourage your employees to tell you what is bugging them.  When I was running a 24/7 Intelligence Watch, I told my people that if they found a Dilbert cartoon that exactly described a stupid, irritating, or aggravating situation in our organization or something that I was doing that was "pointy-haired-boss-ish", they could bring it to me or put it on my desk anonymously.  If you are totally committed to the first two items on this list, they will come to you. If you aren't, they never will.  And if your employees aren't bringing issues and complaints and problems to you, then you have a big problem.
  • Reward your employees with what they want to be rewarded with.  Frankly, this is usually good old cash money. But if you can't do that,  perhaps they want better computers, a nicer desk chair, a day off, whatever.  If you want to reward someone, find out what they want and give it to them.  But please, PLEASE -- I'm begging you here -- do not call a big meeting and pass out a "Worker of the Week" award with some cheesy certificate ginned up with Microsoft Publisher.  When I was in the Navy and at a joint command, I had an Air Force Colonel that did this, and he was universally mocked and reviled for it. Everyone thought it was a joke.  No one wanted that silly certificate and everyone hoped and prayed that they wouldn't "win" the thing.  Those that did posted them like they post Dilbert cartoons on their cubicles -- sort of like a badge of "dishonor".

Now, that's all general stuff.  It applies to all managers, whether they lead a team of auto workers or a group of Delphi programmers.  What does it take to manage programmers well?

  • I think that to be a good manager of programmers, you have to be, or at least have been, a programmer yourself.  This goes against the conventional wisdom, I know, but I think that in order to understand the way programmers work, you really have to have done it yourself.  It's true that many programmers would make bad managers, but it doesn't follow that every programmer guarantees that one will be a bad manager.  Programming is one of those strange professions that mixes right- and left-brained skills.  To program well, you have to have an ordered, mathematically oriented mind, but at the same time you have to come up with artistic, creative solutions to puzzles and problems.  One really needs to be one to understand one.  Now the hard part here is that most programmers don't want to be managers. Alas -- a quandry there, eh?  Well, if you run across one thatdoes, don't hesitate to consider it.  If you are a programmer and want to be a manager, let your bosses know, they'll probably be happy to hear it.
  • Give programmers what they want:  challenging work, a quite place to do that work, a good fast computer, a good salary, and the opportunity to expand their skillset.  Don't be cheap on these things.  This may cost a bit more,but you'll make it back in spades.
  • To as large a degree as possible, let programmers choose the tools that they use.  I know, I know, this isn't always possible.  Sometimes those decisions are made above your pay grade.  But then again, if you use Delphi under the table to produce a solution twice as fast for half the cost, then maybe Delphi won't be under the table for long.  If one of your guys wants to try to build that new intranet application in Ruby On Rails, let him.  Why not? Who's going to know?  If it works and gets deployed early, it's likely that no one will care what tool or language was used to make it, and now you have a new skill in your quiver.
  • Be flexible.  Some programmers do their best work between 10:00pm and 04:00am.  Let them.  Some hate to wear ties, dress shirts, khakis, etc.  Don't make them.  Some are flat out nuts.  Let them be.  Nothing wrong with all of that as long as they produce good code, eh?

Okay, that's a pretty good list.  I've been on both sides of the fence, and as a consultant, I see all sorts of management types and methods.  I deal with programmers on a daily basis, and I are one myself, so I think I have a pretty good grip on what's going on from a lot of angles.  I'm sure you all will come up with more stuff and comment on it.  Please do.  After all, I'm not an expert on this stuff and I only write this to try to make you look good.  ;-)

Flotsam and Jetsam #70

By Nick at November 23, 2012 12:16
Filed Under: Flotsam and Jetsam, Delphi
  • Looks like Bjarne Stroustrup himself will be part of the C++ portion of CodeRage7.  That's quite a coup.
  • LeanTed now has its own URL:  http://www.leanted.com
  • Anyone out there know about TSynEdit?  Which is the "one true version" that I should be using?  I'm using this one:  http://sourceforge.net/apps/mediawiki/synedit/index.php?title=SynEdit_Home_Page but it seems like there are/might be other better/different versions out there.  Anyone have any advice or thoughts on the matter? Also, anyone know about what encoding it uses?  Can I change/set it? I confess I can't seem to figure that out....
  • Delphi is really popular in Brazil, and Roberto Schneiders is a new blogger from that lovely country.  He's written his first post about DataSnap.  Nice.
  • Cloud storage certainly is all the rage. As far as I can tell, I have storage in the following places: DropBox, BitCasa, Google Drive, SkyDrive, Asus Cloud Storage, and Amazon.  And probably some others I can't even remember.  Here's a business idea that I'm sure has already been done because I just thought of it:  Create an app that aggregates all those different chunks of space into a single drive.  That would be cool.
  • Everyone seems worried about Best Buy -- apparently they are all doomed and everything in the face of Amazon -- but I can tell you they didn't look doomed last night at midnight.  I was awake and decided to attend their Black Friday event at my local store, which started at midnight. (I had not intention of, and did not, buy anything...) The place was an absolute mad-house.  There was a *huge* line to get in when I arrive right at 12:00a, and they had a large maze set up in the store to keep people moving in the same direction.  I didn't notice any outrageous deals, but I can tell you that a lot of merchandise was available and a lot of it went out the door.  Plus it was fun -- great people watching.

Blast from the Past: Delphi may be the only choice you have

By Nick at November 22, 2012 01:08
Filed Under: Delphi, Software Development

Yet Another Blast  from the Past, this one from November 23, 2003.  This one is kind of moot now, as well, eh?

As frustrating as it is to us Delphi lovers, Delphi has always been a tough sell in corporate America -- not because Delphi isn't perfectly capable of performing any task that a corporate development team might throw at it, but mainly because many managers and decision makers aren't willing to take the perceived risk of investing in a non-Microsoft development solution. Borland has (rightly perhaps for a while in the past, but certainly not for a few years now) the reputation as being a bit on the edge financially, and so the safe, "nobody ever got fired..." decision has been to buy Microsoft. This will probably continue to be the case for some time, as Microsoft certainly will continue to be the a dominant company in the marketplace for the foreseeable future. However, I think the advent of the .Net Framework as the "platform of the future" and Microsoft's particular strategy for moving people to .Net both provide Borland and Delphi developers with a unique opportunity that actually makes Delphi the only safe development platform for a large number of projects that will be developed over the next few years.

Microsoft clearly wants us all to move to .Net, and frankly, I think we all should be happy to make that move. The .Net platform is really cool and really powerful. It provides a very capable and easily accessed framework (the Framework Class Library, or FCL) that is light-years ahead of the Win32 API. Microsoft actually seems to have finally figured out object-oriented programming. Once the actual framework becomes ubiquitous, or even the basis for the operating system itself , building, managing, and deploying applications will be much easier than it is now. I, for one, am eagerly looking forward to Delphi 8 for the .Net Framework and being able to develop applications with it.

Microsoft clearly wants you to move to the platform as well. They make it totally easy to download and install; every new operating system includes it, and they are on an all-out marketing campaign to raise awareness in the developer community in order to promote its use among software developers. The most interesting thing about all of their actions, though, is that they clearly want to force people to make the jump to .Net by pretty much cutting off existing development paths and by not providing a clear migration path for existing applications. It appears that the idea is to instill a bit of panic in their community of developers -- "Holy cow, we'd better get on this .Net bandwagon, or we are going to be left behind!"

Sadly, that is pretty much the case -- VB and C++ developers who don't migrate to .Net soon will be (are?) pretty much abandoned. Sure, there's "Managed C++", but what serious C++ developer would really want to use this neutered version of the language? VB6 developers are abandoned in the sense that VB.NET is so different from what they have done that it is pretty much a whole new language. Code written for VB6 simply won't compile in .Net. And of course, there were no existing C# projects before .Net was released. Therefore, if you are a Microsoft development shop, and you want to move to .Net, then you are pretty much talking about a complete rewrite of all of your Win32 code no matter what you were using to develop those applications. There simply is no easy migration path to .Net for your existing applications.

And that, of course, begs the question -- "What to do for a new application that needs to run on Win32 today, but that will eventually migrate to .Net sometime in the future?" This isn't an unreasonable question -- shoot, it is probably very common. There are certainly new development projects being started everyday, and .Net looms out on the horizon for all of them. It is also a question that is tough for Microsoft shops to answer. While the .Net Framework is readily available, it is certainly not ubiquitous, and there are plenty of machines out there in the corporate world, small businesses, and homes that can't even handle the .Net Framework and that won't be able to handle it for sometime yet. That means that Win32 may be the only option for new development. However, anyone starting new development today probably will want to be able to migrate that app to the .Net platform in the future. If you choose C++ or VB6 for the Win32 version, there simply is no easy way to migrate that application to .Net. Any Microsoft-based development solution for the Win32 platform today means pretty much a complete re-write for that application when it comes time to migrate it to .Net.

But hey, there is a solution -- a non-Microsoft one -- to this problem: Delphi. Delphi provides a powerful, fully-capable Win32 development platform, and with the VCL for .Net, a much, much smoother migration path for Win32 to .Net. And when you do move to .Net, Delphi 8 for the .Net Framework provides powerful tool that is a first class citizen in the .Net development world. If you are starting a new development project in Win32, and need to be able to move that project to the .Net framework some time in the future, then Delphi is your only real choice. Microsoft-only development organizations quite conspicuously have no similar choice. The VCL is cross-platform -- at least between Win32 and .Net. Applications build in Win32 using Delphi and the VCL should migrate relatively smoothly to the .Net platform today . VCL for .Net exists, and has been available to Delphi 7 owners via the Delphi for .Net Preview since last summer.

Now I am not at all claiming that the migration will be totally seamless -- you may need .Net version of third-party components, and if any of your code calls into the Win32 API directly, you'll need to update that. In addition, not all of the technologies that were in Delphi 7 will make it into Delphi 8, and certainly the presence of garbage collection in the .Net framework may affect the way your code works, but the migration is clearly not a complete rewrite as discussed above. Heck, at this year's Borland Conference, they compiled and ran in Delphi for .Net an application that was originally a demonstration application for Delphi 1 -- a 16-bit development tool! Can't get much more compatible than that.

This fact alone ought to be changing the way that developers and companies view Delphi. Delphi will drastically lower the overall total cost of a project by drastically reducing the time and effort needed to migrate a Win32 application that needs to be built today to the .Net framework tomorrow. Delphi doesn't lock you in to either Win32 or .Net and doesn't force you to move to .Net faster than you or your budget might want you to. Delaying the transition to .Net can also save money, as building applications in Win32 now for existing hardware can extend the life of that hardware rather than accelerating the hardware upgrades to run the .Net Framework.

Smart managers already know that they are stuck in a tough spot and smart Delphi developers will be quick to point out the advantages of using Delphi for new development. So if you have been looking for that silver bullet to convince your managers or your customers to use Delphi as the development tool for that upcoming project, you now have it.

Permalink|No Comments Yet|Login at the right or register with the site to add a comment.

Flotsam and Jetsam #69

By Nick at November 21, 2012 10:42
Filed Under: Flotsam and Jetsam, Delphi
  • I went to Philly Code Camp 2012.2 this past weekend.  It was a valuable use of time.  I learned a lot about Javascript (it has some unusual scoping rules) and ferreting out information about changes in databases (outer joins between old and new data can be revealing....).  In addition, I learned about a really cool add-in for most of the popular text editors called Zen Coding. It's pretty slick.  It makes writing HTML and CSS much easier.  For instance, type this:  html:5>head+body>div and then hit the hotkey for your editor and you get a nice template for an HTML five document, including the <head> and <body> tags, the DOCTYPE entry, and a <div> tag inside the body tag.  You can find out more about the extensive things you can do with it by watching this video, by reading this tutorial, and by looking at this cheat sheet.  Overall, another great code camp.
  • I completely forgot that I, along with Marc Hoffman, had the honor of being on .Net Rocks.  Cool!  It was great to see Carl and Richard at the .Net Rocks tour in Philly a couple of weeks ago.  They are really great, funny, smart guys, and they do a great job making development fun.
  • LeanTed now has basic support for table and crosslinks. The feature set is actually getting close to a 1.0 release.
  • All of the CodeRage 7 talks are online and available for viewing.  You can both download them and watch them on YouTube.  I like the YouTube part.  That's cool.
  • This video on MVVM and Delphi by Malcolm Groves of EMBT Australia is a must watch video.  This is how you should be building your applications from now on.  It's really made possible by Live Bindings.   You don't necessarily have to use the exact MVVM pattern than Malcolm shows here. He notes that an MVC or MVP pattern will do much the same thing, but we all really should be separating our concerns out so that we aren't coupling our code together. 

Blast from the Past: The Gaping Hole of Delphi

By Nick at November 20, 2012 22:56
Filed Under: Delphi, TechBiz

Another Blast from the Past. This one is mostly overtaken by events.  The sale of CodeGear makes the whole thing moot.  But I thought you might enjoy a trip down memory lane.  Things certainly have changed for the better.  This was originally published on January 6, 2006

 

Every situation, properly perceived, becomes an opportunity. ~ Helen Schucman

Yesterday I went on a sales call with two of the Borland sales reps for the region. Before hand, we met at a Dunn Brothers coffee shop to get our ducks in a row, talk about the client, etc. The meeting went well – the Borland guys are very knowledgeable, professional, and clearly know what they are doing and what they are talking about. The client could probably benefit from Borland's tools and hopefully there will be a deal done. I learned a lot about sales from the meeting. (Sales is not my strong point.)

The interesting part of the whole day was the epiphany I had while meeting with the Borland guys at the coffee shop. Sales guys are into revenue generating. They need to maximize the revenue that they get per hour of effort spent in getting revenue. That's their job. That's what Borland wants them to do, they are rewarded financially based on that, so naturally, that is what they do. I don't blame them. Opportunity costs are very real, and they have to choose where to expend their efforts.

If opportunity doesn't knock, build a door. ~ Milton Berle

The big thing I learned from the sales guys is that Delphi isn't even on their radar. They aren't given a commission on Delphi sales. That's frustrating. But here's the thing: even if they were given a commission on Delphi sales, I doubt very much that they'd sell much of it at all. Remember opportunity costs? Opportunity costs drive the salesmen to concentrate on the Fortune 100 to the Fortune 500 crowd, and the sad fact that we Delphi developers need to accept is that the market for Delphi amongst these large companies is very small. Those companies have probably already chosen their tools – either Java or Microsoft or some other open source solution – and while a concerted effort to sell Delphi into that market might work, the opportunity costs are just too high to make the effort worth it for a Borland Sales Representative. Delphi's traction is slim in that arena, but the traction for StarTeam, CaliberRM, and Together is very high. (Remember, it's all about revenue per man hour. Dollars per man-hour selling Delphi is pretty low. Dollars per man-hour for CaliberRM, StarTeam, and Together is pretty high. So, as a result, the Borland sales force doesn't sell Delphi and they do sell the enterprise products. This should not be a surprise.)

Let your hook always be cast; in the pool where you least expect it, there will be a fish. ~ Ovid

When we were at our TeamB conference in November, Boz Elloy basically said the same thing. He told us that “Fortune 100/500 companies don't want Delphi. It's a waste of time for us to try to sell it to them”. (My fellow TeamB'er Dave Nottage blogged about that meeting as well. For the record, Boz explicitly gave us permission to publicly discuss the meeting.) Boz drew a diagram with three levels: the “channel”, SMB, and Fortune 500. He basically said that they only try to sell Borland Core into the Fortune 500. (This is why you won't see Delphi having anything to do with Core. Core is Borland's Java platform, based on Eclipse, with perhaps some .Net mixed in, but only in the form of plug-ins to Visual Studio.Net) For the Small/Medium Business market, they offer Borland Developer Studio and the ALM solution. And the “channel” is sites like Programmer's Paradise that simply sell Delphi for Borland. For Borland, Delphi only really exists in the bottom two arenas. It simply doesn't exist in the highest bracket – but not to a level that would make the effort selling there worth it. (So, if you are a Delphi guy, and you hear stuff about “Borland Core”, just ignore it. I has nothing to do with you. Even though every fiber in your body screams out “Why isn't there anything about Delphi on the 'Core' pages!?!”, resist said temptation and simply let it all roll off your back. Core just isn't your deal. Now, when you hear “ALM”, your ears should definitely perk up, but Core? It's nothing to us Delphi guys. Let it go.)

Now, as I said, all this is very frustrating to a Delphi user. But if you step back for a minute, it makes perfect sense. Sales guys need to generate revenue, and so they spend their time doing that. Double the sales force won't alter this equation. It's purely a strange outcome resulting from the structure of Borland's product line. We Delphi dudes can bitch about this (and Lord knows we will), but the key thing is to get past the bitching, accept reality, and try to figure out a way to deal with this unfortunate situation.

In the middle of difficulty lies opportunity. ~ Albert Einstein

Okay, so I'm past the denial and anger stages (and I encourage all of you to get over the hump into acceptance as well), and ready to move on to trying to figure out what can be done to promote and expand Delphi. Every cloud has a silver lining. For every window that is closed, a door opens somewhere. In the middle of difficulty lies opportunity. (Someone stop me before I break my cliché meter). I really believe that there are any number of effective ways to market and sell Delphi given all of the limitations that we've already talked about.

The first thing to do is to examine the lay of the land. The thing that jumps out at me is this gaping hole that exists in the market. Delphi is sold almost exclusively in the channel. The folks that buy from the channel are, to a large degree, the little guys like us. We buy one, two, five copies for our development shop. If a medium-sized company wants to buy Delphi, they have to go to the channel as well. Unless they run into a Borland Partner that sells product, they won't get any personalized service. Delphi isn't sold into the Fortune 500 companies. But between the real little guys and the real big guys, there is this gaping hole where Delphi is useful and where lots of opportunities lay, but no one appears to be interested in taking advantage of these opportunities. These medium sized companies are ripe for the picking. I presume that many of them have modest development organizations. I presume that many are still evaluating .Net technologies. Many of them are using Visual Basic 6 – a product that has basically been abandoned by Microsoft. They know they need to make a move to newer technologies, but they aren't sure about it all. They aren't pleased with Microsoft, and would be willing to hear about products from a tools vendor that is almost compulsive about backwards compatibility and ensuring that old code can be moved forward. They might be interested in hearing about a company that is continuing to focus on RAD development in the Win32 space.

In addition, I also look out, and I see products flourishing that don't have any corporate backing (Think Ruby, Python, or Perl). These products are known and used, despite not being hawked by professional salesmen. How do they do it? They use the Internet. They use word of mouth. They use “guerilla marketing” techniques that cost very little and can reap large rewards. I see no reason why Delphi can't benefit in the same way.

Opportunities multiply as they are seized. ~ Sun Tzu

Here's an idea. Offer a free copy of Delphi Personal to any Visual Basic developer that will go on his blog and post a picture of himself holding a sign that says “I'm a VB developer and I want to try Delphi,” or witty variations thereon. If there is no Delphi Personal, send them a trial disk and a t-shirt. Something. Have them email their links to Borland so they can be posted on a webpage at www.borland.com. Get some buzz going on the VB community about Delphi – even if some of them get mad. Remind disgruntled VB developers that Borland has always and steadfastly promoted backwards compatibility and will never abandon them. The transition from VB 6 to Delphi isn't all that much harder than the transition from VB6 to VB.NET, so there has to be plenty of sales to be had in this arena. Give away a copy of Delphi Architect to the guy with the coolest, funniest, or most outrageous picture.

How about an affiliate program? If you click on the link in the upper right corner of this blog and buy a copy of FeedDemon, I get a kickback. Hence, I take every opportunity I can think of to mention the fact that if you click on this link and buy FeedDemon, I get a kickback. Good for me, good for FeedDemon. I'm also constantly hawking Amazon products as well. (Heck, I'd be a NetFlix affiliate, but they turned me down!) Now, wouldn't it be cool if we had a similar program for Delphi? Of course it would. You'd put a link on your blog, wouldn't you? Wouldn't you like to make a little cash selling the product that you love so much? Of course you would! Can you think of a reason why Borland shouldn't have such an affiliate program? I sure can't.

Finally, it would be great if, in addition to an affiliate program, it was fairly easy to become a value-added reseller (VAR) for Delphi. As a guy who's company tried to do this, I can tell you that it was really, really difficult to sell Borland products for Borland. We had to front the cash for all purchases, and deal with a maze of bureaucracy to get product delivered to customers. It sure would be nice if we simply had a vendor ID number that we could use to order product for our customers online. It sure would be nice if Borland recognized and knew the consultants that actively want to sell Borland products. It was way, way to hard for us to sell Borland products, and if it is one thing a company ought to do, is make it easy for your fanatical supporters to sell your products.

If a window of opportunity appears, don't pull down the shade. ~ Tom Peters

Delphi has a great opportunity to make a lot of traction in the current market. There is a big transition to .Net going on, and many, many organizations haven't yet made the move. Many, many organizations still want to do Win32 development, and Delphi is really the only path from Win32 to .Net, as well as the only RAD tool still actively supporting Win32. Opportunities are only valuable if they are seized, and as Sun Tzu noted, they multiply when they are seized.

The problem of course, is that Delphi is caught between two worlds. It's stuck somewhere in between the grassroots, individual developer market and the big money, big company enterprise market. Delphi's position inside Borland makes it a bit of a red-headed step child. I think the product needs more autonomy to thrive. (That's why the idea of Delphi being sold and becoming part of a separate company was pretty appealing to me.) Delphi's bright light all too often is left back in the garage, and it needs to be brought out and allowed to illuminate the marketplace. The mistake that Borland makes, I think, is in utterly ignoring this gaping hole. If you go to www.borland.com, the content will vary, but you'll almost always see information about Core and about items of interest to Enterprise-level decision makers. What you won't see is “Small/Medium Businesses Click Here” or something like that. There practically nothing there for them. If Delphi is going to be treated differently than the Core/Java offerings, then there at least ought to be a place on the Borland website where the people that Delphi/BDS/ALM is aimed towards can go and get information. Again, there's that gaping hole. The information may be there, but it isn't utterly obvious how to get to it.

Small opportunities are often the beginning of great enterprises. ~ Demosthenes

If there is one sure thing in the marketplace, it's that gaping holes will be filled with something by someone. Right now, it seems like that gaping hole left by Borland and Delphi is being filled by Visual Studio and Microsoft. Sure, Microsoft has a huge budget to market to these folks, but if ever in the history of free enterprise there was a time when you can go crazy and market a product with little or no cash, it's now. With the advent of the Internet and the shrinking world it creates, all bets are off. The opportunity is out there. What can Borland and the Delphi community do with it?

Blast from the Past: What to do with Kylix

By Nick at November 20, 2012 05:00
Filed Under:

Here's another Blast From the Past, this time about Kylix.  It was originally posted on December 12, 2003.

Sadly, Kylix isn't fairing in the market place as well as Borland would like. Borland never really releases sales figures, but it's pretty safe to say that Kylix hasn't generated as much revenue as Borland would like. (Of course, no product every does, I guess. Who wouldn't want more revenue from any product?) Whether it has or ever will actually pay for its cost of development isn't known. What is known, however, is that Kylix is a pretty cool idea, that it is the most feature rich development tool in the Linux world. Sadly, though, it doesn't seem to sell many copies.

Now, why it doesn't sell probably can be debated, but whether it is because the Linux world doesn't want to pay money for tools and applications, because it is “too buggy”, or because it “is a dead product”, the fact is that it doesn't sell well. But certainly one of the reasons that it doesn't sell is that the applications it builds are perceived as a bit unwieldy. Kylix applications require the Trolltech qt library to be shipped with them. An application built with Kylix actually has to go from Pascal through a layer to a C++ library in order to work. The C++ version has to go C++ to Pascal, back to C++ again. Such a long trip doesn't make for a necessarily clean, easy to build and deploy application. Far be it from me to complain or second guess the design decisions made by the Kylix development team, but this fact is a sticking point for many potential Kylix customers.

Actually, I misspoke. It is GUI applications that have to make these trips. Kylix brings Rapid Application Development to GUI applications and Linux, but Kylix can do a lot more than that. Kylix can build application servers and Apache Dynamic Shared Object (DSO) modules. It can build these without all the hassles of the qt library and the multiple layers of code. In fact, it makes building such applications quick and easy, and it build native code executables an libraries. Kylix's ability to create power server applications is very much an unheralded and under-appreciated feature of the product. And since Linux's strength lies in being a server, there seems to be a disconnect somewhere.

This disconnect is where Kylix might actually be able to reverse its trend and actually make some money. I propose that Borland take Kylix, strip out all of the qt-based GUI features, and sell it as a server building application development tool. Call it ApacheBuilder, or MiddleBuilder, or ServerBuilder, or whatever (it should be clear that you'd be foolish to hire me to name your product). Sell it as a great way to build the applications that Linux users are actually running – server applications.

Linux's major inroads in the marketplace have been as a server, whether it be a database server, a web server, a J2EE server, or any other kind of server. Linux on the desktop remains the dream of many a Linux Distribution seller and Slashdot cowboy, but for now, it is just that, a dream. Microsoft has no intention of letting Linux cut into its desktop market the way it has in the server market, so trying to sell a development tool that builds desktop applications may be a non-starter, but selling and marketing a tool that builds the kinds of applications that Linux users want and need -- now there's a way to make money.

Now I don't know the technical requirements or exactly what work would need to be done to make this happen. Perhaps it would be too much work to make it worthwhile. Perhaps it isn't even possible. But I do think that marketing a tool that has as its main emphasis the building of servers would hit a sweet spot in the Linux community. For instance, Apache is easily the most popular web server on Linux, and Kylix makes it pathetically easy to build powerful, native DSO libraries that run on Apache. How many potential Kylix customers even know or realize this? With the dbExpress database technology and the WebSnap architecture, building dynamic, database driven Apache extensions is quick, easy, and powerful. That feature of Kylix, however, was sort of drowned out by the hype of the RAD, GUI development side of things.

Bottom line: By actually reducing the feature set of Kylix, and by marketing it as a server development tool, Borland might actually be able to turn Kylix into a successful product, and a tool that Linux developers want and need.

Blast from the Past: Embrace and Extend, Borland Style

By Nick at November 19, 2012 07:41
Filed Under:

I've been wanting to find this post on an old hard drive or thumb drive, and then it occurred to me that I can dig it up on the good old Wayback Machine.  The post below was originally written on November 14, 2003, well before I went to Embarcadero. (You can read the original in all its glory, including the original comments on the Wayback Machine)  It was also written before the VS Shell program came about.  In it I wrote about what eventually would eventually come to pass in the form of Embarcadero Prism. 

In digging around on the Wayback Machine, I found quite a few interesting articles I wrote back in the day, and I'll be publishing them here over the next week or two.  It is kind of fun to read all the stuff I wrote when I was younger,  brasher, and more foolish. 

....or, Hoisting Microsoft by Their Own Petard

I've just returned from The 2003 Borland Conference where Borland spent an understandably large amount of time talking about the Microsoft .Net Framework (an precious little about Linux, I noted). Clearly we Delphi developers are standing on the edge of a pretty sharp inflection point, bending pretty radically in the direction of the .Net Framework. Microsoft is moving all of us into the world of managed code, and there doesn't seem to be much we can do about it. But the good news is I don't think we should want them to do anything about it -- .Net is a very, very cool platform, and one that I think we should embrace.

The inflection point doesn't just affect us developers. It actually affects Borland a whole lot more. They are the ones who have to make the tough choices about where to take their products and how to get there once they decide. Right now, all of their .Net plans are in the hands of the .Net Business Unit (formerly called the RAD Business Unit). These guys are responsible for Galileo, the IDE framework that is currently deployed in C#Builder, and will soon be deployed in Delphi 8 for the .Net Framework. Galileo is Borland's next generation IDE that builds on the code base of Delphi/C++Builder, but which clearly is moving into the .Net world.

We got a lot of good looks at Delphi 8 for .Net (hereafter called simply Delphi 8) at Borcon. During the opening keynote, we saw Michael Swindell build an ASP.NET web service, and then consume it with Delphi 8. He also did something many folks appreciated – he compiled an ran the original FishFact.dpr application that shipped with Delphi 1 (yes, Delphi 1 – the 16-bit version). That application compiled and ran just fine in Delphi 8.

But it is the development of Galileo is what provides Borland with it current, very difficult, challenge. As I listened to the Borland folks and talked to developers at Borcon, it became clear that while .Net provides an excellent opportunity for Borland and Delphi, it also makes things difficult for them. For perhaps the first time, Borland is playing catch-up in the IDE arena. Visual Studio.Net has been out for over a year, and the new, improved Version 2.0 is due next summer. While C#Builder offers some advantages in this market, it will almost certainly continue to chase Visual Studio.Net in features and support for future versions of the .Net Framework.

Borland, as we all are aware, has limited resources, and their main competition, Microsoft, has in effect unlimited resources. There is a small but highly skilled group of people developing the DCCIL.EXE compiler, while Microsoft has, literally, hundreds of people working on their compilers. Borland has a lean, mean team of developers working on their IDE, where Microsoft has, again, hundreds. Microsoft's marketing budget for their tools division is likely larger than Borland's yearly revenues. Borland has managed to compete in this environment by providing superior products and technology. However, even the staunchest of Borland groupies will agree that this gap has narrowed, and in some areas, the gap is created by Microsoft's lead.

I pondered all of this during my time in San Jose, and I've come up with a solution – a means for Borland to continue to leverage their technical expertise, to lower their overhead and to increase the return on their R&D dollars. It's not a solution that will seem immediately beneficial to most of you – indeed, I expect that the initial reaction of Delphi developers will be quite negative. Therefore, I ask you to hear me out, to consider what I've said, and weigh my argument before running off to the newsgroups to rant about how I've lost my marbles. I've bounced this idea off of a number of very smart people in the community, including people at Borland, and all of them have said that despite initial appearances, this is not a crazy idea.

First, some bona fides: I am a totally sold-out, completely assimilated Delphi bigot. I love Delphi. I was in on Delphi from the very beginning, I want to code in Delphi for the rest of my life, and I think that anyone who doesn't code in Delphi is crazy. I love Borland. I love using Borland products, I love going to Borland and hanging around the super-smart and super-nice people that work there. My livelihood is directly tied to the success of Delphi and Borland. I am on TeamB and spend interminable hours on the Delphi newsgroups doing what I can to help people use Delphi.

Second, I don't hate Microsoft, but I don't go out of my way to help them out. I like and use Windows almost exclusively, but pretty much don't choose Microsoft products if I don't have to. I buy Quicken, not Money, and I am typing this in OpenOffice, not Microsoft Word (though I confess I have Word on my machine. Who doesn't?). I don't like a lot of the things Microsoft does nor the way they generally do business, but I will defend to the death their right to do with their property what they want.

Thus, having said the above, I hope you believe me when I say that I propose what I do below with the purpose of trying to bring Delphi forward into .Net in the most competitive manner, and in a way that makes Delphi usable and desirable by the whole community of .Net developers and not just existing Delphi developers.

The Idea

Okay, enough said. Here it is – here's my idea that you all have been waiting for with baited breath: Borland should abandon the Galileo IDE, license the Visual Studio.Net IDE via the Visual Studio Industry Partner program, brand it as their own, and enhance it with their own plug-ins, features, and capabilities, including first class support for the Delphi language.

What do you think?

Okay, hey, stop hyperventilating and remember that you promised me that you'd hear me out.

First, let me flesh out the idea in order to be clear about what I mean. Borland would license the Visual Studio.Net framework and build their own version of Visual Studio.Net. They'd put Borland Developer Studio on the caption, they'd put in their own palette, colors, look and feel, etc. They'd add full and complete Delphi support. They'd sell their own, complete product themselves. Note that I am not talking about building a plug-in to Microsoft's Visual Studio.Net, but a full-blown, “Borlandized” version of the product, into which Borland can add their own value-added features. They could sell it for whatever price they think will maximize their profits.

As far as I can tell, this idea is feasible and well within the licensing of the VSIP Premier Program. In fact, there's every reason to believe that Microsoft actually wants and encourages Borland to make this leap, as I'll discuss below.

I think this is a really good idea and I am going to tell you why. Here are the reasons:

In order for people to choose Delphi, the IDE must be compatible

Delphi is a magnificent language, beautifully mixing ease of use, readability, power, and elegance. It's been marvelously managed by the R&D folks at Borland over the years. It's not messy and overdone – it's just right. That being said, though, I think most Delphi fanatics agree that Delphi is a hard sell. Getting organizations to buy into Delphi isn't easy, as C++, VB, and now C# are all easier to buy into, because, as we all know, “no one ever gets fired for buying Microsoft.”

(Don't you find the rapid adoption of C# rather galling? For years we Delphi people were told that Delphi wasn't used because it wasn't popular enough, that it would be too expensive to migrate code to it, etc. Well, C# wasn't popular either, and it's no cheaper to migrate to C# than it is to Delphi. But I suppose no one ever told us this all would make sense. Anyway....)

Galileo is not compatible with Visual Studio.Net. A Galileo project can't be imported as-is by Visual Studio.Net (you have to export it from Galileo first). Plug-ins for Visual Studio.Net don't plug-in to Galileo. Therefore, if a .NET development shop is using Visual Studio.Net, they have very little reason to buy either C#Builder or Delphi 8 for .NET.

However, if Borland's IDE works seamlessly with existing .NET projects, then many of the reasons not to use Delphi go away. Delphi programmers could work side by side with Visual Studio.Net-based organizations. If those organizations have a set of standard plug-ins for the IDE, Delphi developers can use them. The barriers to using Delphi become very short.

Borland can stop worrying about IDE development and start worrying about IDE enhancement

As it stands right now, Borland has to expend a lot of energy to build their own IDE. They have to play catchup with Microsoft in the area of .Net Framework support. The effort required simply to maintain and enhance the IDE infrastructure is effort that can't be spent on enhancing and adding value to the IDE.

If Borland were to leave the IDE infrastructure development to someone else (i.e. Microsoft), they could unleash their estimable R&D team onto the improvement of the IDE. They'd be free to implement all the things they've been wanting to add to the IDE, but can't because they've had to use up precious R&D resources trying to keep up with Microsoft.

To a large degree, the IDE world is becoming commoditized. Borland's PrimeTime IDE and the open source Eclipse project dominate the Java IDE world. Borland recently took the Java-based PrimeTime IDE and used it as the IDE for their new C++ offering. At this point, it would be crazy for any company to try to build a new Java-based IDE.

The same can be said on the .NET platform. Microsoft will always be a step ahead with their IDE, as they can begin working on it with the knowledge of what coming versions of .Net will do. Think of redoing a bathroom. By using the solid plumbing that Microsoft can provide, Borland can put all of their effort into decorating the bathroom instead of just getting by with cheap fixtures. If the plumbing is all complete when you start, you can afford to add beautiful wallpaper, high-quality fixtures, a jacuzzi, and plush carpeting.

With the commoditization of the IDE, the real selling points of an IDE are the unique value-added items that a company can provide, and if it is one thing Borland knows how to do, it is adding value to an IDE. Freed from all the “plumbing”, Borland could add value by making their version of the IDE a showcase for their technologies like Borland Data Providers, Together, StarTeam, CaliberRM, etc. Borland has plenty of things they could do to make their version of the IDE very attractive, and given the proper resources and time to spend on enhancing rather than building, the IDE, they could provide a very compelling .Net development platform that provides support for the whole application lifecycle management process.

The resulting Borland IDE would be totally compatible with Visual Studio.Net

If Borland were to license Visual Studio.Net, then the Borland IDE would be compatible with all the existing Visual Studio.Net plug-ins and enhancements, as well as with existing features like C# and VB.NET. Borland wouldn't have to expend any more effort in building and maintaining a ToolsAPI. They wouldn't have to make the effort to make their ToolsAPI compatible with Microsoft's – compatibility would come for free. Delphi developers would be able to work side-by-side with C# developers. One of the main arguments against buying Borland's tools – that their IDE's don't mingle well with Visual Studio.Net – would instantly be removed.

Microsoft wants them to do it

This part is all pure conjecture on my part, but I think Microsoft wants Borland to do this. First of all, why would they even allow companies to do so via the VSIP program if they didn't want them to do it? The way I read the general information about the Premier level of the program, they actually encourage companies to “license and distribute” Visual Studio.Net.

Second, Microsoft clearly wants Borland to succeed in selling .Net solutions to developers. Without Borland, they have no real competition in the market space, and they are, to say the least, very sensitive about this. By encouraging Borland to develop their own, competitive version of Visual Studio.Net, they encourage .Net development (and not Java development), keep the Department of Justice off their back, and keep everyone happy. It's a win/win situation for them, and not only do I think they'd be happy to have Borland go this route, I'd be willing to bet that they are actually pushing Borland to do it. Borland could use this fact to negotiate a licensing and price deal favorable to Borland's bottom line.

Profits, Profits, Profits

The only reason Borland will do this is if they think they will make more money.

Right now, I am asked all the time – Why should I buy C#Builder? Well, if we were all honest, it is a tough question to answer. If Borland were to do what I am proposing, however, you could honestly answer back “Whynot buy C#Builder? It's totally compatible with Visual Studio.Net, and it has a huge number of enhancements and improvements over what Microsoft supplies. In addition, you can use it to manage your entire application lifecycle, which you can't even come close to doing with Visual Studio.Net. Plus, you can use the marvelous Delphi language if you want, all in the same package.”

Come on, wouldn't you love to have a ready, compelling answer to the “Why should I buy Borland?” question? You know you would.

And of course, if the answer to the question is a good one, then people will buy Borland, and the more that people buy Borland, the more money Borland makes. The math on that is pretty easy.

Borland already sort of has this product out there

Borland already has a rather extensive set of plug-ins for Visual Studio.Net, including Together Edition for Microsoft Visual Studio .NET, as well as Visual Studio.Net plug-ins for CaliberRM and StarTeam. These products require the consumer to buy Microsoft's IDE. Why simply sell these as part of a Borland IDE, which happens to be compatible with existing IDE's already? Don't continue to give your customers a reason to buy the competition's IDE – give them a fully compatible solution that Borland sells them.

Objections

I'm not silly enough to think that you all will simply buy my argument without any objections. So, in an attempt to head you off at the pass, I'll use my years of experience in the Delphi community to list a few of the objections that I know will be forth coming, and address them.

Borland will be giving up control of their bread and butter product.

Yes, in a sense they will. Borland pioneered the concept of the IDE with Turbo Pascal. They have been the leader in IDE enhancement and integration since the beginning. Their reputation for innovation and technical excellence is unmatched, and making this move would be, in a sense, a cop-out.

But in another sense, giving up control may be inevitable; they might not even have a choice. As discussed above, the IDE market is trending towards commoditization. In the Windows/.Net world, this means that the IDE needs to be Visual Studio.Net compatible. Borland's IDE probably never would be compatible, and so it would very likely be marginalized at best. The C++ group gave up the control over their IDE as well, turning to the Java-based PrimeTime IDE, so the move is not unprecedented.

In addition, one could view Borland's bread-and-butter as IDE's, but really it's their ability to build user-friendly, productive IDE's that sells their products, and by not worrying about the guts of the IDE, they can dedicate all their efforts to making the IDE better, leaving the “grunt work,” if you will, to Microsoft. And who wouldn't like to get Microsoft to do all that kind of work for you?

It will end up making Borland's IDE to expensive because they have to pay Microsoft

First, Borland's IDE's are already more expensive. Second, not necessarily.

It totally depends on what kind of deal Borland can negotiate with Microsoft. If, as I said above, Microsoft is quite anxious to get Borland to become a high-level VSI partner, Borland might very well be able to negotiate a very favorable (read 'cheap') deal. Perhaps Borland could use the patents that they own and that Microsoft needs to leverage a good deal. It may very well be that Borland, and not Microsoft, holds the high cards in this deal.

Again, even if Borland can't negotiate a good licensing deal, they still will be creating an IDE that has way more value than Visual Studio.Net, and so a higher price can be justified. Integration with the ALM products like CaliberRM, Together, and StarTeam will alone make any higher price worth it.

Borland's version of Visual Studio.Net will have to be way, way better to get people to buy it

I understand this objection, but I don't think it really bears on the issue at hand, because this is true whether Borland uses the Galileo IDE or the Visual Studio.Net IDE. Either way, Borland has to make their IDE the better deal simply to overcome the inertia that buying Microsoft tools already has. By making themselves compatible with the Visual Studio.Net market, it actually makes it easier to make the value proposition to managers because one of the major hurdles of selling the Galileo IDE is removed.

Borland will never go for it, so why even expend the energy to make the case?

This seems like the hardest objection to get over, but I think it is less of a problem that most would think. Sure, the great, hard, time-consuming work that the R&D team has done on Galileo will pretty much be shelved, and perhaps there will be some resistance inside Borland to that for reasons of pride and because they won't want to throw away the investment.

First, the pride issue. I don't know that this is as big a problem as you might think. While I was at Borcon, I spoke about this idea with a number of Borland people in the .NET Business Unit, and they all were intrigued by it, including the IDE Developers that I talked to. None seems to upset about spending less time developing the IDE infrastructure and more time doing the actual enhancements that they've wanted to do but had to delay because schedules and limited resources held them back. Increasing IDE enhancement time and decreasing IDE nuts and bolts coding time was quite appealing.

Second, the objection that Borland might have about throwing away an investment isn't economically sound. The R&D costs invested in Galileo are sunk – i.e. They can't be recouped no matter what Borland does. The money is spent, and it isn't coming back. The only way Borland can make money is selling the software they've created, and if selling a Visual Studio.Net-based IDE will sell more copies (as I believe it will), then the most profitable route is to do so. Or look at it this way – the R&D time is gone, no matter what Borland sells. At this point, they should sell that which maximizes profits, and selling a Visual Studio.Net product, is, in my opinion, the most profitable way to go. It means more bang for the buck on future R&D expenditures, as much more R&D time can now be spent on enhancement instead of bug fixing and IDE maintenance.

Third, I think it is almost inconceivable that Borland hasn't considered this idea already. As I argued above, I believe that Microsoft has been trying to get them to do it, and if so, this wouldn't be a new idea for them. In addition, my aforementioned conversations with people from Borland gave me reason to believe that my idea wasn't a new one to them. (Let me be clear, they all remained true to whatever NDA's they have and they gave nothing away that they weren't supposed to, but they certainly didn't act like I was talking lunacy). In other words, they may already be taking the idea seriously, and if so, one can't say they'd think it a nutty idea.

Conclusion

Well, there it is – a radical idea to be sure, but one that clearly has merit. I bounced this idea off of a bunch of very smart, very well known people both inside and outside Borland, and not one of them thought my idea outlandish, and everyone outside of Borland thought is was a good idea. (The Borland people were appropriately tight-lipped on the matter, as they should be) All in all, I think it is a sound, reasonable plan that will help push forward the Delphi language, and thus Borland, into the inevitable world of the .Net Framework.

Using LeanPub’s Markdown

By Nick at November 18, 2012 05:53
Filed Under: Delphi, Software Development, TechBiz

I’ve been doing a lot of Markdown lately.  It’s a pretty interesting notion – it’s similar in concept to HTML (a mark”up” language), but Markdown is about 443 times simpler.  Jeff Atwood is a big fan (StackOverflow uses Markdown for formatting questions and answers…) and called out Markdown’s creator, John Gruber, to be a better “parent” to Markdown back in 2009.  Recently, he has called for a standardization of the language, asking Gruber to take the lead in doing so.

Apparently, however, John Gruber, creator of Markdown, wasn’t as, ahem, “supportive” as he could have been.  At first, Jeff didn’t at first get response, but apparently then he did.  But apparently Gruber wasn’t exactly into it, or even that respectful about Jeff’s reasonable request.  I guess he’ll “think about it”.  Gruber clearly is more from Philadelphia than most people from Philadelphia, I guess.  Jeff points out that Gruber created something pretty cool, but then hasn’t exactly been the most benevolent of fathers.  And he’s not asking for anything other than a blessing on what they are doing, really.  Gruber could clearly be a bit cooler about it than he is being.

Markdown is one of those things that can easily become bastardized.  It’s specific purpose is to be human-readable and human-writable.  However, the temptation is quite great to start adding to it, making it not both of those things.  Hence Atwood’s appeal.  I hope Jeff makes something happen in this area, with or without Gruber’s support.

Anyhoo.  I’ve been using Markdown because that is what LeanPub™ uses it to create books.  As I said above, one of the main ideas of Markdown is that it should be both easy to type and easy to read un-rendered.  But that doesn’t mean that we geeks don’t want a tool to create it.   Winking smile.  The most popular editor for Windows appears to be MarkdownPad, which is a nice tool.  There is an early version of a WYSIWYG editor for Markdown called Texts – it looks promising but has a ways to go.  Some folks appear to be using Emacs (yuck!) or other editors only available on the Mac. 

However, LeanPub™ appears to be doing what Atwood is worried about – extending it just a little bit beyond what the standard is.  That’s fine -- they’ve added Tables, and different code tags using Pygment – all of which are not supported by the “normal” editors.  For instance, I’m writing a technical book with lots of code samples, and tools like MarkdownPad can only be so helpful.  As  much as Markdown is meant to be human-writable, it’s a bother to add in manually the tags for Delphi code blocks, for instance.

So pursuant to that, and because I want to make writing my book as easy as possible, I’ve built a Markdown Editor -- I'm calling it LeanTed --  that is designed specifically for LeanPub™ authors.   It implements the LeanPub™ Markdown standard, supports code tagging, and other Markdown stuff that is used by LeanPub™.

It is written in Delphi XE3, as you would expect of me.  The main editor window is a TSynMemo, and it uses the Ribbon controls that ship with Delphi. 

You can get it here.  Please be warned – this is currently a very early version and not fully featured.  I’m using it myself to write my book, but I understand all the quirks.  I’ll be refining it as I use it more, of course. 

Features that I already have on the list to be added include:

  • Implementing LeanPub’s Table support  and CrossLinking -- (The current Table stuff doesn't do anything other than display what would be added....)
  • Associate it with *.md files
  • Notice when the file has changed elsewhere
  • Timed Autosave
  • Synchronize the text and preview modes (anyone have any idea how to control the scrolling on a TWebBrowser control....?)
  • A lot of little details that I’m keeping track of in my TODO list…
  • Anything anyone thinks of that would be a good feature.

I’m releasing it as Freeware, but please feel free to donate to me for the software.  $15 would be niceSmile

In any event, please let me know what you think in the comments, and please remember that this is totally alpha-level software and that you use it entirely at your own risk.  I will, of course, be updating and improving it, incorporating feedback and suggestions. 

Measuring Developer Productivity

By Nick at November 11, 2012 03:19
Filed Under: Delphi, Leadership, Software Development

Introduction

If you go to Google and search for "measuring software developer productivity" you will find a whole lot of nothing. Seriously -- nothing.

Well, okay, not exactly nothing. You'll get a ton of links. But almost all of the links you find will talk about how measuring the productivity of software developers can't be done effectively. Some people will even argue that it shouldn't be attempted at all. Some others will describe techniques to measure developer productivity, that, well, everyone else knows don't really work.

There have been many valiant attempts to measure developer productivity, but all seem to end in less than successful territory. (We all know to laugh at "Lines of Code" as a productivity measure). Virtually any objective measurement you can apply to the software development process can be "gamed" into submission.

There are just too many variables to account for everything that goes into the development process. Measuring any one of them, or even a combination of them, simply cannot begin to capture effectively everything that is involved. You can't pick a surrogate thing to measure, but because of human nature, developers will react in ways that will skew the measurement.

Many studies have been done on this topic, with little to show for it. Every software development manager who has to fill out a developer's evaluation or determine who gets bonuses has struggled with this. Many a leading expert and guru has thought about and researched this thorny topic.

Experts Agree

And not one of the experts has come up with a good idea or method to measure individual productivity. There are plenty of good and effective ideas on measuring team and project productivity, but there is a severe if not complete shortage of ways to measure individual performance and productivity.

For instance, Robert D. Austin wrote an entire book on this subject called Measuring and Managing Performance in Organizations and came to the conclusion that unless you can measure 100% of something -- that is, every aspect of it -- then there is no point in measuring at all. If you attempt to measure less than 100% of the things involved in a given activity, you will get what he refers to as "dysfunction", or what you and I might call gaming the system. And since software development is an incredibly complex and creative endeavor, it's virtually impossible to measure every aspect of it. Often it quite literally involves sitting and staring at a computer screen. How do you measure the productivity of that?

Here's Martin Fowler's conclusion in an article he entitles " CannotMeasureProductivity":

"This is somewhere I think we have to admit to our ignorance."

Neil McAllister of InfoWorld writes in an article entitled " The futility of developer productivity metrics"

"For most other companies, however, it might be best simply to forget about the idea of measuring developer productivity and rely instead on tried and true methods. That's right: A highly effective, productive developer workforce is often the result of high-quality, effective management. Unfortunately, nobody has developed a metric for that yet. Coincidence?"

Joel Spolsky writes:

"It's rather hard to measure programmer productivity; almost any metric you can come up with (lines of debugged code, function points, number of command-line arguments) is trivial to game, and it's very hard to get concrete data on large projects because it's very rare for two programmers to be told to do the same thing."

Steve McConnell, a widely regarded academic, author, and consultant says:

"So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects."

Like I said, it's hard to find a leading expert making the case for objective measurements, and easy to find plenty that say you shouldn't even try.

So I don't think that it's a tough leap to agree that there is no objective way to measure productivity in software developers. I know this is controversial, but it seems quite clear to me that software is more art than science, and measuring productivity in art is, well, simply not done. One does not tell Michelangelo that it took him too long to paint the Sistine Chapel because he should have been painting 1.4 square feet per day instead of 1.2. That would be preposterous.

So, What Are We to Do?

Anyone who is charged with managing and leading developers is left in a quandary. We want to be fair, but if everything is subjective, how can we be?

The fact that there is no objective measure of developer productivity doesn't mean you can't measure it. It just means that you have to measure it subjectively . And we do that, don't we. You can look around your shop and just know who the productive developers are. There are probably developers you know that simply crank out good code faster and fix bugs more efficiently than the rest. For ease of discussion, I'll give this developer the name "Jason".

And just how do you know Jason is more productive and more valuable? You just do. You can just tell. You know it when you see it. But if you stop and think about it, Jason has some characteristics that you can figure out and write down.

What I mean is that if you stop and examine Jason and his work, there are things that you can say about him that describe what he is all about. They are subjective, sure, but you can write them down and give an "objective" measure to these subjective things.

A Modest Proposal

So yeah, what I am proposing is a way to measure developer productivity and value via a subjective set of measurements. Think of it as a way to qualify the notion of "you just know that Jason is productive".

Here is the list:

  • Productivity
    • Does the developer get a reasonable amount of work done in a given period of time?
    • Is the developer's velocity on bug fixing sufficient?
  • Engagement
    • Is the developer dedicated to his/her craft?
    • Is the developer committed to delivering software on time?
    • Is the developer dedicated to company success?
  • Attention to Quality
    • To what degree does the developer's code work as designed?
    • Does the developer thoroughly test code and believe it to be correct before checking it in?
    • Do a minimal number of bugs get reported against his/her code?
    • Does the developer write unit tests for all new code?
    • Does the developer follow the Boy Scout Rule and leave a module cleaner than it was before he or she worked on it?
  • Code Base Knowledge and Management
    • To what degree does the developer understand the code base assigned to him/her?
    • Does the developer take responsibility for his/her team's code base, improving it at every opportunity?
  • Adherence to coding guidelines and techniques
    • Does developer's code routinely meet coding standards?
    • Do code reviews reveal a minimum of problems and discrepancies?
    • Does the developer use Dependency Injection to ensure decoupled code?
  • Learning and Skills
    • Is the developer constantly learning and improving his/her skills?
    • Does the developer show a passion for the craft of software development?
  • Personal Responsibility
    • Does the developer first assume that the error lies within his or her code?
    • Does the developer understand that he or she is solely responsible for their code working correctly?
    • Does the developer take pride in their code, ensuring it is clean, tested, easy to read, and easy to maintain?

Again, these seven items are all subjective measurements. All the questions require the evaluator to make subjective judgments. But a good lead/manager is presumably in their position because of their good judgment about such things, and so they should be able to make fair and accurate assessments about Jason's productivity using these "measurements".

Most of the questions ask for a yes or no answer, but all can spark a discussion with management or even the developer being evaluated. You could use these measures on a formal evaluation form. Whatever you do with them, it's probably better than the "just know it when I see it" approach you are probably taking now.

Conclusion

In the end, any evaluation, judgement, or other assessment of the productivity or value of a single developer will be subjective. No one has yet found an objective way to measure individual productivity in our excessively complex profession. But I am saying that it is possible to qualify and make judgments about a specific set of criteria as a small and humble step towards being able to do the thing that our industry has so far found very difficult.

My suggestion is that we accept reality and embrace the subjectivity -- and lack of objectivity -- in measuring developer performance.

How Not to Code #3: Compound ‘with’ Statements

By Nick at November 03, 2012 04:24
Filed Under: Delphi, How Not To Code, Software Development

Seriously, think about this:

  with (Sender as tStringGrid), Canvas do

I’m doing some string grid work, and ran across this code out on the web.  Wow.  It does what I want, but really?  It was code on a page with a date of like 1998, so at least we could say it was before many Delphi developers knew better. But still….. that is just awful. 

Here’s the truly hideous part – if I comment the line out,  the code still compiles!  Yikes!

My Book

A Pithy Quote for You

"No matter how rich you become, how famous or powerful, when you die the size of your funeral will still pretty much depend on the weather."    –  Michael Pritchard

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.