I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument.

It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in. I use the database for what it was made for, and only what it was made for: to persist and retrieve data. Anything else should be in the code.

Also, key/value schemas are terrible and slow, but sometimes they're the only way to get the dynamic nature of what you are doing. The best compromise I've seen of that is to have the values you know are going to be used a lot by groups/customers flat, then have the key/value schema for anything oddball.

I guess the moral of the story is old/young doesn't really matter. It's know / don't know what you are doing. I guess it boils down to thinking about what you are doing. Key value is very dynamic but I'll bet it's slow. Do we need fast more than dynamic? Is there a compromise that will satisfy both requirements? Many people don't think that deeply and just want to get it finished.

When I was young, the dot bomb was the "great filter." After that, there were a lot more people who knew what they were doing because they survived. It sucked though, I don't recommend it.

> It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in.

If i recall correctly, back in the dark ages of Classic ASP and SQL Server 6.5, database stored procedures was the only feasible way of implementing a reasonably performing web application.

Back in SQL 6.5 days (and all the MS SQL versions up to, i believe, 2005), "precompiling" queries in stored procedures was recommended for performance reasons. It was even asked on hiring interviews, at least to me.

Oh I wasn't saying it was -- just providing examples for when the hand-waving/dismissive attitude by senior developers isn't really backed by anything. I'm pretty skeptical of 'because I said so' answers nowadays (by both young and old devs).

>then have the key/value schema for anything oddball

Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)

My mentor was a huge arguer, that's probably where I got it from. He'd start talking louder and spittle would come out at me and everything. It was ugly, but I got used to it. We'd go at it for hours, but we both knew when we came up with the right decision and were receptive to it. I like to think I'm quite a bit more tactful than he is though.

>Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)

Oh god, I suffer over schema design decisions more than I should, but sometimes, relational just doesn't fit what I'm doing. What's really helped is I got stuck doing reports for a huge schema my 2nd two years and I really saw what crappy design could do to performance. My favorite is when a schema has missing foreign keys on 80% of the tables. It's like they discovered foreign keys 3/4 of the way through the project and didn't bother to retrofit them.

And I have been steamrolled in discussions with 20-somethings as well. "Don't worry, I'll always give you enough time to refactor the tree shaking caused by this design," from a first-time manager is probably my favorite, followed by "this must be re-written, there's no way to salvage it in-place."

They went from consistent if slow progress in defusing the landmines in the old backend to eight months of re-writing everything (frontend included since the data model was also changed) and trying to claw their way back to parity.

Bad programmers will be bad programmers, regardless of age. At least age will put a polish on average developers, letting them work above their raw potential simply because of "I've seen this before; here's how it was solved".

We tend to be fairly agile with regard to new technologies, and much of that is driven by the architects. A few of the young folks will recommend bleeding edge platforms/libraries/techniques. Some of this stuff has been accepted, some of it hasn't. It is almost always filtered through the lens of experience ("what happened when we tried to introduce x? ").

Experience counts, primarily because one group has been burned in the past by accepting recommendations from just-out-of-college engineers. That's not to say the younger devs don't know anything, but they have precious little experience shipping actual product.

(We work in the medical domain, so "move fast and break things" doesn't work so well in a highly-regulated industry).

On the other hand, our senior build engineer is more, uh, established in his ways, and we are currently stuck on an antiquated version control system. This particular engineer also wields quite a bit of influence to the larger company, so his way tends to be the way we go (unfortunately).

At the end of the day, I think you find stuck-in-their-old-way folks in an industry. This is not at all unique to software engineering.

I remember when this was the thing to do; to store as much as possible in stored procs. Fat server (the server here being the database server), thin client.

That has changed, and changed again, and no doubt it will be different in the future again. The problem with our profession is that it isn't always easy to determine which changes are actual progress, and which are a fad or fashion.

(Anecdotally: I also remember having to replace ~100 lines of Python with ~60 stored procs and views in Access. This was code that was very unsuitable to be done in a database. The Python code did the job fast, and was readable and understandable; the Access queries were NOT, and it took them minutes to do the same thing. But, management considered Python "unmaintainable" because it was "an obscure language"... so they preferred the Access "solution".)

If they like git and know it well, they're probably old, full of the experience and benefits you're looking for, _and_ energetic, growing and open-minded.

(I said "probably" because it's not perfect. But it's a pretty good heuristic).