In software engineering, premature optimization is the term for when you start trying to make something work better before you've completely settled on how it works or even what it does. There's a form of this that might be called premature productionization
In "Zen and the Art of Motorcycle Maintenance" the author contrasts the bottom up parts-> train model with top down train moves stuff. It's difficult to modernize any process midstream, so making good value judgements early on, with an eye on getting there, on schedule, on quality, and on budget requires both forethought and hindsight.
Our experience at Sapio is that people should be willing to get something live very fast even if its a little "dirty". We can go extremely fast in a V1 if people buy into this approach. Then the users will use it, maybe break it, but importantly will know what they like and what is missing. Then we iterate very fast again on the next release.
The challenge is we are asking people who live by rigor and protocol where precision in definition are very important to be less so on the ELN/LIMS implementation. But LIMS/ELN projects are not identical to experimental or lab processes, even though we want to model these. For lab processes there is little wiggle room as if you change things you can get bad results, but with software there is always wiggle room as "what" you track and how is always open for debate. So best to go fast and get it in the hands on the users and iterate...this will lead to a better solution faster and at lower costs.
In "Zen and the Art of Motorcycle Maintenance" the author contrasts the bottom up parts-> train model with top down train moves stuff. It's difficult to modernize any process midstream, so making good value judgements early on, with an eye on getting there, on schedule, on quality, and on budget requires both forethought and hindsight.
Our experience at Sapio is that people should be willing to get something live very fast even if its a little "dirty". We can go extremely fast in a V1 if people buy into this approach. Then the users will use it, maybe break it, but importantly will know what they like and what is missing. Then we iterate very fast again on the next release.
The challenge is we are asking people who live by rigor and protocol where precision in definition are very important to be less so on the ELN/LIMS implementation. But LIMS/ELN projects are not identical to experimental or lab processes, even though we want to model these. For lab processes there is little wiggle room as if you change things you can get bad results, but with software there is always wiggle room as "what" you track and how is always open for debate. So best to go fast and get it in the hands on the users and iterate...this will lead to a better solution faster and at lower costs.