Jon Schindler/Strategies for Caret7

From Van Essen Lab

Jump to: navigation, search

Before diving into a wishlist for Caret7, I believe that a discussion of how we go about designing software, and how we go about evaluating norms and guidelines for the creation of software is crucial at this stage of development. In other words, we should start by highlighting the thought process that goes into solving problems with software. We should strive to ferret out the hidden assumptions that were made with Caret5, highlight them, and where they are incorrect, eliminate them.

At the highest scope, we should ask (and hopefully answer), the following questions:

How do we select and prioritize norms and guidelines for software development?

Above all, software design is intended to be practical. It doesn't matter if something is philosophically correct if it isn't usable. We can actually use this as a guideline for selecting norms and guidelines for development. Above all, our norms should strive to address issues that really exist. They should address the problems that have actually kept us, for example, from reusing caret5's code base as it is.

Using this as a criteria, such concerns as software aesthetics, while important, take a backseat to the issues that are forcing us to rewrite Caret5. When selecting our guidelines, we should ask, "How does this guideline prevent the problems we had in caret5?" I will select development guidelines based first on the problems with Caret5, and only after doing this, will select other guidelines that may also be important.

How do we organize our software, and what is the best way to organize it for maximum future flexibility?

Modern software is based on object oriented design. An object is a programming construct that groups related data and subroutines together into constructs that are called objects. An example of an object is a BrainModel, which encapsulates all date and subroutines related to displaying, processing, and interacting with a Brain Model.

We can choose to organize software along many different axis. There is no "right" or "wrong" way to do this. What makes sense in one context can be incorrect in another.

How we do we learn from past mistakes? How do address these issues and move forward?

Personal tools
Sums Database