How to choose developer tools (Delphi)?

Question

As stated in many places in SO "hardware/software is cheap, people is expensive".

Tools, like the ones listed here can really make a difference. Now I am stepping out of the cave and I am realizing that i must update myself.

I started studying "theory", I have a busy schedule for reading books on Refactoring, UnitTest, OOP Patterns. But all this is a lot of theory.

It is very good to do refactorings, write tests and apply patterns. But doing this simply in Delphi IDE (copying and pasting code/using the buggy built in refactorings) it is good for understanding the concepts, but for being proficient I feel tools are a must. Without a UML tool, I think it is impossible to refactor complex classes (or, even worse, legacy software where classes are just containers for procedural code). I am not experienced yet in OOP, but I translated in Delphi and followed step by step chapter one of Fowler's Refactorign. Yes, I see the great benefits, but I also realized how easy it is to get lost as many methods start to be added to classes (for good OO design). In those theoretical books there is almost never a reference the a CASE tool, or they say (I read this on Ambler's Object Primer) that CASE tools won't change your lifes. I agree that a CASE tool is not the starting point, first one must master the idea, and then use a tool (somehow we learng writing a language on paper and the we move to word processors). Sticking on that first chapter example. I never used a CASE tool with advanced refactoring optinos, but I am sure it would have taken 1/3 of the time to do those refactorings with a tool.

And the same applies for all other cases: UI testing for example. One test I need to do in one application is to push all the buttons to see if errors occurs. If a tool allows me to do this, even if it costs 500$ it is worth.

Another example DUnit. Yes it is free but many things are left to the develoeper. If a tool like TestComplete makes me save time and money and headache, why shuoldn't I go for it?

Then a problem comes from choosing the tools. I see these problems:

1) etherogeneous tools that has great features can be comlpex to learn and master, while a suite of tools with may be some less feature can speed your way up. (for example buying 3 tools from same vendor, or a tool that does 3 things is maybe better than buying the 3 best tools from 3 different vendors)

2) Make a priority list: which tool do I need first? Buy only that one, master it then go to the next? The only tool I am using now is proDelphi profiler, may be it is not the best profiler on the world (now AQ is even built in in Delphi XE) but anyway being able to use it it helped me in finding bottlenecks I couldn't guess.

3) buy it or code it? I often read on forums about "buying dataabstract vs write your own libraries for 3-tier developement". Coding everything can be ok for a huge organization but for a small one as mine I think the solution is investing in 3rd party libraries (picking of course the ones from companies that seems not near to bankrupt). Let's make the dataabstract example. It costs around 1000$. Let's say the cost of a developer is 2000$ per month (just to have an idea). Anyway you get the library at less then 1 developer month work. Buying upgrades is like maintaining the libraries. The cost is much less and the features and performance are better.

4) I don't see a point of dimishing returns with tools/libraries, but may be I am wrong.

Somehow to step out of the cave of procedural programming and enter in the world of effficient programming there is monster jump to do. Doing OOP on simple "book examples" projects is nice. But putting it into practice in wide systems is scaring, expecially because I don't have an expert with me, I have to do it on myself.

Final thought: using tools, buying libraries... I think this is necessary to delegate to tools/libraries some tasks and focus only on what I really need to do. Anyway I am confused a little, scared too. May you please comment on what I wrote and give suggestions that can help me?

Answer 1

1) Good point: in fact, heterogenity can be like a nightmare. For example, if you want to upgrade your IDE version, what about all third-party components? Every one must be compatible with the new IDE. If the owner of the component still maintain it, you can hope, ask and pray for an update. If there is no official maintainer anymore, two possibilities, depending on the source code availability. If you don't have the source code, it's a dead end. If you have the source code, you'll find out that all the features of this component need to be updated, even if you use only 1% of it... this will be a time waste. Some third-party components are well documented. Other (most of them, IMHO) are very poorly documented. This could be a major time waste if you've to fix the source. And it could be a major problem if your SQA requirement is high (how do you document/trace/test these SOUP?). My last project was in biological analysis, so FDA wanted us to document everything.

2) Priority is the root of Project management. I agree with you.

3) I don't see the point about the company size. I coded a whole framework alone, and the time spent in this coding was not wasted: we had the exact tool we needed, and we didn't waste time about understanding some other code. Only the UI part was using third-pary components. But the most delicate part (database engine, reporting, ORM, Client/Server, UI generation, i18n) was all developped on purpose, with dedicated unitary testing.

I just met some R&D guy, which said to me "if you can get some component on the shelf, this is worth the money if I don't pay a developper for it". This may be a good idea for short time. But the more third-party you got, the more stuck with it you are. I've seen several projects with so much third-party libraries at once... for example, 4 reporting engine for one application... a nightmare to maintain! How many Delphi projects are stuck in Delphi 5 version for such reason?

IMHO, it's a good advice to waste some time at the beginning of a project, and select a framework which meets your needs, and extend it (if necessary) to your purpose, to enhance documentation and maintanability in the future. If your coding is well documented and architectured, the time spent in the beginning will not be wasted. You'll find it easier to maintain your project in the future.

With some Open Source frameworks, you can get the source, then contribute to the project. I think it's even a better approach than only "consumming" third-party components.

Just two examples, taken from our http://synopse.info experiment. We included both reporting and unit testing in our last framework, resulting in a strong and consistent architecture, ready for Unicode. About testing, we were able to include all the corresponding reports into the main documentation process (using our powerful and GPL SynProject tool). About the Report engine, some users around the world helped us (for free) debugging Arabic or Chinese for the reporting or pdf generation, and the project was compiling/running from Delphi 6 up to Delphi XE. "Sharing is everything" at this level.

Answer 2

From my experience, libraries are never worth buying unless they include complete source. This way it doesn't matter what happens to the vendor, you always have the ability to upgrade the library or apply a patch for a specific need that the vendor did not consider.

ALWAYS keep a copy of the original source separate from your changes. A simple method of doing this is to check all of the library source into version control. You can use the diff tool to see the differences between releases, and will make merging any specific changes you made easier. When you do make a change to a library, place a comment block around the change describing what your doing and why. Good chance that you won't remember a few years down the road when the vendor releases a huge update and you need to perform a merge.

As far as the buy/build argument... I tend to focus on the buy for specialized libraries, and the build for enhancements to what already exists in a VCL control. The exception of course would be to achieve a specific look that is being requested by the customer/management.