documentation and quality management

[hypertrader]

We are a group of European traders all using eSignal now for more than a year as a platform for developing trading strategies and integrated trading systems. We are pleased by the overall system design and its many features. However there are some issues which require more attention in order to avoid loss of time and money by its users and in order to make this good product an excellent one.

I alone spend 1000+ hrs over the last year designing, coding and testing. In spite of my programming background it was quite a steep learning curve which I experienced.

I think everybody who has attempted to develop a fairly complex system with EFS had the same impression and also the feeling that something should be done about it.

My estimate is that roughly 50% of my time could have been saved had there been available a more complete and up to date documentation of the EFS. This forum is helpful but it is no substitute.

Having a fairly exhaustive documentation of EFS and giving examples of what can be done with it would be a good start. (The existing online documentation is of fairly poor quality: it is incomplete, often lacks useful examples and contains too many errors.)

What is also needed is information about what (presently) cannot be done or shouldn´t be attempted due to system limitations and / or performance problems.

Finally it is obvious that a system like eSignal cannot be free of bugs. The problem is not that there are bugs but how they are addressed. It is not a shame to talk about them openly - it is just the opposite!

It is true that this forum is a good place to find SOME information about various problems one might encounter in designing and implementing systems. But this is spread out over hundreds of threads and the information found is incomplete, redundant and often not up to date. Therefore my guess is that many users spend way too much time looking for information about how to deal with problems they ran into; often without luck. Even if they eventually find a helpful hint – mostly by other users - it is a very inefficient way of dealing with problems which often could have been avoided with some more knowledge upfront.

What we think is needed is ONE list of known bugs, problems and possible workarounds which is beeing updated permanently. This includes status information about the effort to solve those problems.

Don´t get us wrong. We like eSignal. But we think there is a huge potential for improvement; not by increasing the speed of adding new features but by making the existing system more stable and better usable through improved quality management and documentation.

Comments and reactions highly appreciated.

[Gavishti]

Thanks hypertrader for bringing this up. I'm in a similar situation. I agree with all that you have said. It would be very helpful to have the documentation better organized and more complete.

By the way, thanks Chris Kryza for providing your help file. It helps a lot. And thanks eSignal for the EFS Reference Guide. It also is helpful. But we could use a lot more.

[Bartje]

For me it would also help if there was some kind of a "step through" feature for debuging, instead of having to add all the debugPrint lines.

[AndyS]

Hi Hypertrader,

Thank you for taking the time to express your thoughts on EFS. You raise valid points and I don't disagree with what you have to say. It is a challenge to balance the priorities needed for the business to be able to provide EFS and the Advanced Charts since it's inception.

Here's what I can offer you as to what we're doing to help in this situation.

- We have under development EFS2, which is expected to simplify the coding process as well as the documentation. While I don't as yet have an ETA on when this will be rolled out, we do expect it to happen later on this year.

- Documentation has been an area of challenge for us. Like you said, most of it's there, and much of the remainder is spread through-out the boards. To that end, we've just concluded the purchase of a knowledge base system which we believe will help us in compiling, combining, and centralizing all the available help documentation on EFS to one location. Look to see this implemented over the next month.

In summary, we're aware that we can do better on documentation and we'll continue to improve upon it.

Thanks again for your post.

[hypertrader]

Dear Andy,

thanks for your reply!


I don´t know what to expect of EFS2, hopefully not less control about the processing of data.

What I like to see in the nearer future are some concrete steps to document and deal with existing problems.

There are lots of things in eSignal that don´t work as expected leading to wrong signals or system crashes and in both cases to wasted time and money.

I know that there always is work to do to fix bugs in large projects but you have to do it most important YOU HAVE TO DOCUMENT EXISTING BUGS PROPERLY.

And if there is some major design flaw which cannot be addressed easily PLEASE describe the problem as clear as possible to give us users at least the chance not to run into problems without being aware of them.


I would like to give some details which do illustrate which kind of problems I ran into over the last month:

1) When accessing data of another (nonprimary) symbol (e.g. $Tick) there is an offset between the primary (e.g. ES M4) and the nonprimary symbol increasing over time.
This effect depends on the TimeTemplate. It seems that the EFS engine does not care about the tick/bar time stamps when loading/processing multiple symbols. This is particularly annoying when using 24hrs templates.
Is there any further information available about this effect?

2) There is a discrepancy between getValue("time") and getValue("rawtime") of approx. 61min.

http://forum.esignalcentral.com/showthread.php?s=&threadid=8099

Any explanation for that?

3) Tick chart data do drift even after a couple of seconds.

http://forum.esignalcentral.com/showthread.php?s=&threadid=8102

What is happening there and how can this be avoided?

4) Zero trade tick data seem to be missing.
Is this a bug or a feature?

5) debugPrintln(String) seems to be crashing the system if String reaches a certain rather low length.
What is the exact limit if there is any?

6) Are there any guidelines to optimize system performance? How do heap and stack size setting for the formula engine affect performance?

to be continued....

[Guest]

FWIW,

I noticed you talked about the use of debugPrintln. This can impact impact performance and cause crashes if the formula output window is not periodically cleared (debugClear()) see this link