10 ways to save Delphi Jan 17, 2007 19:45
There have been a few blog entries discussing the 5 things they would do to "save" Microsoft. Those blogs are interesting reads. Much of CodeGear's ability, and certainly Delphi's ability to survive and thrive depends on how well Microsoft does.
In the spirit of Guy Kawasaki and since CodeGear/Delphi needs more help than Microsoft, I figure I would throw out 10 ways to "save" Delphi. When I say "save" I mean save it from irrelevance, not death.
The OS is becoming less relevant, development frameworks are becoming more relevant. Cross platform development will help distinguish Delphi from VS.NET and make Delphi more competitive with C++ and Java. Delphi has proven itself to be capable of competing against C++ and Java. If Microsoft is going to face difficulties ahead, diversify Delphi.
Most Delphi users are Win32 developers. Find a way to give them something substantial to talk about. Be courageous and break backward compatibility to offer something new and experimental. Be bold and produce something completely bizarre but cool. Appeal to the inner geek in all of us. Give the R&D guys some latitude to produce some "less than useful things". Be remarkable.
On the strategic front of evangelism: the free Turbo Explorer editions are probably the best thing to happen to Delphi. But it's important to leverage this with a sustained marketing campaign. I see this as being akin to the "Spread Firefox" campaign. Do whatever it takes to "Spread Delphi", except bribe bloggers with pre-loaded laptops. 
Google is typically quite mum about the products in their pipeline. Their marketing strategy is not one based on anticipated products, but on tangible ones. They under promise and over deliver. They serve the community rather than pushing product on them. They attract rather than promote.
There's a distinction between engaging the customer in an honest dialogue and justifying poor performance. There's a difference between an explanation and an excuse. I'm genuinely grateful that CodeGear is more open about their intentions than Borland has been in the past. I think they've improved quite a bit on the communication front, but...
I'm sick and tired of hearing excuses. I'm sick and tired of seeing product delays and poor quality releases. I'm sick and tired of hearing how CodeGear is different than Borland. I don't want to know about your problems anymore; I have my own. Whatever problems you have, fix them. SOX got you down? Don't bother telling me about it, you could have gone private. Again it's not my problem. I'm your customer not your lawyer, accountant, shrink or priest/minister/spiritual guru.
While we're at it, let's debunk the argument that what Borland did in the past is irrelevant. It's really simple to debunk: no one would care about CodeGear if it weren't for Borland. CodeGear inherits a positive legacy and a negative one. They cannot separate the two and trying to do so is simply living in denial. Denial is a useful tool, it's tempting to live in it "happily", but it's just not healthy or realistic.
The core problem CodeGear has is one of distrust. I don't trust what CodeGear has to say. When there is distrust, even a legitimate explanation sounds like an excuse. Everything CodeGear says seems like an excuse. There's only so much patience people have:
It's been a long time since we've listened to Borland talking about how how developer tools were integral to their ALM strategy, then turn around and align their ALM products with Eclipse and Visual Studio. Not to mention categorizing Delphi as a cash cow. Remember what all the Borland faithful said at the time? I do. Some people suggested a separate company "Delphi Inc.". Remember what all the Borland faithful said about that? I do. Then when the divestiture was actually announced, we waited. Remember what the Borland faithful said then? I do. Now we find that CodeGear is to become a wholly owned subsidiary. Ok, I agree it's better, but hardly "under promise and over deliver".
I'm not saying that we should hold a grudge or not give CodeGear a chance at redemption. I'm saying that there are serious trust issues and that CodeGear should be held accountable for what they say and do. Consider this a time of "tough love".
Bottom line: until they start taking action, there will continue to be distrust. Trust takes a long time to restore, so this action has to be visible and sustained over a long period of time.
If there has been a major mistake in the stewardship of Delphi in the past 5 years it's been in regards to .NET. Hindsight is 20/20 so I won't harp on past mistakes here. The important thing now is to have a .NET strategy that leverages Delphi's strength and keeps it relevant in the .NET world. Delphi's strength is it's native code abilities: .NET Interop is what's going to drive value. IMO, the ultimate .NET interop capability is a mixed mode compiler. Short of that, there are a few practical things that Delphi can do going forward: host Winforms, interop with WPF or WPF/e, ADO.NET and TDataSet adapters, easy .NET consumption of native Delphi packages.
Also since they already have a Delphi for .NET compiler, one of the more significant things they could do to distinguish themselves from VS.NET is to officially support Mono. They could also roll Mono's C# compiler into BDS. This would also aid in addressing my #1 point above.
Modern IDE's are more like platforms than products. Modern IDE's have integration hooks everywhere and they're documented and/or visible because those IDE's are open sourced. The reality is that CodeGear can't do everything for BDS; like it or not, they need the help of the community.
Document the OpenTools API, create example IDE integrations, demonstrate this via screencasts, etc. Do what it takes to make this happen, or CodeGear might as well integrate Delphi into Visual Studio or Eclipse or NetBeans.
In order to leverage the community effectively there are certain technologies that need to be in place. Delphi in many ways was a pioneer here: its RTTI enhancements enabled things like design-time component-based development. Enabling technologies are vitally important to spawn innovation and extend the reach of Delphi. CodeGear would benefit greatly by beefing up RTTI in native Delphi.
In addition to RTTI enhancements, getting generics is vitally important. Focus on some core VCL enhancements. Leverage RTTI enhancements and create a better data binding architecture. Let's get Unicode in there. Let's get an IDataSet implemented. Let's get a standard set of generic containers. The community will fill in the gaps with fancy looking controls.
Another thing that I would like to see is the removal from having to "install" packages. Why can't Delphi pick them up based on a standard (with an override) directory path? Make it easy to install, reinstall and manage Delphi installations across computers and team members. Why can't I check in our Delphi installation into version control? Why can't I have project specific configurations? Push the limits on dynamic code loading.
Internet development is vital. Because of that, it's important to get the server-side right. In recent releases, I've pretty much ignored the included server-side technologies that Borland has built. Why? Because there were better third party offerings (e.g. RemObjects). But there are two existing things in the box they should unite: Intraweb and ECO. Do this and allow deployment to Linux.
The fact that ECO doesn't include all its runtime source is unforgiveable. I'm sorry, but that's simply old fashioned thinking and hurts ECO's overall adoption. Also, most of your customer base can't use ECO because they are coding in Delphi Win32. Bring ECO to Win32/native. If you can't, build something "ECO like". Just don't use dbExpress; we don't need another framework without source code. Design it to use an abstraction layer where all the great third party data access components can be used.
This is a no brainer and can be done independent of Delphi releases, it can be done now. 'nuff said.
If CodeGear were to do this, it would demonstrate that they are a nimble, agile company that is committed to developers. Full releases every 4-6 months. They should also do more CTP's, Public Beta's, etc. and will need to for the long term projects that take longer than 4-6 months. CodeGear needs to demonstrate through their actions that they are not like the slow and monolithic development shop Borland ended up becoming.
Adjust the roadmap in the same way: small changes more frequently. Don't wait a year to update the roadmap, let it be a fluid outline of CodeGear's strategic direction. Make it a "living document".
In the spirit of Guy Kawasaki's bonus #11, here's mine. Dump Together; many people strip it out anyway. ModelMaker technology is simply better. ModelMaker will provide all the Together functionality and more: refactoring, uml design/code synchronization, ECO designer surface, etc. If CodeGear is truly independent from Borland, this is one thing they can do to really show it.
So there's my list. FWIW, I'm not so arrogant to believe that I could do a better job at managing Delphi or CodeGear, this is merely a blog entry after all. All I do know is that I don't envy their task one bit. Good luck CodeGear! 
Write a comment
- Required fields are marked with *.