Enterprise Core Objects Survey Results

Once I created ECO Survey on the DC Portal® to know how developers are happy with it and what they actually develop with ECO. The DC Portal® always helps me in such situations and I highly recommend it for everybody who wants to gather some data online. UPDATE: Please notice the survey was originally oriented to ECOIII, but it seems it got responses from ECOIV usesrs as well. And now I want to share some interesting facts. I'll start from some diagrams and at the end will summarise peoples' opinion on ECO. I don't try to express my personal opinion and do my best to avoid it and only operate the facts and results of the survey. If you think I'm not correct or push my opinion, please let me know.

Application Type

It is a great thing to see developers producing both Windows and Web applications which means that ECO can be generally used in most projects of different complexity.

IDE and Language

The most interesting fact for me is that people want to or already do develop ECO applications using both C# and Delphi.NET and both Microsot Visual Studio and CodeGear RadStudio. The difference in IDEs is pretty small. But the C# language is a bit more required than Delphi.NET. Many respondents noticed they want to use both C# and Delphi.NET. Other IDEs and languages are not worth to mention in this case. It means for me that ECO should (and it looks like it does) extend its influence to other markets as well as keeping existing one (Delphi.NET).

Concurrent Users

Most of ECO applications handle less than 10, and less than 100 concurrent users. But this is worth to mention that definition of number of concurrent users can vary depending on type of application. It also just has different definitions. This is how Wiki defines it: "the number of concurrent users for a resource in a location, with the location being a computing network or a single computer, refers to the total number of people using the resource at the same time". I had to add some description to the survey to explain what actually I meant under concurrent users. So this part might not be very objective.

Satisfaction

Most respondents are satisfied well enough to use ECO (53%) or feel it is acceptable for them (35%). The "highest option" (ECO is the Best Possible solution) got about 5%. On the other hand 4% told that ECO is Bad and 3% - worst possible. This obviously means ECO is a very good and mature enough product for real-life applications. But it also has lots of space for improvement.

ECO Improvements

Most of developers believe that ECO should be much better in terms of performance. Query Generation and OCL are also very important. It looks like ECO API is very good because of it is the least required to be improved. "Other" section got more than API ratings, so there are other major areas not included in the survey people would like to see better. The other question was about how many records the largest table contains. It varies a lot. But most people (22%) told about less than one million. Less then 10 millions - 15%. Only about 1 and a half percents of respondents provided value of "less than thousand". "Above 10 millions" got about 12%. All that looks like ECO can successfully be used in very complex systems with large data volume.

Respondents' Comments

During the survey completion respondents were able to provide some comments. I'm not going to publish all of them here and will try to summarise them as accurately as I can. All people are pretty much sure: ECO is just a great framework and allows them to produce qualitative, maintainable applications with hight speed. This is the general idea of all (or at least most) of the respondents. Many of them say something like "I can't imagine my .Net developments without it any more" (quotation). But the same time lots of people are not happy with the following things:
  • No WinForms support. Some people just don't like, but some experience problems porting their applications.
  • IDE. Some respondents experience problems/crashes working in BDS2006.
  • Slow evolution and issue management. This hopefully will be improved - CapableObjects can manage it by themselves.
  • Lack of good documentation. UPDATE: EcoIV should has much better documentation thanks to Peter Morris. I suppose it is mainly about EcoIII.
  • Other platforms/DBs. Some requirements to run ECO on Mono and different DBs (like Firebird).
  • Bad handling of large datasets.

Summary: The Verdict

The Enterprise Core Objects Framework has some inconveniences and minor problems. But based on the response of experienced users, ECO is one of the best available frameworks that allows achieving development goals faster, produce applications of the best quality in shorter terms. It seems nobody who ever used ECO left it. New users feel some knowledge leak about ECO, but even they realise usefulness of ECO. It seems like they cannot stop learning it.

My 2 cents

Here I express my own opinion :-) Personally I have had some performance issues, bugs and other difficulties (and most of them were solved thanks to Jonas Hogstrom). But even in such situations it is always faster and better to apply workaround than produce the same system without ECO. Most of performance issues can be solved just by tidying ECO queries (OCL), choosing right components etc. But if even nothing helps in a particular situation, it is always possible to use old good DataSets with direct SQL (especially in Eco4). ECO becomes a kind of a high-level language over .NET platform with similarity to Delphi over Win32 (or even assembler :-)). So I wish ECO good luck and all the best. Thanks to Peter Morris for beeing a great helper for the community. Thanks a lot to Jonas Hogstrom for his invaluable contribution into ECO and always beeing helpful for the people. Thanks to Jesper Hogstrom and Jan Norden for all the help provided in Newsgroups. Thanks to all the ECO Team for keeping good work. Happy development with ECO and decision making with DC Portal®!