Widgets Nick Hodges | A man's got to know his limitations

Blast from the Past: What to do with Kylix

By Nick at November 20, 2012 14: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 16: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.


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.


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 14: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 12:19
Filed Under: Delphi, Leadership, Software Development


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.


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 13: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!

Fun Code of the Week #6: Primality Checking

By Nick at October 27, 2012 18:02
Filed Under: Delphi, Fun Code


I decided to give KhanAcademy a spin, and watched this set of videos:

Level 1: Primality Test

And that let to me writing this code:

function IsPrime(const x: integer): Boolean;
  i: integer;
  i := 2;
    if X mod i = 0 then
      Result := False;
  until i > Sqrt(x);
  Result := True;

I know that this can be optimized (which I'll do if I end up watching the next video :-) ), but I don't often write really geeky code like this, so I thought I'd post it so you all can write lots of comments like you always do when I post code. ;-)

UPDATE #1: There was a bug if you passed in a negative number. 

function IsPrime(const x: integer): Boolean;
  i: integer;
  if (x <= 2) then
    Result := False;
  i := 3;
    if X mod i = 0 then
      Result := False;
  until i > Sqrt(x);
  Result := True;

UPDATE #2:  Took the Sqrt() call out of the loop.

function IsPrime(const x: integer): Boolean;
  i: integer;
  Wall: double;
  if (x <= 2) then
    Result := False;
  i := 3;
  Wall := Sqrt(x);
    if X mod i = 0 then
      Result := False;
  until i > Wall;
  Result := True;

UPDATE #3:   The learning and optimizing continues!  I updated the code based on more suggestions, but the special case of 2 is irritating me.  I confess I thought a while (I’m not cheating by looking up implementations on Google…) and so I came up with something of a hack.  Also, just for Julian, all the x’s are lowercase now.  Smile with tongue out  Also, I learned/re-learned that 1 is not a prime either, by definition.  Interesting.  Any more optimizations out there?  Is there a “correct” way to handle 2?  The end goal here is to have a really nice, really efficient IsPrime function. 

function IsPrime(const x: integer): Boolean;
  i: integer;
  Wall: integer;
  if x = 2 then
    Result := True;
  i := 3;
  Result := not ((x < i) or (x mod 2 = 0));
  if not Result then Exit;
  Wall := Trunc(Sqrt(x));
    Result := not (X mod i = 0);
    if not Result then Exit;
    Inc(i, 2);
  until i > Wall;
  Result := True;

Flotsam and Jetsam #68

By Nick at October 27, 2012 13:16
Filed Under: Flotsam and Jetsam, Delphi
  • Is it me, or does it seem like there are more Delphi conferences happening in Europe than there has been in the past?
  • I totally get the notion of being on hold to wait for customer service.  I usually put the call on speaker phone and wait that way.  They usually play music and go about my business.  What bugs me, though, is when they break in every ten seconds to say “All our representatives are currently assisting other customers.  Please continue to hold.”  That’s all well and good, but every time they do it, I have to sort of stop what I’m doing and see if it is recording or the real person coming on.  Irritating.
  • Apparently, my man Frank Borland has a blog
  • I was happy to find this interesting, insightful, and marvelously written answer by Danny Thorpe to the question “Why did Borland fail?”.
  • I’m feeling a bit out of it, as I just discovered and joined Quora – and gave my first answer.  I’d never really heard of it before, but found out that many of you folks are already there using it.  Now to think of a question to ask…..
  • I made a few more changes to the website – easily enabled by Less.  I put slightly rounded corners on the little side boxes, as well as a bit of a shadow.  Both are easily adjustable thanks to Less. 
  • I also added a new advertiser – Lake Quincy Media.  They specialize in Developer Tools, so hopefully what you see should be more of interest.

Fun Code of the Week #5

By Nick at October 24, 2012 21:39
Filed Under: Delphi, Fun Code

What is your FizzBuzz solution?  Any comments on mine?

If this is an interview question, what are you looking for?

Here is FizzBuzz in over 150 languages.

For the record, I spent no more than three minutes to write this. :-)

program FizzBuzz;


{$R *.res}


  i: integer;
  WriteNumber: Boolean;

    for i := 1 to 100 do
      WriteNumber := True;
      if i mod 3 = 0  then
        WriteNumber := False;
      if i mod 5 = 0 then
        WriteNumber := False;
      if WriteNumber then
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);

Less is More for your CSS

By Nick at October 24, 2012 19:34
Filed Under: Delphi, Software Development, Tech Stuff

As you may have noticed, I made a few changes to the website here at good ol’  I added a column of boxes on the left, with the idea being to make stuff more accessible without so much scrolling.  And, well, yeah, okay, I’ve used that space to add a few more advertisements.

And while I was at it, I cleaned up a few things with the layout and the CSS.  It’s what I did with the CSS that I’d like to talk about today.

The main thing that I did was to start using the CSS pre-processor called Less.  Less allows you to do a lot of things “right” when writing CSS.  The first thing you notice when you start writing CSS is that it is a horrible violator of the DRY principle – Don’t Repeat Yourself – and Less solves a bunch of those problems.  It’s hard to write “clean CSS code”.  Less can help.  Less allows you to:

  • Create a *.less file that is then processed into your CSS file.  You can do this manually with a command line preprocessor, or you can do it on the client-side with Javascript.  Below, I’ll discuss how I pre-processed my *.less file automatically
  • Declare variables for colors and other things.  Say you have a color that you use in a number of different places.  You can declare

         @WidgetBorderColor: green;

    and then everywhere you had to type green, you could put @WidgetBorderColor instead.  Then, if you want to change from green to red, you only have to do it in one place.  That is really nice. 
  • You can also declare mixins – or chunks of CSS code that are commonly used.  For instance, if you have a bunch of places that use  

         {padding: 0px; margin: 0px}

    then you can declare

         .p0m0 {padding: 0px; margin: 0px}

    and use that as an “alias” in your *.less files

       body {
        font-family: Verdana;
        font-size: 13px;
        color: @Black;
        background: @White ;

  • You can also use parameters to pass in to your mixins if you want, an other more complex constructs, though none of it is terribly difficult.   The Less page has all the documentation in one place.  The two features above were what I used in an effort not to repeat myself in my CSS.

Once you have your less file set up, you can process it via the command line, or using a GUI compiler tool.  Because Less is written in Javascript, you can use node.js to run it on your local machine.  To do that, you can download the Node Package Manager and then install  Less by simply executing

npm install less

npm is kind of interesting – it’s an online registry, so when you issue the above command, it goes out to a public registry and finds the Less package and simply installs it – there’s nothing for you to install. I guess it is much like Nuget in that regard. 

After that, you can then execute the lessc compiler. 

So the workflow at this point is:

    1. Write CSS and Less code in a *.less file
    2. Compile the *.less file into a *.css file.  (For instance, I use a batch file with:  c:\Code\node_modules\.bin\lessc C:\NickHodges\themes\nick\style.less c:\NickHodges\themes\nick\style.css
    3. Deploy the new CSS file with my site
    4. Repeat as necessary

Step 2 is kind of a bother, though.  You have to shell out to the command line to do the compile.  Who wants to do that if you don’t have to?

Well, I sure don’t.  So I found a cool tool called WinLess which does a nice thing – it automatically compiles your Less code into CSS every time you save your *.less file.


It works great – you just point it to your *.less files, and whenever you save changes, it automatically compiles the Less code down to CSS.  That way, your CSS is always up to date, and you just have to worry about your Less code.  Maintaining the CSS file is totally painless.  So now the workflow is:

  1. Update your *.less file as desired
  2. Save
  3. Deploy your *.css file.

That’s a lot easier, eh?

Now what I really want is a tool to find patterns in your CSS and automatically turn them into Less entries.  That would rock.

CSS is powerful and cool, and you can’t create a well-designed website without it.  But as a language, it’s not really very “best coding practices friendly”.  Less makes it much more so.  If you set things up correctly, you can do your styling in Less and forget about CSS altogether.

What do you guys do with your CSS?

Flotsam and Jetsam #67

By Nick at October 20, 2012 09:12
Filed Under: Flotsam and Jetsam, Delphi, Software Development
  • For those of you who still cling to the archaic notion that “Delphi Marketing Sucks”, you should know that I can’t go anywhere on the internet without seeing an add for RAD Studio XE3.  One of the things I appreciate about Google Adsense is that it knows the kinds of ads I want to see and what I am interested.  And it has very astutely determined that I like Delphi.  And Embarcadero marketing has very astutely provided ads to let me know that RAD Studio XE3 exists and that I can buy it.   That’s what marketing is all about.
  • How have I managed to miss this page of cool stuff all these years --  Delphi Inspiration? I’m particularly intrigued by the Delphi pre-processor.
  • Cool Thing Built With Delphi of the Week: dbConstructor
  • A bunch of you have ordered Delphi XE3 from me. I am very grateful. Thanks.  It's a great release -- I'm really enjoying using all the cool new language and RTL features, and I think you should too.

My Take on TypeScript

By Nick at October 17, 2012 21:43
Filed Under: Delphi, Tech Stuff, Software Development

Microsoft has been keeping the renowned Anders Hjelsberg busy on a new language called TypeScript.  Typescript is an open-source project (using the Apache 2.0 license) that allows you to write a super-set of Javascript that allows for a stronger typing system.  You can watch Anders’ original launch presentation

I’ve said a million times that I’ve said a million times that Javascript is the new Assembler – that Javascript will become the thing that everyone compiles higher level code into.  You’ll write your web apps in a higher order language, and then compile them to Javascript for execution in the browser. 

I refuse to believe that any rational person actually likes to write Javascript, and as it is designed currently, it really isn’t a language for developing the kind of large-scale applications that people seem to be wanting to use it for.  In the deep, dark past, Assembler used to be all there was, and we created higher order solutions that compiled to assembler.  And in the same way, for a while, Javascript was all there is for the browser.  Now, however, we are beginning to see higher order languages being brought to bear to produce Javascript for us. 

If Javascript is the “new Assembler”, then the Browser becomes the “new operating system”.  The cool thing about that is that the “new OS” is ubiquitous.  Just about every computer in the world – computers running Windows, OS X, Linux, Unix, whatever – has a browser that runs Javascript.  That means your application can run on any computer.  That’s a very compelling idea.

You can actually do that today with Delphi using a very cool tool called Smart Mobile Studio.  There is also the Elevate Web Builder tool from Elevate Software.  Both have the same idea – leverage the power of Delphi to produce Javascript-based applications.  Pretty cool, really.

Anders talked to Scott Hanselman about Microsoft’s offering in the “Language to compile down to Javascript” arena in the latest episode of Hanselminutes.  Anders is always a good interview – I love a guy who thinks and speaks as clearly as he does.  (That’s why I always loved a Danny Thorpe presentation.  Danny is pretty quiet and mellow, but his talks were always so clear and well organized – every single word he said was worth listening to – that they were always excellent and enormously educational.  Anders is the same way….) He does a great job discussing the notion behind TypeScript.

Here are some of my thoughts on what Anders said and on TypeScript in general.

  • TypeScript seems to exist for two reasons – to make Javascript “tool-able” and scalable. 
    • First, the type annotations, classes, modules, and other enhancements exist to allow Visual Studio and other IDEs to do things like Code Completion (the RAD Studio term that Anders used in the podcast instead of Intellisense – I loved that.  Smile  ), refactoring, and other language-based features that modern IDE’s do.  Javascript doesn’t provide enough information to let development tools do all the things that we expect, but TypeScript does. 
    • Second, TypeScript is also a way to make Javascript scale. By providing the notion of typed classes and modules, you can create larger, well-organized TypeScript applications which then compile to Javascript.   TypeScript is a language ready to do the heavy lifting that Javascript cannot.
  • Since TypeScript is a super-set of Javascript, it follows that pure Javascript is valid TypeScript.  Anders points out that you can use your existing Javascript as is inside of TypeScript.  The idea, though, is that TypeScript becomes the language you’d use instead of Javascript because of all the tooling support, and because it can be used to build applications via modules (units, for you Delphi folks).    Typescript doesn’t have any runtime or virtual machine – it literally just compiles to Javascript. 
  • You can create an external declaration file to define the types in your *.js file, so that means that existing Javascript libraries like Node.js and jQuery.js can be “typed” and thus used in the TypeScript environment.  I think that is a pretty cool idea – and I’m sure that Microsoft will be delighted if the community follows their lead and “converts” the existing popular libraries.
  • Anders also points out that TypeScript puts a “dial” on the typing level of your code.  Pure Dynamic advocates can leave everything untyped, and the strong-typing zealots can type everything if they want, and the folks who want to type some things and not type others can do that if they want.  That’s a very interesting notion – a language with a variable level of type-safety.

Now one thing to note is that tools like Smart Mobile Studio and Elevate Web Builder offer pretty much all these features as well.  There isn’t any reason that Embarcadero couldn’t make Javascript be something that is output by the Delphi compiler.  Heck, there is even a project out there to get LLVM to produce Javascript.  TypeScript would integrate well into HTML5 Builder. Whatever higher-end language you want to use, it seems pretty clear to me that Javascript will be the thing our compilers will be producing in the not-to-distant future.

Are you going to give TypeScript a look, or are you more interested in the Delphi-to-Javascript solutions?  I’ll probably check out both.  Either way I have to use a different IDE, so I’m guessing I’ll lean towards the Delphi-based solutions.  Plus, I frickin’ hate curly braces.  Winking smile

What do you guys think?

Frank is Back

By Nick at October 12, 2012 18:43
Filed Under: Delphi

This is posted without comment, because I really don’t know what to think or say.

Flotsam and Jetsam #66

By Nick at October 12, 2012 08:42
Filed Under: Flotsam and Jetsam
  • I’ve talked about my Ooma.  I love it – I has cut my phone bill from $50 a month to $5 a month.  It works great, and I get unlimited calling in the US, and $0.01 a minute to Canada.  (That’s important to me, as my wife is from Saskatoon and calls her family there.) In fact, the phone bill is $0, and the $5 is just taxes.  It is paying for itself in four months.  And right now, you can save $40 on the unit, meaning it will pay for itself even faster.  And if you buy from this link, I get a commission.  It’s a win for everyone. 
  • Blog Sightings:   There’s been a bunch of activity on the Embarcadero Blog site:
  • The Embarcadero MVP program is “official” now in that there is a web page and everything.  I’m honored to be included among the list of amazing, skilled, and knowledgeable folks.  Know someone who should be on the list?  You can nominate them
  • One of the cool new features in Delphi Xe3 is helpers for intrinsic types.  The most noticeable one is TStringHelper which lets you do things like MyStringVar.Length and MyStringVar.ToUpper.  However, I find it curious that they didn’t include a “standard” helper for integers.  I supposed it is because there are so many different integer types, but I seems that they could solve that through some form of inheritance, right?  I don’t know.  I just know that I’d like to be able to go MyIntegerVar.ToStringSmile
  • Here’s a blog post after my own heart: Why you should use Delphi’s Unit Testing – DUNIT.  In fact, there is a bunch of great stuff on the India Delphi User Group blog
  • Is it just me, or is it weird that Send To|Clipboard as Name isn’t a default behavior for a file in Windows Explorer?  I must use that twenty times a day.  I have to add a plug-in to have that feature. 

Flotsam and Jetsam #65

By Nick at September 25, 2012 19:14
Filed Under: Flotsam and Jetsam, Delphi
  • Hey, here is something cool.  I am now an Embarcadero Affiliate.  This means that you can buy Delphi XE3 from me.     You can click on that link or any of the banner ads right now, buy, and get a great version of Delphi.  I’d really appreciate it. Definitely.  Go on, you know you want to.  Winking smile
  • The Call for Papers for CodeRage 7 is out.  I will definitely be submitting some presentations.  This year they are actually having two CodeRages, one for Delphi and one for C++Builder.  If you have never done so, but have always wanted to be a speaker, I’d suggest that you submit some presentations.  It’s really cool being a presenter at these events.  I’ve always enjoyed it.
  • One of the unsung heroes of the Delphi community is Uwe Schuster.  Uwe does a lot of things that benefit us all.  Most prominently, he basically wrote and continues to update the Version Insight feature in the IDE.  If you are storing your Delphi code using Subversion, Mercurial,  Git, or Jedi VCSm then you should be using the IDE integration that Uwe has provided.  It’s actually quite amazing.  The Live Blame feature alone is worth it.  But that isn’t all – Uwe has a bunch of really good IDE plugins, including a nice TStringList visualizer, an expert that enhances the Object Inspector, and for those of you who hate the new modeless search feature, a modal search dialog.  So here’s an official F&J ShoutOut to Uwe for all the cool stuff he does.
  • The Jedi VCL Library is now ready for XE3.  I for one am very appreciative of all the great work the Jedi team does for the community.
  • I don’t know if many of you know Joe Hendricks. He’s been a Delphi community member for a long time.  Both he and his wife Heidi have been battling cancer for many years, and his Facebook posts about their progress, adventures, and life were an inspiration to me and many.  Their faith in Jesus was evident throughout everything they did.  Heidi passed away early this week.  I’m saddened at the loss of a woman I never met, but who was in inspiration to me.  And I send my condolences to Joe, who was a fine example of what it means to be a man, a husband, and a Christian.

Stuff I’ve Been Reading #1

By Nick at September 08, 2012 16:33
Filed Under: Software Development, Unit Testing, General, Book Review, Stuff I've Been Reading

My Book

A Pithy Quote for You

"Just the knowledge that a good book is awaiting one at the end of a long day makes that day happier."    –  Kathleen Norris

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.

Month List