Any substantial change to critical software should be backed by a high confidence in correctness. Testing can be difficult when working with existing software systems. Automated tests might be sparse and hard to write effectively, while manual testing practices are often error-prone and labor-intensive.
During the reverse-engineering of legacy systems, in particular, correctness can be challenging to define and components might interact in non-obvious ways. Therefore, simply “writing tests” is not as simple as it sounds.
I write a lot of Java. These days, I use Visual Studio Code. Sometimes, I see a variable but do not remember its initial value. No worries: I just put the cursor on the variable, press F12, and watch the editor navigate to the declaration. It’s called Go to Definition in Visual Studio Code. Many other IDEs have it, too, and for many other languages. It’s a very useful feature. So… Should IDEs for DSLs have Go to Definition as well?
Many legacy applications store data in binary files by using generic database systems like Microsoft Access, proprietary libraries or homegrown binary formats. All these methods have one thing in common: the data is stored in an opaque binary format that only the application can decipher.
“To a person with a hammer, every problem looks like a nail”. In other words, some people have a one-size-fits-all tool to solve everything. You might think that we’re guilty of this at Swat.engineering because we use Rascal a lot. So, are we myopic software engineers obsessed with a single language and its tools? Not at all. Here is our nuanced story.
Swat.engineering wants to help its customers deliver the right value. So we often start with a requirement analysis phase. This yields a requirement analysis report: How can we use the least amount of tools and overhead to focus on the essentials? We’ll show you how we use Google spreadsheets, Rascal, and HTML to generate interactive/traceable requirements. These requirements can not only guide a single software project but they can also be used to formulate a full project roadmap, see From Requirements to Roadmap (to be published).
Most IT systems consist of closely interacting software components (applications/tools) that solve related problems in the same domain. Many components are based on the same domain elements.
In the banking domain this would include account, client, and interest rate. In the forensics domain file format and encryption would be prominent.
Building each software component from scratch will be expensive, error-prone and maintenance-intensive.
Using domain knowledge is the solution to these problems and it forms the centerpiece of the Swat.
What to do when a legacy system becomes too expensive to maintain or to add new functionality? Rebuilding the leagcy system from scratch will be expensive, error-prone and maintenance-intensive.
Domain knowledge forms the foundation of the Swat.engineering Methodology for legacy systems:
Our first step is to deeply explore all knowledge we can collect about the system, ranging from interviews with developers to automatic analysis of source code and documentation.
When we incorprated Swat.engineering early 2017, we quickly registered the domain swat.engineering and put there some temporary information. Little did we know that “temporary” would mean 3 years.
We needed all our time to run a start up.
A few month ago a colleague in an EU project said: “Hey, Swat.engineering must be doing pretty well, since your website is never updated”. Indeed, we are doing very well as a company working on exciting projects with a range of clients.