[peteretep]

    > I have the feeling that knowledge
    > about bits is lacking by a lot of
    > younger coders. And I also think
    > this is what causes bloatware

From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for developer and maintenance.

Certainly when running technology in an SME I found my gut feelings about many cost/benefit questions were often invalidated by the ever-decreasing cost of computing power, both in terms of physical hardware and cloud resources.

[notzorbo3]

Managers often think throwing more hardware at the problem will fix things. But hardware scales sub-linearly. Solving the actual underlying problems can easily get you exponential payoffs.

Anecdote: One of my managers once spent €70000¹ worth of hardware to speed up an application because he believed it would be cheaper than to optimize the code. Naturally, no-one had done any kind of performance analysis, so while the upgrade made things about 20% faster, it still wasn't enough. It took me all of 20 minutes to figure out that caching was disabled on the database and it had no indexes whatsoever². 30 minutes of work yielded a few thousand percent speed increase.

¹) This was a long time ago before SSDs existed and buying a hardware RAID of fast disks and fast CPUs / memory was extremely expensive.

²) DBAer consultants of a certain large database vendor are not worth the horrendous hourly fee they ask.

[peteretep]

    > Managers often think throwing more
    > hardware at the problem will fix things

It often will...

    > no-one had done any kind of performance
    > analysis

... is the moral of this story

[nur0n]

I think we agree on the basic point: you can't decide what the most cost effective solution is until analysis is carried out. But an effective performance analysis can't be executed without an understanding of the machine.

Lacking low level knowledge can only create blind spots in the analysis.

[chillingeffect]

Nice work! This is where legends of 10x programmers come from.... they're 2x programmers in a world of 0.2x programmers ;)

[laydn]

That almost physically hurts to read!

The performance modelling teams working for the large CPU makers get several code traces from major database vendors to optimize the execution of critical pieces of database code. They do a cycle-by-cycle analysis.

And then people run the databases with caching and indexing disabled. Go figure

[xorcist]

> I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems,

I regularly see the exact opposite: People throwing money and hardware at problems instead of doing the simple and obvious thing. I guess that makes me officially old.

[peteretep]

    > People throwing money and hardware at
    > problems instead of doing the simple
    > and obvious thing

There are (almost) no technical problems, just business decisions. Programmer time for development and maintenance is expensive. Hardware is decreasingly so (also it's CapEx, so nobody cares if you literally light it on fire).

[wmccullough]

I find this too. Even the so-called proprietary algorithms many companies tout aren't even that complicated because 90% of their business runs on a REST over CRUD in SQL web service with a slightly different bootstrap theme on the frontend.

[xorcist]

See, now you fell for the same fallancy. Something that is smart must surely be more expensive, but this is seldom true. A method that is simple is easier to describe, easier to implement and could very well be more performant than a more complicated one.

[eru]

You can often see a bit bump in complexity when going from single computer to some kind of cluster environment (be that hadoop or similar). That complexity also often decreases efficiency.

So it can be useful to think a bit to be able to stay on one machine.

But making those trade-offs is exactly what engineering is about, and what's hard. So talking in the very abstract is seldom useful.

[afpx]

It depends on the person, obviously. But, I hope you sprinkle in a few of those types of analysis questions in your standardized interviews so that older people like me even have a chance.

It hurts (both emotionally and financially) to be rejected by younger teams because they assume things about me that aren't true. I now get the dreaded "has too much experience and would be bored" rejection line all too often.

[fundabulousrIII]

There is only one way to go there. Start a consultancy and be your own boss. That is about it for us older folks. Most of your customers don't want stellar code: they want you to fix what is broken (which is simple enough).

[seanwilson]

> From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for developer and maintenance.

Why do people feel the need to generalise about things developers of different ages do...?

Knowing when to save on developer time by spending money in some form definitely seems to be a learned skill though.

[peteretep]

    > Why do people feel the need to
    > generalise about things developers
    > of different ages do

Mostly it was a tongue-in-cheek reply to a comment doing the same...

[mighty_bander]

You'll find a lot of people of all ages that get lost in the problem instead of considering the cost/benefit and going with a good compromise between cheap and "perfect."

Of course you'll also find a lot of kids who overestimate the maintenance cost of 3 lines of weird code sitting in a corner doing their thing for 20 years ;)

[fundabulousrIII]

This is where some knowledge as a syseng or SA comes in very handy. Programmers tend to come up with cool solutions to a problem in their wheelhouse but it may not be the most cost effective or efficient solution. Having domain knowledge is very important.