jonathan@researchcomputingteams.org
Parent categories: Technical Leadership
Other tags: | Technical Leadership: Software Development |
Avoid Rewriting a Legacy System from Scratch by Strangling It - Nicolas Carlo Because the value of the code is what was learned from writing it rather than the code itself, when it comes time to grow from earlier maturity stages to the next, the recommendation for from other sectors is to migrate away from the earlier code, not to refactor a proof of concept until somehow becomes production quality. (See also Keavy McMinn’s recommendation to throw away code from a proof-of-concept “spike” in her...
Continue...Other tags: | Technical Leadership: Software Development |
The key points of “Working Effectively with Legacy Code” - Nicholas Carlo Exit the Haunted Forest - John Millikan An awful lot of of code we work with in research computing can be thought of as legacy code - whether it’s functioning but old code that to meet current needs needs to be refactored, or whether it’s new code from a researcher which just isn’t maintainable in its current form. I like to think of reworking such code as helping the code reach its potential....
Continue...Other tags: | Technical Leadership: Software Development | Technical Leadership: Case study |
Migrating large codebases to C++ Modules - Takahashi, Shadura, & Vassilev C++ Modules in ROOT and Beyond - Vassilev, Lange, Muzzafar, Rodozov, Shadura, & Penev C++20 is finally coming. There are five major new features - Contracts (preconditions/postconditions/assertions - which I think are potentially extremely interesting for research computing), Co-routines, Concepts, Ranges, and Modules. Modules are probably the biggest change to the language. Ever since C, the approach that’s been taken for modularization of C/C++ code is C-preprocessor style include statements. These are hard to...
Continue...