This living document is a catalogue of other documents and explanations of their gaps in logic. The conclusion of these other documents could be valid, however that is by luck, not because the author(s) are using sound logic. This document will be updated as new ones are discovered.
This document is the output of multiple individuals. Their thoughts and ideas have been collected and combined.
The lesson here is threefold. First, the Big Rewrite is almost a sure-fire way to ensure a project fails. Avoid that temptation. Don’t look into the light. It looks nice, it may even feel nice. Statistically speaking, it’s not nice when you get to the other side of it.
The second lesson is that making something microservices out of the gate is a terrible idea. Microservices architectures are not planned. They are an evolutionary result, not a fully anticipated feature.
Finally, don’t “design for the future”. The future hasn’t happened yet. Nobody knows how it’s going to turn out. The future is going to happen, and you can either adapt to it as it happens in the Now or fail to. Don’t make things overly modular, that leads to insane things like dynamically linking parts of an application over HTTP.
The author describes a system that got rewritten and the results didn't work out, then proceeds to generalize lessons. But the article doesn't support the conclusions. Is the Big Rewrite a sure-fire way a project fails? Maybe, but the article doesn't provide anything beyond a single example. In fact, in the given example the rewrite makes it all the way to accepting requests from customers. When they describe what went wrong:
We set it up, set a trigger for a task, and it worked in testing. After a while of it consistently doing that with the continuous functional testing tooling, we told product it was okay to have a VERY LIMITED set of customers have at it.
That was a mistake. It fell apart the second customers touched it. We struggled to understand why…
And after a week of solid debugging (including making deals with other teams, satan, jesus and the pope to try and understand it), we had made no progress.
But performing better testing is not in the "lessons learned". Nor is making a system that can be debugged. It seems quite odd that a new system, taking very little traffic, would be so hard to debug. That seems independent of any Big Rewrite.
The second lesson is about developing as microservices. Whether or not this is a good idea likely depends heavily on the surrounding organization. Is there support for developing and operating microservices quickly? Is there a institutional knowledge for doing that? If so, perhaps it is a good idea.
Finally, the final lesson is contentious in software engineering. Should one plan for the future? If so, how much? It's common enough that there is a pithy way to express not planning for the future: YAGNI (You Ain't Gunna Need It). But the article doesn't making a compelling argument for this. Again, the article makes it clear that the product was not tested sufficiently and was not debuggable.
At SoftwareMill we’ve been experimenting with different tools for 10 years already. Here are the apps that are currently being used by our teams. Let’s see whether you find something interesting for your project!
Despite the title of the article, how the tools presented translate into faster work is never described. The list of tools seem to be those that the company likes using, but no evidence is presented that they make work faster. It is certainly fine to have a preference for various tools, however that does not mean those tools make one more productive. And a tool does not need to make one more productive in order to have a preference for it.
This article contains a list of Pros and Cons about various programming languages that the author feels qualified to comment on. The end of the post is also a list of languages for which the author admits they would never consider for usage, so their inclusion in a blog post about how to choose a language makes little sense.
Disclaimer: I don’t like the rest of these programming languages and would not use them to solve any problem. If you don’t want your sacred cow gored, leave here.
The "How" in the title of the post implies some sort of process will be described but no such process is given. How does the author take a problem, this list, and then choose a language? A list of Pros and Cons about a tool, even if that list is accurate, is generally insufficient to determine if the tool is right for a job. In the list of languages the author would choose, it is not clear in which case they would use a particular language. Take C#, for example:
Pros: less boilerplate than Java, reasonably healthy package ecosystem, good access to low level tools for interop with C, async/await started here.
Cons: ecosystem is in turmoil because Microsoft cannot hold a singular vision, they became open-source too late and screwed over Mono.
Even if all of these points are accurate: how does one decide to use C# using this information?
It is impossible to determine how the languages compare to each other because there is no consistency between the Pros and Cons of each language. For example:
The author states that the best way to learn is by doing, and in this case that is likely true because this post provides little information the reader can apply.