To summarize my answer: this is a frame challenge. Rather than learn how to reduce arbitrary line count, it’s much better to simply not focus on line count, but only on readability and the restrictively scoped responsibilities that a microservice should represent.
Is it possible to write very short production-ready programs?
If you open up your question to such a generalization, the answer is immediately yes.
static void Main(string() args)
That’s production ready.
Obviously, how quickly you can develop something to be production-ready very much depends on the complexity of the requirements. Displaying a hard-coded string message is arguably the lowest form of complexity, hence why we tend to use it as the default example.
Fred George, the father of micro-services suggests between 50 and 100 lines of code.
This could be done by “writing code” or “configuring tools” which both increase the number of SLOC.
Apples and oranges. I very much doubt that Fred George is talking about SLOC, but rather LOC (i.e. ignoring the complexity of any libraries used by the microservice.
Given the commonly agreed upon workload of a microservice (e.g. a simple REST API to fetch database entries), if you count all lines of source code including the library dependencies, you are in no way going to be able to write an application in under 100 lines.
my simplest meaningful programs which saw production were about 200 SLOC and were exceptionally simple. They only focused on one specific task and served as a tool for other programs to use.
Initially, this was the intention of microservices. It arguably still is, but we’ve slightly relaxed the constraints on how micro a microservice needs to be.
This is a matter of real world compromise. It may be elegant to keep your microservices incredibly tiny, but in reality a lot of companies are going to stop shrinking their microservices at an earlier stage, leading to slightly bigger microservices being built.
Have you ever seen a picture of a concept car? They are wild, mindblowingly innovative, have funky shapes, and make a very clear artistic statement. But the cars that get built from that concept are much plainer looking.
This is because the theoretical concept can explore wildly different things, but actual cars still have to deal with compromises, such as ride comfort, trunk space, back seat, road legality, …
The same happens for any theory before it is put into practice. Theories can be radical, but their implementation generally dulls them down to make it easier to implement.
Fred George drew a very radical line on how strongly we should minimize microservices, but that doesn’t really work well for a lot of companies whose codebase is, let’s face it, bulkier than any theoretical example tends to be. Therefore, compromises have to be made, and in this case this means allowing for a larger line count, while still respecting the original intention of microservices (i.e. a strongly restricted scope of responsibility per microservice)
two week bootcamp (which involved writing a relatively sophisticated application in just 22 lines of ruby)
I don’t know the specific exercise or its source code, but it does seem valid to put a very big asterisk here, based on how you’ve based your question:
More often than not, line count is the opponent of readability. The fewer lines there are in an application, while retaining the same features), the denser the features are spread across those lines. That’s just simple logic. If you’re carrying 20 eggs, the more baskets you have, the less eggs there are in each basket.
“a relatively sophisticated application in just 22 lines” raises a red flag for me. Sophisticated tends to mean complex (i.e. involving many bits and bobs, not necessarily difficult), which tends to warrant an increased line count to keep things readable.
Like I said, I can’t judge this particular example since I don’t know exactly how complex it is. But your question seems to tie together the concepts of counting lines, being production-ready, and good practice development.
In every common sense scenario, line count should simply not be observed. By common sense, I mean to exclude cases where you’re just willfully generating more code without adding further value, e.g. FizzBuzz Enterprise Edition is a great (though intentionally satirical) example of this.
What seems to be much more relevant, is the responsibility of the microservice, i.e. exactly the service that it provides to outside consumers. This responsibility should be kept to a logical minimum.
What is a logical minimum? Well, that’s arguable. Does a query to fetch all users and a query to fetch a specific user really represent the same responsibility?
Reading Fred George’s opinion on microservices, I cannot help but infer that he would attempt to separate the two as they service a subtly different purpose. However, in commonly agreed upon good practice, it’s well reasonable to have a “user microservice” which allows querying the users in multiple ways, including the two queries I mentioned before.
Am I missing some programming techniques? Could I see example programs which were used in production environment and are less than 100 SLOC?
Any technique that would reduce line count for any application, no matter the context or scope of responsibility, is effectively going to be an exercise in reducing readability.
When applied to such an extent, you effectively set code golf standards. I’m linking to the code golf community to give you an idea on both (a) how much one could actually decrease line/character count if they wanted to and (b) how dramatically it impact the readability and maintainability of the golfed code.
Your question is so broad that it is effectively no longer meaningfully answerable. You’re asking for a LOC-panacea. If it were to exist, and it would somehow be a good idea to do so, then we would all be doing it already.
This is a frame challenge. Rather than learn how to reduce arbitrary line count, it’s much better to simply not focus on line count, but only on readability and the restrictively scoped responsibilities that a microservice should represent.