Playing with legos is easier then delivering value.

Playing with legos is delivering value. Reinventing the same wheel over and over again is not.

What's often missed here is that the problem the lego is slotted in to is often subtly different each time. So you have a guy building an 8x2 lego brick that slots perfectly into his mansion and then someone else really needs to cut a corner off of it to fit their problem. But the original designer never gave you the option to do that so now you have to write an adapter to plug the 8x2 into an 8x2 without a corner.

It only looks like reinventing the wheel every time if you're completely ignorant of the subtle differences of each problem domain. And if you make a bunch of changes to create arbitrary lego bricks then now everyone has to learn your brick framework before they can make an 8x2 brick.

I agree. You have to know your lego blocks well and understand where they fit and where they don't. But if you choose to remain ignorant of the available lego blocks, and instead write everything from scratch every time, you're wasting a lot of effort.

> But if you choose to remain ignorant of the available lego blocks, and instead write everything from scratch every time, you're wasting a lot of effort.

That's a good seam upon which to filet this analogy. A quick Google search turns up uncertainty as to how many different bricks there are. It could be in the 3000s, 6800s, or over 12000. We are all ignorant of the available lego blocks.

I'm not entirely sure what you mean. But if we're talking about AWS cloud services, there are certainly AWS experts who know how to develop software in a cloud-native way and utilize most or all of the relevant services. That knowledge is what we are paid for. It's also true that there are a lot of AWS services available and expertise is divided into different specialty areas, like ML, IoT, etc. Hard to be expert at everything.

Agreed but that is not what is happening though ; people do both; they use legos and reinvent the wheel. Making everything, imho, worse.

The authentication thingy you got as lego block did not quite fit and now you are using more code than the module has in it to add what you need for it to do, making the original module probably impossible to upgrade without a lot of work and creating a problem for maintenance. Now you can fix this by telling your client; ok, I won’t do this because your idea of auth is wrong. But then the client might kick me out (probably not a bad plan if they are doing trivial things significantly different than the rest of the world). I can just implement it like I mentioned above and make money maintaining it (risking having also to maintain the original lib). Or I can just make a new lib and for which I know it does what it was.

Then, my favourite option, is just take something that just works already, deploy that and adapt a few people their habits around it. It fits 95%, stop whining. The least popular option ofcourse, so there we are, creating slightly different wheels with millions of almost the same LoC and unused andor unmanaged libs that should not have been written or used, again, imho.

I have different experiences. My "lego blocks" are AWS services. Each service is a black box that maintains its API backwards compatible forever. My custom stuff is built around the API and keeps working forever. ( * ) In my view AWS has been very successful in maintaining this backwards compatible model even when they often add new features to services.

There are sometimes edge cases that are not possible to implement, but they are rarer and rarer as the service portfolio grows. In those cases the only option is to write your own container and deal with the usual package-level dependency issues in whatever programming language you use.

( * ) The only thing that doesn't work forever is Node.js, which is deprecated every few years and needs to be upgraded to a new major version. I'm looking forward to the possibility of WebAssembly/Deno replacing Node.js as an "evergreen" application platform.

What are you paying though? The most common reason I get pulled in is because of exorbitant aws bills which eclipse dev bills... This sound expensive.

In the past 5 years all my projects have been based on AWS Lambda, API Gateway, S3, DynamoDB and other serverless technologies which are only billed for actual usage and network traffic. So they don't cost much unless they actually get heavy load from users.

I love how the justification of numerous AWS services is always "so it can scale" but if and when that scale ever happens, a new architecture is necessary because the costs become untenable.

I haven't seen this happen myself. In projects that I've been involved with, the justification of using serverless services has been to reduce development costs, because you don't have to setup and develop everything from scratch and spend effort maintaining the infrastructure. The ultimate goal is to avoid doing anything else than define the business logic that is unique to the project.

Is it the same wheel? It sounds like you wanted a Honda Civic, but you used the wheels from an Abrams tank. So obviously the solution is to invent a tank wheel <> Civic chassis adapter layer?

>They will aggressively defend their role which is no longer about creating software but instead entirely about weaving together a myriad of components.

Same thing is happening with mechanics. Young mechanics repairing parts less often, more handing off parts in need of minor repair to specialists and a focus on fitting parts.

Kubernetes is amazing when engineers need it.

Kubernetes sucks when managers need it.

Never underestimate the number of engineers that convince themselves they need something because it is trendy and sounds cool.