Assessing the impact on project schedule from using development libraries and code reuse

A question I asked myself is, when does using prior work save us time?

My co-workers often talk to me with passion about how much they believe in code reuse and how much faster it makes development time. Working in the research fields for a long time before I joined industry, I’ve always been apprehensive about the value of code reuse. My experience has been, it’s often an extreme time sink trying to get other people’s research work running again. My time in industry has also shown me slightly better, but still poor results when it came getting legacy code running. Libraries are okay if they’re mainstream, but obscure libraries can often be time sinks.

Snippets of conversation at work this week has helped me realise the main performance factor for using prior work is how easy it is to understand:

• “Engineers will rarely reuse code unless it’s their own code”
• “In-house libraries means we can easily debug and fix problems when things go wrong, where it’s difficult with 3rd party IP”
• “Developing on the mature platforms of a organisation makes the work so much faster”
• “I can’t get the reference design working, so I can’t copy their implementation”
• “A brand new FPGA board, where we have no experience, takes a long time to explore. 50% of the project time is figuring out how to get the peripherals of the new board working.”

Understanding makes the biggest difference when using pre-made code/hardware:

• The benefit of in-house libraries is the person who made the code is within the organisation, so can help others understand what the code does.
• Documentation and code readability makes the biggest difference in whether the code can be used.
• Working examples, especially ones that can be modified make understanding pre-made code/hardware easier.
• Trying to use code/hardware with poor documentation and no examples takes a really long time.

Always in the past, I would take a quick glance at prior work and would get an intuitive feel for effort it would involve, which often turned out accurate. I didn’t understand what I was intuitively doing, so it was hard to justify myself when others disagreed on my effort estimates.

Now with my new insight, I realise what I was doing was assessing how easy it would be to understand the prior work. Ease of understanding can be fairly quickly assessed without actually needing to understand many details, which is why I was able to come to a conclusion quickly. Then the accuracy of my time and effort assessments were because the ease of understanding tended to make the biggest impact to the eventual work effort.

This is a good step forward for me. With this I can justify my effort assessment to others, rather than just weakly saying it is my intuition.

More broadly, for developers or companies, making your work easy to understand with working examples and documentation make a big impact to the effort required for your work to be integrated into your colleagues or customers designs.