**DDMA IDA Objectives, Matt Sottile.**

1\. A single repository to capture useful algorithms developed by the
team. We have had multiple algorithms developed by students or
contractors who no longer actively work with the team, but IDA has
allowed the code and methods to live on without them.

2\. We frequently need to hand users deliverables for abstract
requirements that boil down to \"let us use DDMA metrics\". It used to
be hard to wrap them up into a form that didn\'t require much
handholding from an unlucky DDMA member. With IDA, it boils down to
\"make dist\" and emailing the resulting tarball.

3\. IDA on sourceforge provides a single, team-accessible means for
capturing feature requests and bugs. Previously, this was done by
emailing one or two people. Email gets lost, and sometimes relevant
people don\'t see bug requests. E-mail is a bad, bad, bad way to manage
this sort of thing.

4\. Coding standards. IDA imposes a standard for component interfaces
that, although restrictive at times, at least makes it possible that
users can know what to expect when calling algorithms. Without
standards, chaos ensues (or, as above, some unlucky person has to deal
with it). \*Coding standards are a widely accepted \"good practice\" in
the software industry and community as a whole.

5\. The not-yet-perfect, but-better-than-hand-rolled build and configure
system for IDA allows us to distribute code that is NOT pure matlab, and
deal with some of the portability issues that arise when dealing with
users on different linux distributions or operating systems like osx.
Hand-rolled solutions for large teams are not fun to maintain, and
frequently ruin the day of some unlucky person who has to deal with it.

6\. The controversial \"database\". It was put in place for two reasons
: being able to rapidly look at past runs without manually organizing
files, and to reduce compute time. The rapid-past-access thing is
probably used only by me, but I do know that the compute time reduction
has had an impact on others during the prototyping and knob-turning
activities that come along with data analysis. Reductions of hours to
minutes in a general (not case-by-case) way is a pretty good thing.

7\. IDA abstracts away the iteration over data files and parameters,
leaving open the option to pull tricks under the covers with respect to
parallel/distributed processing. People should NOT do this themselves,
for two reasons. 1, only a subset of the DDMA team is likely capable of
doing it (without help from some unlucky person), or 2. one person may
choose one parallel model (ie, matlab\*p), and another may choose a
different one (ie, some hand-rolled bag-o-tasks manager). This severely
limits the possibility of handing code off to others to use.

8\. Rudimentary, but functional and understandable interface that
requires only very rudimentary matlab knowledge. An X-division guy can
take the tarball, and string together an analysis pipeline, and view the
results without writing a line of matlab code. Of course, to do \"real\"
work they need to, but they can fart around with it for a very low
intellectual cost-of-entry. Remember: many of our clients do not use
Matlab on a regular basis, if at all.

9\. Hidden optimization. Say someone writes an IDA input file for their
analysis, and downloads a new version of IDA to use it with.

We are free to reimplement algorithms, either in faster matlab code, or
with a complete rewrite in C or Fortran, and the IDA interface standard
makes this transparent to them. This is a good thing - they don\'t need
to worry about compiling code for the optimized version (see build
system above) or seeing interfaces deviate much (see standards above).

10\. We did it the handrolled way for years, saw the limits, and asked
\"how can we do this better?\". The answer was Deepblue, and then IDA.
Unfortunately, like any project of this nature, the end goal is not
reached instantaneously - IDA is still a work in progress. Patience is
necessary, and expecting that end goal to be reached instantly
(especially with no official funding \-- remember, IDA is basically a
DDMA \'skunkworks\' project), is unrealistic. The point is, we did it
the handrolled way already.

11\. For large team efforts, particularly ones where people are
physically separated and loosely coordinated, it would be a royal PAIN
to keep everything in check for developing and applying new methods. IDA
at least aims towards bringing order to that process when it is a team
effort. This is likely not visible for individually-run tasks.