Our Process

We’ve had a lot of experience with different application needs and program eco-systems. Over that time, we’ve worked out a pretty fool proof way of doing our work. The software industry has a long history of creating the methodology ‘du jour’ and then giving it a fancy marketable moniker.  Notable are Agile, Xtreme, UML, the Grady Booth method, and  the Yourdon methodology.

We couldn’t think of a catchy name, but there are several precepts we do follow.

1. Close to the Client

Our average system remains in use for over a decade and several are in the middle of their third decade. The reason for this is that we we go to great lengths understand what our clients need their software to do.  This involves extensive interviews with clients about their needs and critical objectives. This is a very empathetic process. Good software anticipates and shapes work flow and information in ways that leverage clients’ key capabilities. When it’s done right the whole process smoothly glides the program into being and we end up forging an enduring long-term relationship with clients.

2. Business Logic should be encapsulated in data structures.

Programs should administer data structures. This is sometimes difficult to fathom, but let’s look at a simple example. Let’s say that we want to email birthday greetings so many days before a person’s birthday. You could write the program to send birthday greetings  three days prior. But it would be better to create a database into which the client can store a ‘Birthday greeting interval’ that would then get applied automatically as the calendar advances. If usage shows that four days is a better interval, that decision can be implemented without changing the program.

3. Data Validation.

A corollary of Precept #2 is that data should be validated. If you are adding a new record to your master data table (a customer, a contact, a client or a member), there is certain information that must be properly entered in order for a record to be considered valid and usable. Some fields must not be empty. Some fields should only be validated against a list of pre-defined alternatives in order to ensure data quality. (An example is picking a province from a drop-down box of choices.) Program logic and data structures are externalized into control table. These are then manipulated by the program, using the data created and maintained by the client to administer very complex business flows.

4. Deliver early, deliver often.

This is known in the trade as  RAD (Rapid Application Development).  It entails creating many iterative releases from which the final program ultimately emerges. We’re firm believers  in this.  It involves the client in the details of the system; giving end users real input and control over the way the system ends up working. It not only results in a better system but one which receives a broader and deeper acceptance of the program by users. Secondly, RAD catches bugs and gets them fixed earlier. There is a famous software aphorism that says that given enough eye balls, all bugs are shallow. This has certainly been true in our experience. Finally it prevents poorly implemented features from disrupting workflow as they become the norm. Programmers, being human, get enamoured of their own thinking and can easily program themselves into corners. Frequent iterative releases tests these ideas early on and they get refined or dropped. Either way, we don’t end up spending time and money on stuff that doesn’t work.

5. Do the reports last.

Often the design process becomes dominated by a list of reports, existing or otherwise. It’s easy to think in terms of reports, but using these as a starting point is usually a mistake. A report is a static time-frozen representation of data. Having a new system usually means that data and work flows are going to change. Premature consideration of reports closes important areas of exploration. For a program to succeed it must creatively manage those work flows; creating the data on which to report. In additon, writing reports requires a reasonable amount of data to use as the raw material of the report. The RAD process usually generates a fair bit of testing data for use when report creation time comes. Lastly, until quite late in the process of development, data structures and the like are highly volatile, changing in response to testing and refined program design. Unless left until quite close to the end, you end up writing the reports twice, a not very efficient use of client resources. We feel so strongly about the importance of getting the reports right that we have an entire separate page devoted to the topic.

6. You get the source.

When we write a system for clients, they not only get the compiled binary program, they also get all of the source code created for the client, our development library itself (released under the GPL) and a working copy of the development IDE installed on one of thier servers.   This leaves control exactly where it should be, in the hands of the client. While we  like clients to continue using our development services, they are not required to do so. Clients have everything they need to change and build new versions of the program. This arrangement is part of the fundamental relationship of trust that we strive for.

Written By: Rick Gregory

Image Sources:
http://www.aust.edu.ng/school/index/computer-science/about
http://www.edrawsoft.com/Yourdon-and-Coad.php
http://photo.elsoar.com/many-people-playing-video-games-pictures.html