Software Development Lessons Learned
Software development often proves to be much more difficult than initially expected. It’s not uncommon for projects to exceed their budget due to unforeseen complexities, requiring additional expenses for development hours, tools, or consultancy. Similarly, the time needed for testing and resolving issues can be significantly underestimated. To combat this, it’s advisable to invest in software development resources and ensure your project timeline includes a generous buffer for edge testing and bug fixing.
When it comes to creating software architecture, it’s crucial to remember you’re building a system that must interact with multiple internal software components as well as external software products. It must be easily upgradable, and adaptable. We’ve learned some hard lessons about the pitfalls of restrictive architecture, which later required costly fixes. Early, thorough planning for all data flows and system interactions can mitigate these issues. Moreover, if your software will be integrated to other systems, this should be a core component of your architectural strategy. While programming can be outsourced, the core knowledge of the architecture and software’s purpose should stay in-house, well-documented to maintain control and continuity.
Software projects can easily veer off course if not monitored closely. Continuous engagement with the development team is essential to ensure the project aligns with the long-term architectural vision and customer requirements. Beware of scope creep, where additional features inflate the project’s scope without corresponding benefits. Development should focus on what the customer truly needs, not just what’s easiest to implement now. In many cases we have seen an agile approach using sprints can be advantageous over the historical water fall approach to control scope creep.
Considering how software will be deployed and maintained is equally important. Decide early who will provide the hardware, the customer or supplier, as this affects software licensing and support. Plan how updates and maintenance will be managed once the software is in use by customers, thinking about remote access, user training, and support systems.
Finally, if your software must comply with 21 CFR Part 11, design compliance into the system from the beginning. For those new to this area, involving a compliance expert early is wise. Part 11 requires meticulous logging of actions, necessitating specific data fields and an audit system to document changes, which should be part of the initial design to avoid retrofitting into compliance later.
