As we continue working through my list of principles for embedded biotech data teams, we move on to how we design and frame projects:
Design projects around scientific objectives coordinated with the overall organization.
This continues the theme from the last two weeks of viewing the work of a data team as broader than just the technical outputs. Today’s principle addresses two common failure modes: Defining objectives that stop at the technical outputs or, even worse, not explicitly defining objectives at all.
We often don’t deliberately write down project goals because they seem obvious. The goals is for the thing that we’re building to work. When we do write down goals and objectives, we often do it for the stakeholder’s sake. Since R&D can’t understand the technical details well enough to figure out the goal, we’d better spell it out. But in practice, deliberately writing down goals is even more important for the project team.
If you’re building a predictive model, the goal of the project isn’t to create an accurate model. The goal is to improve whatever process or larger project is going to use the model. If the model is 100% accurate but it doesn’t improve the larger process/project for some other reason, the modeling project failed. The same is true if we’re building an app or a data pipeline, or anything else.
Writing down broader project goals forces us to think about that broader scope, increasing the chances we’ll notice the thing that would make our 100% accurate model unusable.
Ok, I know what you’re going to say: What about internal technical projects that don’t address a specific scientific goal? Well, this brings us to the second reason larger-scope objectives are so important: They make it easier to compare the benefits of different projects, and thus define priorities.
If you make your pipeline ten time faster and nobody notices, it probably wasn’t worth the effort. But if someone does notice, and it makes it possible for them to use the outputs in a new way, then there’s your scientific impact. If your code refactor eliminates 90% of your technical debt, but you never touch the code again, then you could’ve just kept the technical debt. But if the refactor allows you to deliver your next update in half the time, which enables a new type of experiment, there’s your impact.
Even if you can’t predict the exact the impact of your internal technical changes, you should be able to estimate it, or identify potential impacts. And if you can’t then maybe you should put that project in the someday/maybe list until there’s a clearer impact.
"technical debt" is real. However, it also can be used a way just to spin cycles. Rewriting code and capriciously updating tools, can a) be disastrous, b) achieve no net gain, c) distract from more operational needs. Coders who are too keen to address technical debt might just be seeing the twigs and not the trees.
What does technical debt look like in biotech?
Writing down "goals and objectives" is hard. Oftentimes they are replaced by slogans and platitudes. Developing metrics is key. If the goals for each department are the same, there is a flaw. If a goal is too easily agreed to, that's another weak link. Revisiting goals along the way, might just prevent a runaway traiin.