Plant Breeding Trial Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does modelling the line instead of the seed lot happen so often?

Because the line is what everybody talks about. Breeders discuss lines, advancement meetings discuss lines, and the first data model somebody sketches has a line table with a quantity field on it. The quantity field is the tell.

A line is a concept. A seed lot is a physical object with a location, a quantity, a harvest year, a parent lot and a germination test. Every planting consumes a lot and every harvest creates one, so ancestry is a chain of lots rather than a pedigree string. Systems that treat inventory as an attribute of a genotype will happily let a programme advance material it does not physically have enough of, which gets discovered in the planting shed in March when there is no time left to change the plan.

The second symptom is subtler. Without lots as first class records with parent links, there is no way to answer where a specific packet came from, so when a result looks anomalous the only available response is to doubt the result. That is how a programme ends up with a data set nobody quite believes.

The fix is a whiteboard test before you sign anything. Ask a prospective developer to model germplasm on a board in the first meeting. The right answer separates the line or genotype as a concept, the seed lot as physical inventory with a parent link, the plot as an observation unit and the observation itself, and it can explain how a lot's ancestry is traversed backwards through increases, crosses and selections. A developer who draws a line with a quantity field has not understood that identity and inventory are the same problem here.

What goes wrong when you migrate decades of nursery books?

This is usually the largest single line item in the project and it is almost always underestimated, including by teams that have done it before.

The problem is not volume, it is convention drift. Pedigree strings encode notation that changed over time, sometimes when a particular breeder retired. Location codes were reused for different fields in different decades. A trait scored on a one to nine scale in the 1990s was scored on a one to five scale later, with no note about which is which. Check varieties appear under three different names. And the only person who can resolve any of it is your longest serving breeder, who has other work.

The failure mode is scope. A programme decides to fully normalise forty years of books before the new system goes live, the exercise consumes the breeder who was meant to be validating the new workflows, and the project stalls in month four with nothing planted in the new system.

The fix is to split the migration deliberately. Convert the material that is still active, meaning lots that exist physically and lines currently in trials, into the full structured model with a review pass by the breeder. Everything else becomes a searchable archive, imported as it stands with its source recorded, resolvable later if a specific line matters. That is not a compromise, it is the correct allocation of a scarce resource, since the value of normalising a 1987 nursery book is a small fraction of the value of getting this season planted cleanly.

Budget breeder time explicitly in the plan, in days, with named weeks. Migration in this domain is not a data task, it is an interpretation task performed by your most expensive person.

Why do the handheld, genotyping and analysis handoffs break after launch?

Three integrations decide adoption, and each fails in its own way.

The handheld fails at hour six. It worked in the office, it worked in the car park, and in a nursery a mile from any signal it runs out of cached data, cannot resolve a plot, or silently stops saving. Raters then revert to paper, and paper transcribed in the evening is where scores get attached to the wrong plot. Offline is not a feature to add later. It is the operating condition.

The genotyping handoff fails on identifiers. Marker data arrives from a service keyed to sample identifiers your laboratory assigned, and those have to reconcile to the seed lot or the specific plant in a specific plot that was sampled. If that reconciliation is manual, it is the second most common place identity breaks after harvest, and it caps everything you could do with genomic selection regardless of how good the models are.

The analysis handoff fails on reproducibility. An analyst pulls an extract, runs a mixed model in R, and produces estimates. Six months later nobody can say which extraction produced them, whether the exclusions were the same, or whether a quality flag applied at the time has since been changed.

The fixes are practical. Test the handheld for a full working day with connectivity disabled before you accept it, and require scanning rather than typing to select a plot, with previous ratings shown in context. Build sample tracking so a leaf punch carries its lot and plot forward into the laboratory identifier. And make analysis extractions immutable and identified, so a set of estimates is permanently traceable to the exact extraction that produced it, including design, as planted layout, quality flags and exclusions.

What happens when trait definitions and seed movement are not covered?

Two gaps quietly ruin data sets, and both look like administration during scoping.

The first is trait definition. Without an explicit layer holding scales, units and permitted ranges, a rater enters a nine on a five point scale and nobody finds it until a statistician does in March. Worse is the missing plot recorded as a zero. A lost, flooded or grazed plot entered as zero enters the analysis as data and biases every estimate downstream, and because zero is a legitimate value for some traits, it is invisible in any summary. Missing and lost must be distinct states from zero throughout the entire system, including on the handheld screen where the rater actually decides.

The same applies to harvest. Store the raw weight, the moisture reading and the correction applied, not only the adjusted number, because correction bases change and you need to recompute rather than re-measure a crop that no longer exists.

The second gap is seed movement. International shipments carry phytosanitary requirements and material transfer agreements, and public and private collaborations carry terms about what can be done with material and what must be reported. Systems that model shipments as a note on a lot cannot answer which of your current material arrived under terms that restrict its use, and that question arrives at the worst possible moment, usually during commercialisation.

The fix is to hold trait definitions as data validated at the point of capture, keep missing and lost distinct everywhere, and model incoming and outgoing material transfers as records attached to lots so restrictions travel with the material through every subsequent increase.

Should you build custom or configure what you already own?

If you are a small public programme or a young company running a few thousand plots a season on standard breeding schemes, do not build. The Breeding Management System is a serious option and comes with a community behind it, and AGROBASE has a long track record in exactly this work. Phenome Networks is a reasonable choice where genotype and phenotype integration is the central need. In all three cases you will get further faster than with a custom build, and we would tell you that rather than quote one.

Before commissioning anything, find out what your current tool can actually do. Programmes routinely use a fraction of a package because it was configured once, years ago, by someone who has moved on. Trial design generation, label printing and field book export are commonly present and unused. A configuration review is a few weeks and occasionally removes the reason for the project.

The build case starts when two or more of these are true. You run more than roughly 20,000 plots a season across several locations. Your advancement scheme or a key pipeline is proprietary enough that the package forces a shadow spreadsheet, at which point the shadow is the real system and the official one holds a partial copy. You are integrating an automated phenotyping platform, imagery or sensor data whose volume a general package does not accommodate. Your commercial pipeline needs breeding decisions to connect to seed production planning. Or your marker and phenotype data cannot currently be joined with confidence.

Note what is not on that list: dissatisfaction with the interface. Rebuilding a package because the screens are dated is the most expensive way to solve a training problem.

How do hidden costs get into the quote?

The engineering estimate is usually the reliable part. These are the items that land afterwards.

• Crop count. A clonally propagated crop, a hybrid crop and a self pollinated crop have genuinely different structures. A system covering all three is closer to three systems than to one with a dropdown.
• Legacy migration and breeder time. The largest line item, and the part nobody prices is the days of your most senior breeder needed to resolve convention drift.
• Doubled haploid or transformation pipelines. These bring laboratory workflow, plate tracking and their own quality control steps into scope.
• Field hardware. Rugged devices, barcode printers that survive a nursery, label stock that survives rain and a spares plan are operational cost that arrives with the software.
• Imagery and sensor volume. Automated phenotyping data changes the storage and processing architecture rather than adding a table.
• Regulatory documentation. Phytosanitary paperwork and material transfer agreement tracking for international movement is a workstream, not a field.

What separates a build that works from one that fails here?

Four things.

The first is barcode discipline at creation. Labels printed at the moment a lot or plot comes into existence, applied to packets, trays and bags, and scanned rather than typed at every subsequent step. Handwritten tags fail in exactly the conditions harvest happens in, and adopting scanning at planting and harvest removes the single largest source of irrecoverable error in a breeding programme. This is a process change the software enables, not a software feature, and programmes that treat it as optional get the old failure with a new database.

The second is holding designed layout and as planted layout as separate linked records. Planters skip, ranges get shortened by a wet spot, fill plots go in where checks were intended. Spatial adjustment at analysis time is only meaningful when the coordinates describe what was planted rather than what was designed, and field maps have to print in the orientation the technician actually walks, which sounds trivial and is a common reason programmes revert to paper.

The third is knowing what not to build. Mixed model analysis stays in R or specialist statistical software. A partner offering to rebuild your analysis engine is scoping risk without capability. Their job is reproducible extraction, and adopting the Breeding API specification for interchange is worth doing where you exchange data with collaborators or public programmes.

The fourth is ownership and exportability. You should own the repository, the cloud accounts and the right to hire anyone else, in writing before kickoff. At Digital Heroes the code is yours from the first commit. A breeding data set outlives most software and most employment contracts, so export in an open format is a programme requirement rather than a preference.