Low-Code, No-Code, AI-Code… Coding without Coders?

Posted on 31-10-2023 by Bert Laverman

Low-code and no-code have been with us since the nineteen fifties, trying to make programming easy and turn business users into “citizen developers.” Code generation using AIs is taking this approach even further, promising to reduce the formality of the “input” to a human conversational level. So, if we accept this starting date for the long run towards the development of AI coding bots, how come we all laughed when Scotty tried to talk to a Macintosh? Even stronger: Why do we get fresh announcements of high-productivity coding environments every few years, promising that finally, this time for real, we don’t need expensive programmers anymore to build our business applications? And why does each iteration then slowly disappear toward the toolboxes of those same developers, if not being replaced altogether with something else?

TLDR

  • Trying to replace developers with business users is a goal that has been with us ever since computers became widely available for business use. Programmer scarceness and productivity have always been the driving force behind “low-code” and “no-code” products.
  • Generally, Low-code and No-code solutions provide fast first-time delivery, at the cost of long-term maintenance and vendor lock-in.
  • Software development is a skill that can only partially be captured using automation. Therefore, all code-generating solutions, including generative AI, realize their optimum potential when applied as tools for developers.
Continue reading →
Posted in Programming Languages, Software Engineering, Tools | Tagged , , , | Leave a comment

Wait, what? Microservices are dead?

Posted on 02-09-2023 by Bert Laverman

If you happened to visit JCON Europe 2023 or follow me on LinkedIn, you may have seen that I presented there using the title “Is it time already? Microservices are dead; long live Microservices!” I know, I know, this kind of title might feel a bit overused, but it expressed what I wanted to convey: Just like Uncle Dave’s “Agile is dead, long live Agile!” we have succumbed to the “tooling approach.” With Agile this resulted in an explosion of Agile methodologies, sometimes even using “project methodology” as a classification, while the whole idea was to put individuals and interactions over processes and tools. However, “doing Agile” does not make you agile!

The same has been happening to microservices, where people are wondering if they should “use microservices” or even “migrate to a microservices architecture.” This is entirely a form of putting the cart before the horse, which can trip you up if you haven’t got the organization to survive this. I’ve already talked about this several times, but wanted to stress this aspect in a different way: If you are properly Agile, and that definitely goes beyond just IT, you will find that striving for small deployable components is a consequence of striving for “Business Agility.” Lean Software Development, DevOps, and the Agile way of working will all help you reduce the time between “Ideation” and “Production.” Somewhere along the line, however, you may find that the size of your application, or its internal structure for that matter, becomes a limitation! Build times, testing, and deployment complexity all battle for attention, and the only way you can successfully conquer them is with smaller component sizes, less coupling between components, and more automation.

I’ll make sure to post the link to the recording of the talk in Cologne when it becomes available!

Posted in Microservices, Software Architecture | Tagged , , , | Leave a comment

Life on the Edge

Posted on 21-05-2018 by Bert Laverman

“But even more important,” he said, “is the way complex systems seem to
strike a balance between the need for order and the imperative to change.
Complex systems tend to locate themselves at a place we call ‘the edge of chaos.'”
Ian Malcolm at the Santa Fe Institute

 

If you’ve been following the announcements surrounding the Java platform, you may have noticed something peculiar happening with the latest Java SE versions. Hardly has the ink dried on books describing the Java 9 release, and we’re already on Java 10. Even more unusual: if you go to Oracle’s Java downloads, you’ll find sections on Java 10 and Java 8, but 9 is gone already, and that in only half a year! The obvious reason for this is Oracle’s new release cadence, where so-called “Long-Term-Release” versions will still use the 3-year cadence, but between these LTS versions Oracle has moved to a 6-month cadence. The reasoning: “developers prefer rapid innovation”. While on the whole Oracle had been getting a lot of flak for it’s slow pace, the combination of a faster pace with rapid removal of older versions will come as a shock for many.

If you compare this with what has happened in the world of Browsers, then it shouldn’t come as a big surprise, because there we see that “big” release numbers have already vanished into oblivion. Who still remembers the toils of “IE fill-in-your-favorite-number” compatibility, especially when catering to slow-changing corporations? Nowadays browser version numbers are hardly ever mentioned, and they range from 17 for Microsoft Edge to 66 for Google Chrome. Sites like “Can I use?” (https://caniuse.com/) provide detailed analyses of the different versions and how well they support HTML, CSS, and other standards, and specialized JavaScript libraries dynamically add support for missing bits.

So is this increased pace really a Good Thing™, simply a natural and inevitable evolution, or is Gartner finally right with its continuing predictions of doom for the Java platform?

Continue reading →

Posted in Agile, Microservices, Programming Languages, Software Architecture | Leave a comment

Agile Architecture, or When not “to Architect”

Posted on 30-03-2018 by Bert Laverman

The sword in the scabbard is a price beyond compare.
Jerome, the first Wayfarer.

Agile Architecture is an interesting subject from a people point of view, especially when funny movies are circulated about a house-building team embracing “Agile”. The movie shows how the team starts constructing happily, but stops somewhere halfway after finishing the ground floor, because other priorities pop up. The point raised is ostensibly that some things simply don’t fit with a agile way of working, comparable to a manager stating “I don’t need to be Agile; I know what I want! Just build it already!” Naturally, when the poster of the movie is cornered about his or her opinions on Agile Software Development, the reply invariably goes towards the comedy value of the content rather than the point it appears to make. So far however, I have yet to find someone making the correct observation that this team lacked a sense of their customer, and probably a Product Owner. As Dave Thomas argued in his presentation “Agile is dead” at GOTO 2015, agility is about taking small steps towards your goal, and after every step evaluating what it did for you. Being able to change direction after every step is what makes you agile, not whether you actually do change direction.

When I read Robert C. Martin’s book “Clean Architecture”, I was intrigued by a chapter called “Details”, which started with “The Database is a Detail”. It discusses the application of agile architecture, and not over-architecting when a simple solution will do. The point is that even the choice of your database technology is a detail which might not be important enough to solve up-front. If, like me, you work in a large organization which values the selection of a standardized Relational Database, that approach can be quite a challenge.

Continue reading →

Posted in Agile, Software Architecture | Leave a comment

Closing the Knowledge Gap

Posted on 11-02-2018 by Bert Laverman

If they were handing out Lamborghini’s for free, let’s say the Aventador, would you take one? I know that for myself, this would be a bit of a poser. I’ve seen enough lotteries where you could win dreamcars, but in the back of my head I would always admit that I would probably put it up for sale. Let’s be really honest here; I definitely would like to take it for a drive, but I don’t have any sports-driving skills, it’s way to big for most parking spots, and having to cross the 5 speedbumps in my neighbourhood just to get home would completely trash the spoilers. But the real long-term killer is the required budget for upkeep; maintenance costs alone would kill any chance of a decent holiday for the family. Even if we stretch reality a bit further and include free spare parts, you need specialized tools and knowledge, and you need the room to house it properly. In the Netherlands that last bit can be a real killer.

That all said, if I’m planning to do a lot of miles, nobody can deny that a Lamborghini can really take care of that! But the thing that really jumps into my mind about them is mr Clarkson of Top Gear fame, who enthasiastically explains how you can actually switch off most “protection” to get the best performance, and end up with a car that feels like it is actively trying to kill you. A bit dramatized, I admit, but he was definitely on edge about his personal safety in that car, while pushing it to its limits.

Now read on as I try to revert back to software and applications, while maintaining relevance to the Lamborghini introduction.

Continue reading →

Posted in Microservices, Software Architecture, Software Engineering, Tools | Leave a comment

Turning your application on its head

Posted on 03-02-2018 by Bert Laverman

If nothing what you do wil do, then what do you do?
Hisamatsu Shin’ichi (1889-1980)

So I’ve started by telling you that the Way of the Microservice has to do with quality, that this aspect is more important than the obvious aspects of size and deployment, and that trying to be like Netflix is likely to trip you up if you don’t get the quality bit right. Even Gartner, that ultimate fond of business wisdom, warns its customers that “You are not Netflix.” Bummer. So, why are we even going this path? I mean, apart from the lofty goal of delivering high-quality software, which I hope you’re not against. It’s most likely this nagging feeling that you want affordable quality, not quality at any cost.

An important thing you’re going to get from using a microservices architecture, and totally worth the (apperent) trouble, is increased autonomy. If your “application” is built as a group of cooperating small processes, and they adhere to those principles of loose coupling and high cohesion, you gain a lot of flexibility. Since the components are small, making sure they are secure and fault-tolerant is also a lot easier. Luckily there is a fairly simple trick to help you achieve the increased independence: stop building applications that move data around, but model the flow of data first, and let your microservices process or produce them: Implement a Data-Driven Architecture.

Continue reading →

Posted in Microservices, Software Architecture | Leave a comment

XML still not fit for human consumption, and neither is YAML

Posted on 15-01-2018 by Bert Laverman

A while back I wrote about XML (The Problem with XML), arguing that it is essentially great for computers, but definitely less so for humans. Since then, XML’s popularity in the enterprise world hasn’t really diminished that much, although we do have a strong competitor in JSON (the JavaScript Object Notation) for REST calls over the public Internet. But wait, more is happening! Binary is BACK thanks to our friends at Google, who argued that, within the confines of the (corporate) local network, binary is pretty acceptable, and way more compact and thus efficient. They named their baby “protobuf” for Protocol Buffers. Duh! Who’d have thought that? I mean, apart from any young upcoming developer… and most older ones as well. Even then, admitting I haven’t looked at the underlying encoding of the bits and bytes, didn’t we already have something like that with CORBA? Or ASN.1?

However, setting the bitching about re-inventing the wheel aside, there is a new contender for human non-consumption these days. It fits in nicely with the new name of my site, being used by tools such as Docker and Kubernetes, and its name is YAML, for “Yet Another Meta-Language”… Oh no! “YAML ain’t Meta Language“? Ye gods, yet another recursive name! (YARN) Yet another human-readable data serialization language, (YAHRDS) and this one is a doozy! Like our favourites of lots of years ago it uses whitespace to denote structure: start a line of text with more spaces then the last, and you are apparently detailing whatever was in the last line. Worse: if you want the detail to stop, just start the line with the same amount of whitespace as the level you want to return to. So if there are a lot of lines with details, you have to hunt upwards with a ruler to find out how many levels were just “closed”. YUC! (You Unintentionally Cringe)

Posted in Uncategorized | Leave a comment

Happy New Year!

Posted on 15-01-2018 by Bert Laverman

‘scuse me for the late well-wishing, but there you go! 🙂 I’ve been busy with helping my eldest move to her first student-apartment-room-thingy. Next I started redecorating her ‘old’ room for use by the undersigned. Takes a bit longer than planned, but I can almost start flying virtually again.

Posted in Uncategorized | Leave a comment

Why are Microservices so hard?

Posted on 04-12-2017 by Bert Laverman

If a microservice in the cloud stops responding,
and no logs were generated,
did it fail at all?

Suppose I have two applications, one a “classical” monolith, called so even though it was built using a multi-tiered architecture, the other using a microservices architecture. Furthermore, lets keep it simple and assume the functional requirements were the same, so they both provide the same functionality to the organisation and users. What can we say about how difficult they are to build and run? How do they compare? Why would I prefer the one over the other?

The monolith looks like the easy winner in build effort if I were starting from scratch, having the advantage of a simple infrastructure and application design. Hokay, now let’s add in a sense of reality: I have performance requirements, splitting the users in internal (employees), external (customers), and IT staff. (“keep everything running”) So the infrastructure needs a bit more thought; probably a separate database server and web-application server. Maybe a separate web-application server for the internal users, so their work won’t inconvenience the customers and vice-versa, and a common back-office system to tie it all together. Security is a thing as well, so set up a secure directory server to manage accounts, a DMZ around the front-end to secure the back-end further, some DDOS protection, you know the drill.

We’re hitting all the important points, so let’s take a look at the alternative: We take an account at one of the major cloud providers, select the appropriate lego-blocks from the catalogue, and start filling it with components. Funny thing is, this sounds easier, because we don’t have a lot of the infrastructure hassles.

Fast forward to the working application and we’re ready to throw a wrench into the system. Monkey wrench? Yeah, a Chaos Monkey wrench. Customers start calling that the site isn’t working. Now what?

Continue reading →

Posted in Uncategorized | Leave a comment

So what is a Microservice?

Posted on 23-11-2017 by Bert Laverman

A developer presented a new module, saying: “If you call this a microservice,
you oppose its reality. If you do not call it a microservice, you ignore a fact.
Now what do you wish to call it?”

Microservices are in full swing towards the “Trough of disillusionment”. Practically everyone has heard about them, and we have famous “poster children”, with Netflix probably as the most used example. Many are trying for it, and lots have failed or are coping with problems following their introduction. Interestingly though, there is no authoritative definition of what a “microservice” actually entails, mainly because that would imply you have a clear target to shoot for, and the failures show the target isn’t clear at all.

Continue reading →

Posted in Agile, Microservices, Software Architecture | Leave a comment