That's completely true, but it's also not what I said. There is a difference between being able to work with a paradigm (which will take time, albeit not 10 years) and being able to write a proper critique of it. More so, if you wnat to do that in the way it was done in this article, you will need some time to get acquainted with other paradigms as well, or any comparison you make are mood points.
Seems we live in an era where it's more important to bash paradigms and technologies as soon as possible, rather than trying to understand them and put them to proper use.
My point is that whatever language you use, we are almost always learning some language, it is just expressed in a different form. Go is in this case expressing another language. It just happens to be expressed in verbose Go syntax.
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.
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.
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…
The text below is a piece that I wrote in 2009, and it’s still relevant. However, I am not sure if I still agree with my own conclusions from back then. What do you think?
Who hasn’t heard stories about managers who don’t have a clue what their engineers, architects or quality officers are trying to achieve? And who has tried to go over their manager’s head to try and fix the problem that way? Out of frustration, or to strenghten their own position? …