
Distrusting Borland/DTG Oct 23, 2006 10:47
I find it hard to trust Borland/DTG at the moment. The hard part is because when I look back at their history it's full of contradiction and failing to deliver. I'm really heartbroken because I love Delphi and still think it's the finest Win32 development tool out there.
I do recognize that Borland/DTG has been doing better in recent months. The launch of their Turbo line and the more frequent hotfixes to BDS2006 are all very good signs indeed. The more frequent newsgroup posts, the more interest in engaging the community.
But the point of this blog entry is to examine why I still distrust Borland/DTG and why it's going to take more than words to mend this distrust.
There are three business level issues that come to mind that hurt Borland/DTG's credibility. The first is Inprise, and while that happened quite a long time ago it still brings forth feelings of mistrust simply because they decided that their focus was going to be on the Enterprise. They split "borland.com" into a separate division from the "Inprise" one that was to be focused on the "Enterprise". Towards the end of the Inprise debacle there were newsgroup posts like this. (It's also kind of cool that the Infoworld link actually still works).
Although it is different, it's eerily familiar to what's happening today. Which brings us to the second issue: Borland ALM/SDO and DTG. The situation of having two separate divisions within one company with different areas of focus exist today. Borland has decided to become an ALM company focused on the "Enterprise"; this is pretty much Inprise version 2.0.
The reason why I feel distrustful is because in both cases there is a period of a few months, perhaps years when all perceived resources are being spent towards these "Enterprise" things. Meanwhile employees and "fan-boys" of Borland/Inprise on the development side of the house try to speak of the strategic importance that binds developer tools to these "Enterprise" products and explain away poor quality products.
The reality is that Delphi 4 like Delphi 2005 was a bad release. The reality is that Corba/Middleware like ALM don't offer much leverageable synergy with Development tools.
Which brings us to the third issue: the divestiture. For the record, I do believe that things will be better and DTG will indeed be spun off; but the problem is in the way it was handled. There have been public statements saying that the divestiture would occur by the end of the 3rd quarter. Well, it hasn't happened. It doesn't really matter who is to blame or if DTG is frustrated, because at the end of the day it hasn't happened.
It might have been better to not say they were being spun off at all and dealt with explaining the Segue acqusition to the blood thirsty non-techians. After all, for the past few years, it's all been about ALM, and we could have endured a little more of the same stuff. This is all irrelevant really, since what's done is done. The main point here is that trust is hurt when actions and talk don't match. That's the definition of integrity: walk the talk.
Although Borland/DTG claim to know what they are doing, they repeatedly demonstrated having trouble doing three essential things: 1) analyze the market for a given product; 2) formulate a good strategy to capitalize in that market; and 3) execute well on that strategy. The formula for a successful product is simple:
There are two significant dropped products that hurt my ability to trust that Borland/DTG can deliver new products and more importantly remain committed enough to make them work. The first of which is Kylix. Borland's market analysis apparently showed that there was a market for Linux support. This part I actually agree with and still believe, but there were some problems with the analysis.
At the time, Linux was all the rage and there were many analysts makeing noise about Linux replacing Windows on the client. This obviously didn't happen to the degree of the hype (understatement), but I assume Borland's analysis at the time thought what the analysts thought: Linux on the client was going to be big. That was the "conventional wisdom" at the time.
This analysis gave way to the strategy of what I call "porting Delphi". This kind of makes sense, one of Delphi's core strengths, if not its primary market strength, is building great GUI's in a client/server environment. Clearly the strategy of porting Delphi to Linux didn't work.
I think it's important to recognize that Linux's strength has always been and continues to be server-side development and non-GUI remote administration. The strategy, and certainly the marketing message was not to push Kylix's server side abilities. I think the lesson here is that the tool must play to the platform's strength, not the strength of the tool on other platforms. This is why I don't think a cross-platform porting strategy will work for anything but C++.
But beyond that, the execution was fraught with problems that have been detailed in more depth and with more expertise than I have with the product. The core complaints as far as I know (which isn't a lot) were the IDE had limited support for Linux distributions (including slow response to kernel updates), and applications initially had some undesireable X-Windows dependencies; the initial price point didn't help either. And then there was the community project which never seemed to materialize.
It's quite unfortunate, because I think Kylix is a product released ahead of its time (virtualization would have helped adoption) and it was not focused on the right market: server-side development.
The second dropped product was CBuilderX (no not C++Builder), but the larger issue revolves around Borland's C++ product development. In the days of client/server based applications with thick gui clients, C++Builder made sense. It certainly offered something significantly better than MFC. Leveraging Delphi's VCL for GUI development is clever and useful, but the problem is that it only appeals to a particular niche of the overall C++ market.
I spent a few years as a professional C++ developer at an ISV working on developing cross platform servers. This and the embedded/mobile market seem to be a large part of the C++ market. Certainly there were many C++ guys in corporate IT as well, but those guys focused on non-GUI stuff as well. But here is a very critical point: the C++ culture is different from the Delphi culture.
The C++ guys I know all *loved* the language. Standards compliance were very important to them. The STL was as well. The language was much more important than how they built GUI's. Many of them were accepting of using MFC for their GUI stuff, others used Tcl/Tk widgets and called out to the command line. It's just the way they were, the language itself was much more important than anything else. They also preferred minimalist tools or "IDEs that stayed out of their way". I have great respect for the C++ culture and I relate to parts of its programming aesthetic.
So back to CBuilderX. I believe it was the right kind of product to target this broader market: they got the Analysis and part of the Strategy right. Messing around with make files and supporting multiple compilers with C++ was a pain. Debugging across platforms was also a pain. Most of us used Visual C++'s debugger on Windows, but debugging on Solaris was much more difficult. CBuilderX was compiler and platform agnostic; debugging alone on multiple platforms was a huge advantage. There was a market there, and I believe there is still a market there.
The part of the Strategy that they got wrong was the choice of wxWidgets. This was a luke warm mature widget set and didn't really excite the C++ crowd. FMPOV, the "right" GUI framework to support was Mozilla. And Mozilla goes beyond the GUI, but offers a component model, runtime, etc.
So now we get to the execution. Initially, I thought building it on top of Primetime was questionable since I was skeptical about the IDE's performance, but when I tried it, it was actually acceptable. All in all, Borland did a good job with their Primetime core.
But there were real problems with their execution: 1) No Code Insight/Intellisense 2) wxWidgets never materialized anyway. The product was released without Code Insight! For a modern IDE, this is just inexcusable. Then the product was quickly dropped without wxWidgets support (at least publically, I heard rumblings that a version 2 was offered privately to customers, not sure if it contained wxWidgets support though). Essentially, they gave up way too soon and released a half-baked product.
What I would like to see from a C++ perspective is a two pronged approach: continue working on C++Builder, but resurect CBuilderX and give it a chance. I'd leverage Eclipse and support Mozilla. I think there is a real market for a cross platform tool that compiles Mozilla apps out of the box.
Granted, in hindsight it's always easier to be critical and there are bound to be failed products from any company. The problem is they tend to get part of the equation right and screw up on the other parts. In both these cases they totally screwed up the execution portions, and the strategy was far from effective.
Delphi is a great product. It quite literally saved Borland and kept them relevant as the Windows world emerged. Turbo Pascal was reinvented for the Windows world. Instead of reinventing Delphi for .NET, Borland has tried to pursue .NET by adapting Delphi to .NET. Although Delphi maintained a great deal of backward code compatibility with Turbo Pascal, Delphi represented a dramatic shift in development philosophy as it supported Windows.
I believe that .NET represents a similar shift in development philosophy. It's more than Delphi/VCL TNG. The shift to running applications in VM, utilizing a garbage collector, language neutral development, etc. is a completely different and new philosophical approach. It's main competitive target is Java and like Java, .NET's sweet spot is on building internet server applications. I do believe that MS will do a better job at supporting the client than Java, but I digress. Unfortunately, I believe Borland viewed .NET as nothing more than another Windows technology, and shoehorned Delphi in to support it.
I will have more to say on just how I believe Delphi's current .NET strategy is fundamentally flawed another time, but let's just say I think it's all wrong. There are execution issues as well. Perhaps the only thing they got right is the analysis that says .NET is critical to windows development. It is critical, and I firmly believe Delphi needs a .NET story of some kind, I just don't think it should be the headliner within DevCo's portfolio going forward. Based on the current product offerings in DevCo's portfolio, I think ECO should be.
The proof is in the pudding. Borland has released 4 versions of BDS with .NET support. Delphi 8 and C# Builder were completely .NET releases, offering nothing for the native side (beyond bundling). The remaining two (BDS 2005 and BDS 2006) were mostly driven by .NET and language personality integration work.
From an integration perspective BDS 2005 was the release that Delphi 8 should have been. I remember looking forward to Octane in anticipation that it would have both the Win32 and .NET Delphi personalities in one IDE. It took Borland another release to bring that to fruition. BDS 2005 put in a lot of new features, but many of them had already been implemented in JBuilder and VS.NET. This also came with a price: poor quality, which I talk about in the next section.
In my opinion, a large portion of Delphi's R&D efforts have been focused on making it a first class .NET product. The problem is that despite all their efforts they have fallen short of VS.NET. I personally believe most developers that use Delphi use it for Win32 work. I believe the turbo distribution download numbers back this up. I think the adoption rates of Delphi for .NET development, even among existing Delphi developers, have been less than impressive. I believe it's been a dissapointment for Borland and will only get worse.
The bottom line here is that Delphi for .NET just isn't good enough to be appealing as an alternative to VS.NET and MS has loads of resources that they are pouring into VS.NET. I just can't see how DevCo can acheive a platform advantage on a platform that they are having a hard time just keeping up with. By the time Highlander is released supporting .NET 2.0, .NET 3.0 will be right around the corner. .NET 3.0 has a lot of IDE work associated with it, so it seems very likely that in order to incorporate that into BDS is no easy task.
Competing with MS directly, on a platform that they not only control, but are offering better tools than they ever have, looks to be a failing strategy. MS tools are being developed by high profile ex-Borlanders who worked on Delphi itself. This isn't a shot at the talent on the Delphi team at all, just a recognition that MS has now assembled a lot of talented, experienced people to build developer tools for them.
The question that I've posed on non-tech a few times is what is the threshold for changing their .NET strategy? If by the release of Delphi 3, Delphi wasn't used as much as Turbo Pascal was, I believe it would have been regarded as a failure. Should Delphi for .NET not be held to those same standards? It's time for a new .NET strategy for Delphi.
The other problem is that as Borland continues on this quest, the native side of Delphi continues to suffer. There is still no unicode support, no generics, no Win64 compiler, etc. Certainly there has been work done on the native side of Delphi, but I believe that most would say that it has progressed more slowly than it would if .NET were not as big of a priority.
The first few BDS releases suffered from low initial quality. Delphi 8 was pretty much a non-event simply because most of the Delphi community aren't using Delphi for .NET, but it was awful nontheless. Delphi 2005 was a "dissapointing" release, and Borland employees have said as much. Granted, they didn't say this initially, neither did TeamB. This leads me to not trust "when it's ready", but rather I see it as "when we need revenue".
Non-tech can be non-sense when people claim that the quality and performance issues are because of the use of .NET within BDS. Many applications are using .NET successfully and reliably. I will state for the record that I definitely like the direction Borland is going with BDS over the old IDE core. The old IDE core was showing its age and despite fond memories it needed to be overhauled. I believe Borland made a lot of progress with Delphi 2006 on the quality front and their willingness to push out hotfixes/patches is a step in the right direction.
The problem now is that although they continue to focus on improving quality for the release of Highlander, they still have a lot of work to do! So not only does a few poor quality releases breed distrust, it makes it that much more difficult for them to move forward at the required pace that is already too slow.
One advantage that the new company will have is the possibility to adapt more quickly than Borland has in the past few years. First, they will be smaller. Second, they'll most likely be a private company where quarterly revenue marks won't be so important as overall growth over time.
However I still have some concerns about their ability to adapt. My concerns are: "Delphi myopia" and numbness to criticism. I've mentioned the phrase "Delphi Myopia" many times on the newsgroups and what it essentially gets at is what I perceive as the inability of those at DevCo to think about additional products beyond Delphi serving different needs. It's Delphi all the time, for every problem.
For example, in the .NET space, there is no reason why Delphi must remain DevCo's prominent product offering. I believe that a new language with new framework enhancements would have worked much better for that market. That's not to say that Delphi can't participate in the .NET world, it's just that it doesn't have to be the flagship offering. Delphi is good at what it's good at, but it hasn't been as successful as it was in the Client/Server days in addressing the Internet.
It's not that Internet development is beyond Delphi's capabilities, on the contrary, it's just that from the market perspective, it hasn't been as successful as Java or C#. It also has been stated that Delphi doesn't need to be as successful, it just needs to be profitable. That's true as well. The bottom line here is that Delphi needs to be different enough to be appealing for Internet development. I believe IntraWeb was different enough, the problem is that it didn't come from within Borland and once .NET became the direction for Delphi, Borland quickly moved towards marketing ASP.NET.
Delphi is good at many things, and its flexibility is one of the things I love about it. But I think what happens is that Delphi is seen as the answer to all sorts of problems and the strategy is to port Delphi to different platforms in hopes that its success will be replicated. I believe this is a mistake; this is "Delphi Myopia". New products need to emerge and Borland has yet to release a successful product after JBuilder. What ever happened to Charlotte? Hopefully DevCo will actually release new products.
The second concern I have is that the folks that will be at DevCo have become so numb to criticism over the years they will ignore the vocal pleadings of even their most faithful. The reality is that the development landscape has changed significantly over the past 5 years. The concern expressed for Delphi's future today is very different from previous "sky is falling" rants before. IDE's are now commodities, good quality compilers are free, Microsoft is very focused on competing against Java for developer mindshare. These factors alone are significant enough to reshape the whole developer tools business as Borland knew it.
The reality is that markets change and products and companies do indeed wither away to irrelevance. I'm not saying that this is what's going to happen to DevCo. What I'm saying is that to not acknowledge this as a possibility is a mistake. This is why the outright dismissal of "people have been saying Borland is dying for the past X years" is foolish. These things do happen and besides that, many of the current criticisms are not saying this at all. They are expressing concern about the current product direction.
DTG has recently talked about conducting surveys and they have indicated that there is a new Delphi survey on the way. One thing that should be mentioned is that the surveys that I've taken for their various products seem to be: 1) way late in the process to impact strategic direction and 2) ask questions that bias the answer towards what they are already doing. This is insanity and I hope that the Delphi survey that's in the works tries to avoid these pitfalls.
There have been many things that make me distrust Borland/DTG's ability to execute and remain consistent between what they say and what they do. At this point in time, actions speak louder than words so I'm going to wait and see what happens. I have a vested interest Delphi's continued success and relevance, so I hope that DevCo will be able to turn this thing around. But like all trust that has been broken, it will take a long time to earn that trust again. It will take longer than DevCo anticipates, it always does. ;)
There have been many positive actions that DTG has taken, but until the divestiture is complete we won't be able to see all of the positive changes that I know the DTG crowd desperately wants to make happen. I acknowledge their frustration with the situation, but will also point out that our frustration is also showing through our words and actions. The longer this drags on the worse it is for everyone.
I hope that DevCo will be able to be their own worst critic and reduce the amount of defensiveness they have been accustomed to showing while under Borland management. I hope they'll be able to look at their past mistakes, admit them and try to do things differently. I also hope that they look back and their past successes and recognize why they were successful and instead of trying to duplicate them exactly, have the boldness to offer significantly better products to developers in new areas.
I hope all these things, but right now I distrust their words. It's time for DevCo to deliver.
Write a comment
- Required fields are marked with *.







