Wednesday 25 June 2008

Cooking code with the right ingredients

 

cooking code My previous post caused some very interesting discussions on the decisions that I am facing when starting on a new project. The suggestions were as varied as the choices in front of me. It seems that any of the alternatives can do the job, so why don't I just make a decision and move on? Because its at this crucial point that any choice I make will impact the direction of the application for many years to come.

About the only choice that is not under question is the development language of Delphi. Why? One person suggested that Delphi is dying and that we should all be using Ajax instead. Besides Ajax being a supporting web scripting language/tool that enhances JavaScript, the Internet is not my intended environment for the market I'm interested in pursuing. Oracle's APEX is a great development environment for that and with my recent experience in this it would be the obvious choice - if that was the audience. Delphi on the other hand is a very strong and proven development environment that can be as lightweight or heavyweight as required.

I have been involved in many varied software development projects using many languages and development environments. I can tell you from experience that 3 to 4 good Delphi developers can totally outperform 30 Java developers on a similar sized project by a factor of several months. I can also tell you that a lone Delphi developer can take on the big boys and totally capture the market.

But that's the tool, what about the ingredients? There has been discussion on InfoPower, TMS, and DevExpress components. I must admit that I know and enjoy InfoPower and I can complete the full development of the application before I have to purchase. The ExpressQuantumGrid Suite requires that I purchase it before I can even start to code with it. Much though it has been recommended, and indeed it does look nice, its out of the picture for my development. I simply can't afford to purchase it at this stage. TMS is good and I have used that before, however I still fail to see the benefits in most of the TMS components, perhaps I'm missing something.

InfoPower from Woll2Woll has had a lot of negative statements against it. One comment on my last post even suggesting that it looks a little dated. I thought that perhaps that's due to its demo screen dumps that try to show too many things with background images, interesting colours and an oversupply of fancy icons showing something less than professional looking. In reality I wouldn't use all the fancy background textures and some of the other features, but I would use the excellent usability features that their tools can give you. For example, simply by dropping a component on a form and setting a few properties, I can automatically create a full input screen with its own menu and imbedded controls.

I'll discuss the Firebird vs ElevateDB decision in another post. Both are very fine databases, both I'd highly recommend.

6 comments:

  1. AnonymousJune 25, 2008

    The right tool for the right job. It seems to me that you've made your choice on the tool. And a fine choice it is.

    All the ingredients are more a matter of personal choice and familiarity. Thank you for sharing your choices with the community.

    Also, I agree with your observation about "...3 to 4 good Delphi developers...". There is something about Delphi that makes us more productive.

    Cheers!

    ReplyDelete
  2. AnonymousJune 25, 2008

    Definitely Firebird. I've used FB 1.5, 2, and 2.1 in both embedded and server flavors. Single file, fast, very neat, clean and strait forward internal procedural language (one that you'll miss in most commercial databases)
    If you are going to develop an application with an embedded DB which you suspect will grow to some single digit GBs (In my experience 4GBs), I'd say the current best answer is Firebird. By changing a file name, it will change it's personality from embedded to client-server! It's just pure art!
    The best thing about Firebird is that it is truly zero maintenance. It'll just work for years. It has never died on me.

    As for the connection technology, I'd prefer DBX over anything else, specially mixed with Datasnap and ClientDataset (If you follow the right steps and come up with a good design, you'll end up with a very neat solution to compile an app in both 2-tier and 3-tier configs) There's an open source and VERY STABLE, FREE dbx driver for FB1.5 which you can find @ http://www.progdigy.com
    If you want a DBX driver for FB2.x series, you can go for CoreLabs or Upscene.

    For the installer, I'd go with InnoSetup. It is perfect for any size and number of installation files with a medium complexity of installation rules. By your descriptions, it's the right choice for you. It is also open source and free.

    As for the Grid and Data aware components, I recommend Ehlib. It's cheap (about $80), fast, VERY WELL DESIGNED, totally compatible with standard DB components, and very capable. You can use it's trial version for development. W2W has issues with visual inheritance which I would avoid for a professional product.

    For the reporting, I use Fast Reports myself, but Report Builder is just as fine.

    I've used all the components noted above in production environments, ranging from tiny client-server databases with single users, to huge multi hundred GB databases with 3-tier, online, complex and high-load application servers.

    I've also used W2W, TMS, DEVXPRESS, and almost any DB available in the market(!) for many different projects, but for me, the magic combination for a small sized, professional product is always what I recommended above.

    I disagree with Mr. Fletcher on personal choice and familiarity. The biggest challenges in product development are the maintainability (& support) and expandability.
    If you use good enough ingredients and a well thought design, you'll be able to support and grow your product, and easily customize it for special cases.

    For example, if you do not use Data Modules with DBX (or similar technologies), you'll not be able to simply change to other DBMSs for heavy load. If you use a simple client-server model (Datasets on the forms) it'll be impossible to do so in the first place. This means if a big company likes your app and orders it for a higher workload, you'll end up with a whole rewrite (a disaster!)

    Coming up with a good design is the key to productivity and quality. It will take more time to start the actual coding, but will come to the rescue when change is a *MUST*.

    ReplyDelete
  3. AnonymousJune 25, 2008

    Unfortunately those "3 to 4 good Delphi developers" are more and more difficult to find. And it is difficult to get a good developer who does not know Delphi to accept it.

    ReplyDelete
  4. AnonymousJune 25, 2008

    May I suggest PostgreSQL with PostgresDAC combination. All my software is using this and you cannot easily beat the Robustness, Supporting Admin Software, Ability to create installers incorporating database installations for client & server etc. etc. In my case, my experience is on developing large integrated systems with lots and lots of advanced features. I also use Gnostice SDK for FAX rendering and Eurekalog for automatic bug tracing and malfunction notification from customers.

    Best Regards

    ReplyDelete
  5. About discarding DevExpress as an option: I would urge you to reconsider. Yes, it requires a bit of money, but I have concluded quite some time ago that I never found better value for money. The support from these guys alone is reason enough to use their software. But let alone the support, I think the quality of their software is excellent. It will *save* you a lot of time and thus money. I'm not saying there no other decent packages out there, but the added value that DevExpress give to their software through their support is worth quite a bit I think.

    ReplyDelete
  6. AnonymousJune 27, 2008

    I suggest Delphi +TBetterADO+ SQLServer+ DevExpress

    They are all cost software, but if your project give you money, invest it.

    Alex

    ReplyDelete

Note: only a member of this blog may post a comment.