You are making a case for Domain Specific Languages here, certainly given the example. Have you looked into those, as opposed to GPLs?

Drop me a line, I see some things that we might have some interesting dicussions on. I'm working on smart(er) factories, but a smart city is also interesting to look at.

In the past ‘few’ years, everybody has been building so-called dashboards. Be it in the form of web applications, database reports or graphs created in Excel sheets, dashboards showing the progress of key performance indicators (KPIs) have been created in every organization. In factories, people keep track of production quantities, wasted materials, unscheduled downtime, utilization of key equipment and many more data items, over shorter or longer periods.

Based on these KPIs, management decides on what should change in the factory. This often means that a deep dive is required into what’s actually going on. So, to help improve factories…

In software engineering, and specifically in software architecture, we spend a lot of time talking about patterns, architectural styles and other rules and guidelines. Over the past 25 years, and before, a lot of books and articles have been written about those, covering all aspects of software engineering. All of this is very useful, but it can also be overwhelming and sometimes appear quite complex. That’s why every once in a while, I enjoy going back to very basic principles. Basic, as in simple, effective, and often so obvious that they often get overlooked.

Recently, during discussions of the sofware…

This is the second article in a series that covers the contents of a training I developed (and taught) for over 7 years now. The training covers software design, using the Domain Driven Design approach as it’s basis.

On processes, methods and methodologies

As every experienced software professional knows, every organisation, be it a multi national, a startup, a small business, or even an open source project, has its own way of working. Often you find a mix of methodologies and best practises that has developed over time into something specific for the organisation.

What those exact mixes are is…

This is the first article in a series that covers the contents of a training I developed (and taught) for over 7 years now. The training covers software design, using the Domain Driven Design approach as it’s basis. Why I chose Domain Driven Design is explained in a seperate article.

At the start of this first article of the series, I have to thank Ewald de Bruijn and Peter Schipperen who have provided a lot of help in developing and teeaching this material over the past 7+ years.

An example

So, what are we talking about when we talk about software design…

Last week in the comments of a LinkedIn post, I had a brief exchange with Ger Schoeber about the usefulness (or absence thereof) of the current efforts to build a Corona app in The Netherlands.

I had a vague idea of writing down how I thought a Corona app could or should work, but I know too little about the workings of smartphones and Bluetooth (the core of every solution attempt it seems) to do that on short notice.

However, I can say something from a system architecture perspective, based on what I learned the past 25 years by working…

This weekend I had a nice chat with an old coach and colleague. We were talking about doing new things, finding new ventures and using online possibilities of advertising yourself.

One of the things we discussed was related to a request I got very recently: Can you provide our software engineers with a workshop on ‘creating a helicopter view’. Apparently, another ex-colleague of the two of us had told one of his customers that I have the ability to create a helicopter view very quickly, and create a mental picture of a new project, organisation or situation very quickly. Actually…