Difference between revisions of "Philosophy"

Line 54: Line 54:
 
== Convention over configuration ==
 
== Convention over configuration ==
  
With increased modularity often comes increased complexity. One key way of addressing this issue is to provide sensible defaults (e.g., the [http://athinkingperson.com/2010/06/02/where-the-big-green-copier-button-came-from/ big green Xerox button]) as a way of dealing with complex software programs. We embrace the philosophy of [http://en.wikipedia.org/wiki/Convention_over_configuration convention over configuration] utilized by many large software projects in recent years.
+
With increased modularity often comes increased complexity. One key way of addressing this issue is to provide sensible defaults (e.g., the [http://athinkingperson.com/2010/06/02/where-the-big-green-copier-button-came-from/ big green Xerox button]) as a way of dealing with complex software programs. We embrace the philosophy of [http://en.wikipedia.org/wiki/Convention_over_configuration convention over configuration] utilized by many large software projects in recent years. For this reason, SciJava projects use the [[Maven]] build tool for [[project management]].

Revision as of 14:50, 28 October 2014

Template:DevelopmentImageJ, and the SciJava software stack in general, is developed according to certain biases, which we describe here. This philosophy has evolved over a very long development history, reflecting many lessons learned over a course of decades.Template:Sidebox== Release early, release often ==

ImageJ subscribes to the release early, release often mantra often cited in software engineering circles. In particular—and especially because there is a small core development team—the project is driven by Boyd's Law of Iteration: speed of iteration beats quality of iteration. That is not to say that we do not strive for quality—we do. But we have found through experience that more releases, together with guiding user feedback, push a project forward more efficiently than a slower release cycle does.

To ensure releases can happen quickly, each SciJava component is independently released and versioned, using reproducible builds with a "release ready" master branch. This allows individual SciJava components to be released with the push of a button, in a timespan less than five minutes. This puts bug-fixes into the hands of users as quickly as possible.

Open source

The SciJava ecosystem is strongly committed to open source software development. But this software is not an open source software product—it is an open source software project following an open source development process. ImageJ is funded by taxpayer money, so the project strives to be as transparent as possible, by doing it in public!

Why Java?

While it was once true that Java is always slower than the equivalent in C++, this is no longer the case. There have been quite a few benchmarks comparing Java vs C++ performance, this one probably being the grandfather of all.

Pragmatically, one should note that there is not really a big difference in performance when comparing Java to C++.

Java programs run without trouble and without recompiling on the major platforms: Windows, Mac OS X and Linux. And plugins compiled on one platform also execute on all other platforms without recompiling. And profiling and debugging is easier with Java than with C++. And all programs/plugins double as libraries.

So the true reason why we use Java is probably: it makes ImageJ accessible.

See also Isn't Java too slow? and Why is your software written in Java? from the LOCI FAQ.

Convention over configuration

With increased modularity often comes increased complexity. One key way of addressing this issue is to provide sensible defaults (e.g., the big green Xerox button) as a way of dealing with complex software programs. We embrace the philosophy of convention over configuration utilized by many large software projects in recent years. For this reason, SciJava projects use the Maven build tool for project management.