I am frequently in charge of running workshops where a group of stakeholders, often experts in their field, come together to agree on how something works or is supposed to work. This happens in the context of language design, where domain experts try to find abstractions that should go into the language to faithfully cover the domain. But it also happens when trying to decide how a particular software system should be architected in order to fulfil certain requirements. Here are some thoughts on how you should approach running such a workshop.
As a moderator, you should do two things…
This most recent post on the relationship of DSLs to other software engineering fields is motivated by a recent interactions I have had with software architects. They seemed to consider the use (or not) of DSLs more or less irrelevant to “the architecture”. It’s not the first time I have encountered this position, so I thought I’d write about it next.
First of all, there are DSLs explicitly designed to express architecture. Examples abound, they include the various Architecture Description Languages, SysML, to some degree UML, but also more domain-specific ones such as AUTOSAR or Franca.
This one is a little bit different. It is not about DSLs, but about writing. I have been writing a lot over the last couple of years — blog posts, papers, and books — and I was also involved in helping younger engineers to get a grasp of how to write well. And maybe even enjoy it a bit.
This post is a collection of best practices that I try to stick to when writing. They might not be totally obvious for people who do it less. …
Software quality is a huge field: there are lots of different aspects that could be labeled as being part of “good software”. These include
I have recently been asked (by Jurgen Vinju) why I always promote DSLs for domain experts and non-programmers, and not so much for developers. So in this post, I’ll explain my position.
Before we continue: I am not at all suggesting that developers should not use DSLs. In fact, there are many cases where it would be useful. This text is about why it is harder to convince them.
We should probably define what we mean by developer. To me, a developer is somebody whose main skill is software engineering (or development or craftsmanship, if you prefer those terms). They…
Modern optical astronomy relies on huge telescopes such as the LBT or the VLT , because the light gathering power and resolution of a telescope are more or less directly related to the diameter of the mirror. To ensure image quality and avoid optical aberrations, the surface of these mirrors has to be very precisely ground and polished, down to the scale of micrometers. In addition, this precisely-shaped surface may not be bent or otherwise distorted by temperature effects. So the material from which these mirrors are made is hugely important. …
Exactly one year ago, on June 7, 2019, I flew in the backseat of an F-16 of the US Air Force Thunderbirds air demonstration team. I got the opportunity because my omega tau podcast fits well with the Thunderbirds’ STEM outreach activities.
I have been in love with the F-16 since I was a child, so this flight was a really big deal for me. June 7 last year really wants the best day of my life until then, and, as I speculated in the podcast episode, it might also be the best day
going forward.
Domain specific languages are a very particular approach to tackle a problem, and for many people it is unclear what a DSL would do for them. To make this clearer, I have decided to write a few posts that relate DSLs to various approaches known in computer science and IT. I start in this post with knowledge management.
What is knowledge, from the perspective of an organization? Here’s how I would define it. The world is full of information, data and stories about almost every imaginable domain. But if a company wants to develop software in that domain, they have…
The most important consideration is this: you should only develop custom tools and languages for that part of your software that is unique to your business, that drives your unique position in the market. It is crucial that your tools are as effective as they can be for this part of your software. Everything else should be treated as commodities, and you should rely on off-the-shelf tools and frameworks. To make this concrete: if you are not Amazon or Netflix, then computing infrastructure, deployment tools and databases are not something you want to develop specifically for company. …
IDEs with colored code, error checking and refactoring. Unit test frameworks. Automatic execution of tests in the IDE. Automation of builds. Automatic downloading of libraries and frameworks. Version control systems. CI servers that build, test and package for every commit. Automatic deployment to staging servers. Automatic a/b deployment and testing. Platforms that scale up and out indefinitely. Container Frameworks. Software-as-a-Service and Platform-as-a-Service infrastructures with Web UIs. Infrastructure as code. Man, those developers really worked hard to simplify their world.
Congratulations!
Really!
Once my idea of what a software system should do has made into their brains, and once they have…
software (language) engineer, science & engineering podcaster, cross-country glider pilot. On medium mostly for the software stuff.