Unfortunately there are a lot of people around these parts who have arrived at the conclusion that the only way to build software today is using all those services and more (I mean, where's kubernetes in that stack?). They will aggressively defend their role which is no longer about creating software but instead entirely about weaving together a myriad of components.

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.

I'm so tired of React being thrown into every single web stack as of late. You don't need some large React boilerplate mess, that could've been done with some simple PHP+Jquery stack. It's caused this SPA nightmare also, where you have a large delay in page loading, when it's a site with basic functionality.

> Not to mention that those CRUD apps have been done, exactly the same, 10000s of times before and 10000s of people are doing the same work you are doing now at this moment.

And yet now OP is making wood furniture, which has been made before the same thousands of times. Some people need originality some don't. Some just like the work for its-own sake. For those who need originality they should find a job working on something that's not a CRUD app. Not everything is a CRUD app. That's on them.

Sure that is true, but then again I have written many of employee directories, cms’s, erps, social networks, running apps, banking fronts and backends, insurance fronts and backends which were all exactly the same except forced in a different tech because of the taste du-jour. We wrote a massive insurance monolith system in c# and my new client wants it microservice and in TS/node. We will be doing exactly the same as 2 years ago and make a boatload of money while we have a working and tested solution. Almost all of this is CRUD with some calc sheets in excel which we did in the 80s, 90s, 00s and again now. The functionality is completely the same; even the screens have the same ux; ui is a bit updated. But the MS foxpro version was fine almost 30 years ago. Not my money though so what can I do.

Not sure how it fits wood furniture; you cannot copy a chair in a nanosecond; you can software. I am not saying there is no space or need for bespoke and unique software but if you are doing LoB apps for/in a big corp, as many of us do daily, chances are there is a) a perfectly fine version already running in your corp somewhere and b) a completely identical product in all the companies around the block.

> chances are there is a) a perfectly fine version already running in your corp somewhere

You and I have very different experience with big corps :)

My experience is closer to "There's a half-finished version running somewhere that was cut short because of budget/deadline constraints. The team that worked on it is long gone, and it has been maintained by an outsourced team of junior resources for 3 years".

Re-writing a customer-facing system to be closer to the "modern" web experience they're used to on their everyday apps and sites _can_ make a substantial difference to customer experience, and ultimately the bottom line.

> Not to mention that those CRUD apps have been done, exactly the same, 10000s of times before and 10000s of people are doing the same work you are doing now at this moment.

I recently worked for an org that had quite a large software suite (internal system) that was 99% CRUD. For every single CRUD operation, there was a front-end call, to a back-end service, that called a specific stored procedure. So pretty much 4 stored procedures for any construct stored in the database. No ORM, very little dynamic building of queries, thousands of database tables. Releases were a nightmare, change management for database objects is its own complexity, especially with so many objects. I think people were open to change, but with a decade of existing data structures+data, and a long list of projects, nobody wanted to make a change...

My one regret, with respect to that org, is not driving the necessary change.

The recent (modern startup, hip and happening and VC invested company) I built a CRUD frontend for has a lovely system: mysql but the db is not relational: 1000s of tables matching the Objects in their OO code. I have so many scripts and generators and, especially for mysql, introspection tools it was not that much work but what a horror show.

> The level of reuse is depressing and people, especially here, firmly believe we need to use the latest frontend and backend crap to rebuild what was working perfectly fine before.

This seems overly cynical to me; the reason software developers are well-paid (overpaid, some would argue) is that what they build is measurably better that what was there before (at least in dollar terms. I'm not getting into the moral quagmire of automation replacing human jobs ATM)

Code reuse is often a red herring, when taken to extremes. Here's a thought experiment: all software developers are now required to implement all CRUD software in SAP or Peoplesoft (pick one). How much of the code do you think will be re-used, and how much will be in the customizations?

$50K is kind of cheap actually. I've seen people pay $200K and more for basic CRUD websites with a little extra this or that.

In fairness, if your web app does more than CRUD, or if you expect it will in the future, then PHP and jQuery wouldn't be my first choice. I'm very familiar with how much of a mess an app can become when pursued that way -- a nasty soup of callbacks and conflicting states. As tooling around React improves -- and it's already quite good -- it will be easier to cost-effectively write a React CRUD site.

If you just want a CRUD site that works, and you want it fast, a Rails site with scaffolding will probably give that to you in an hour or two -- with almost the whole hour being spent thinking about your data model.