Adaptive has launched an initiative to dramatically raise the bar on quality in TORQUE. We have a team of our best developers working on this effort, and we’ll be blogging regularly about our progress in coming days.
Here is a sneak peek into what we’re working on:
1. Drive down subtle bugs that only manifest under high load, using Coverity.
Adaptive has begun hourly scans of the TORQUE codebase with Coverity, a sophisticated static code analysis tool that is able to predict permutations in execution path across many types of load. This adds invaluable maturity to TORQUE’s new multithreaded performance improvements.
Progress on this front will be measured using an industry-standard “defects per thousand lines of code” metric. We’ve already made significant progress, and we’ll report how that metric changes in coming weeks.
2. Make it easier to contribute patches and see the dev team’s code activity.
Stay tuned for an announcement on torquedev about how it will be easier to contribute, monitor, and participate beginning next week. Our plans should also facilitate safer and faster branching for the community and for customer hotfixes.
3. Invest heavily in new unit tests.
Adaptive has worked hard over the past year or so to integrate TORQUE with the check unit testing framework, which allows internal and external developers to quickly validate new logic, and to exercise existing code with an eye to regressions.
Now that the foundation is solid and familiar, we can move on to phase 2, which is to dramatically increase test coverage. We have audited the codebase for test coverage and identified the 10 modules where additional tests would be most valuable. We will be publishing our progress on test coverage % regularly in the future.
4. Move TORQUE to C++.
As part of an ongoing effort to replaced custom functions with industry-standard libraries, TORQUE already adopted the libxml package. By moving to C++, more best-of-breed building blocks and techniques will be added to our toolkit. We expect this to involve little if any disruption of the code; initially we’ll just be changing a handful of compiler switches. But over time, this investment should pay off handsomely.
There’s plenty more to say–but I’ll save it for follow-up posts.