Design note: software development versus solution deployment
This note goes with Web Services in EK9. It is an aside from EK9 and web services: a more general observation, which you may or may not agree with.
A bit of history
There was a time when a software developer understood the full end-to-end processing of an application: the physical hardware, the networking, even where on the disks the database was installed, and how fast those disks were. As each area became more specialised, software development fragmented (front-end, back-end, DBA, DBD, network engineer, security specialist), with an Enterprise Architect to draw it all together. That is not meant to offend, and your experience may be very different, but you can see the point.
As a pure software developer (coder) today, you may not even know about caching proxies like squid. When 'your' application has a performance problem, you decide it needs more hardware, more CPUs, or more memory for the database. Maybe it needs re-designing. Maybe the DBD needs to look at the database design and 'do some magic'.
The experts
If you work for an organisation (rather than starting out on your own), you will find 'characters', a 'pecking order', or a history with particular technologies or vendors: techie politics, or plain office politics. In my experience, organisations are often dysfunctional, have distorted views, are technologically out of balance and are mismanaged. You still have to develop software in that environment if you want to be paid; let's be honest that this is what it is like.
Applications in a wider deployment context
Why raise it here? Because web services leave the safe realm of coding, where we argue about indentation and the merits of 'for loops'. Now the software fits into a wider solution. Its function, performance and reliability start to show, and they are visible to more than the developers who wrote it (with the appropriate indentation, after much debate).
To an expert with a hammer, everything looks like a nail:
- the DBD: 'your database needs views layering on it'
- the Unix/Linux/Windows guru: 'you need OS version X with hyper something or other'
- the Java/Spring master: 'Spring Boot will solve your problems'
- the Docker and Kubernetes specialists, who will build you a home-crafted, lumpy 'EJB' container (maybe that is a bit harsh)
- the front-end developers: 'we need to reinvent the UI framework wheel again'
Each of those experts may or may not have a point, and what they offer may or may not be of value. The politics is the problem: it is very hard to get people to be objective about the issues and accept that their solution might not apply. Depending on force of character, technological history or poor management, certain solutions get promoted over what might be the most appropriate one. See this article about the schisms inside organisations.
In general, the most robust, reliable and cost-effective software is software that does not get written. That is probably not what you want to hear, and as the developer of a new language it is not what I want to say. But I have to be honest, even if it means writing no new code in a new language.
Development
Even when developing the EK9 compiler, I try to follow these ideas:
- Write an expected output for each input (TDD).
- Write very clear code.
- Write as little code as possible.
- Avoid calling that code as much as possible.
- Go back to first principles when you have any sort of issue.
- Ask the un-askable questions.
- Be honest, especially with yourself.
- Accept that you will make mistakes and not always follow the above (as will others); be kind to yourself and others.
Now back to something techie, and our heads back in the sand of interesting technology. That is honestly what you and I both wanted at this point. The web services page carries on from here with caching, cold caches, why 'devops' means something, and why EK9 draws the HTTP protocol out rather than hiding it.