NCIA, SDCIA, and MSGA Seed Programs

Tailoring an existing system for new clients

The Nebraska Crop Improvement Association (NCIA), South Dakota Crop Improvement Association (SDCIA), and Montana Seed Growers Association (MSGA) are responsible for seed certification in their respective states by providing third party inspection, interviewing, and, in some cases, seed testing services.

Technologies Used:
Laravel React

Within a few years, the success of the Wisconsin Crop Improvement Association (WCIA) project led to the Nebraska Crop Improvement association (NCIA) and soon after  the South Dakota Crop Improvement Association (SDCIA) to reach out to us about using the program. We decided it was most efficient to meet with both states simultaneously, so that all interested parties had input and we could better learn the similarities and differences between the states. Subsequently, the Montana Seed Growers Association (MSGA) also asked to join the program. While their operations are very similar to SDCA, there were still enough differences to do yet another needs analysis.

Challenges & Requirements:

The following challenges and requirements are highlights and represent but a small percentage of those included in this project.

  1. Challenge: While all state seed certifying organizations follow a single national standard, there is a fair amount of variability in the practices, crops, certification programs, and rules from state to state. What could be hard-coded for the original WCIA program could no longer be assumed for other states. A solution was needed to handle variations between states.
    Requirement: Allow for variations between states while minimizing complications and programming time during development both now and in the future. We determined a single code base would be appropriate to streamline maintenance, especially if additional states adopt the program. Similarly, a unified database structure minimizes complications; each state has a separate database but the structure of tables and queries are identical. To accommodate the differences between each states, anything that was specified directly in code moves to an Association Options data table and the program uses these options to determine how to function for each state. Currently there are approximately 160 options in use. Here are a few examples:
    1. Some states allow uploading of field inspection applications; others do not.
    2. Some states ask inspectors to enter their mileage and inspection time; others do not.
    3. States vary in how they present information on analysis reports related to noxious weeds.
    4. States vary in their minimum allowable level of weeds.
    5. States vary in their requirements of naming conventions for SeedLots and Certification Numbers.
    6. Some states group invoice data to minimize entries in QuickBooks; others do not.
    7. Some states invoice daily; some monthly.
    8. Some states charge taxes; others do not.
  2. Challenge: Given ambiguities in the national standard, not all states agree on certain arcane questions related to test calculation and display. Some questions are so central to program function that adding an Association Option to account for the difference would make programming extremely complicated.
    Requirement: Minimize complexity and programming time, while facilitating sometimes-contentious discussions to reach consensus.

Solutions

Needs Analysis

Given our experience in creating the original program for WCIA, Pushing7 already had a comprehensive understanding of the industry and its standards and practices. NCIA, SDCIA and MSGA had programs particular to their states that required the creation of new subsystems.

Pushing7 spent time meeting with NCIA and SDCIA in the first follow-on project to learn about their similarities and differences with WCIA and each other. When new requirements led to changes in the core code that could affect WCIA, we met with all three states to discuss what was needed and reach consensus. A number of times this consensus required the flexibility of each state so the system could be unified and work for all. Negotiations were sometimes delicate and required tracking the diverse requirements of three or sometimes four different states, plus the interpersonal/communication skills to facilitate these discussions.

Proposals and Estimates

The business rules needed to be summarized even more carefully in this follow-on project than the original given the increased complexity of requirements between three or four states.

We augmented our budgeting and invoicing systems to allow us to define one or more clients to share expenses for individual subsystem development. Thus, when a subsystem was developed for just WCIA it would be charged only to them; when for NCIA and SDCIA, only the two of them; or to all states when necessary.

We defined client-viewable reports so they could see the status of development for each subsystem and request adjustments in the order of development as priorities changed.

Always Plan for Future Expansion

It is common to need additional feature development after a project is complete—this project is an extreme example of this. If proper care is not taken, it is possible to design a system—particularly the data structure—that might make future development more difficult and expensive. Here’s a hypothetical example:

Let’s say a system is designed to track vehicles for a rental company. The system is designed with a table named “Car” that holds data such as: VIN, make, model, year and name of the driver. This system is completed, and it works great. Then, due to new laws put in place, the rental company needs to store the name of every passenger in the vehicle. So, the programmer adds three more fields: passenger2, passenger3, passenger4. But what about SUVs that hold 8 people? Or a bus that can hold 60? It would be better to store data in tables that correlate the entities in the real world. In this case, entities include “vehicles” and “people,” with a field in the People table linking it to the Vehicle record.

We have a rule at Pushing7: Make sure the date structure matches the real world. We have completed a number of projects that involved creating a new system to replace an outdated system. In almost every case, the data structure in those older systems didn’t match the real world, which required users to do all kinds of confusing workarounds that wasted time and prevented them from having accurate information.

By following this simple rule when creating WCIA’s initial system, we found that expanding the system for additional states (and the expansions were significant), it was rarely necessary to rework initial data structure and code to allow for the new systems—the original data structure was sound and expanded naturally to include the new entities.

Developing data structures that match the real world doesn’t necessarily have to cost more than “easier” methods of development. And in those cases where it does cost more, the additional cost is usually not significant. What IS significant is the additional programming costs incurred when future expansion of an existing system requires date to be restructured due to lack of foresight.