food for thought: code bloat

[PlainName]

That's old thinking. Nowadays you architect a product by using Python to glue github modules together. Easy peasy.

[brucehoult]

That's old thinking. Nowadays you architect a product by using Python JavaScript to glue github node modules together. Easy peasy.

[SiliconWizard]

That's old thinking. Nowadays you architect a product by using Python to glue github modules together. Easy peasy.

 

[Bud]

System architect are watered down to mineral water these days.
I now see architects with less than 5 yrs of work experience f*cking it up because they have no clue what they do except look good

Do not know what your justification fot 5 years experience comes from.... Many years ago I had 2 years of Extensive experience working in a specific area and I still carry on decades after and get hired and get paid for the knowledge I got from that time period. Granted, I did not sit twiddling my thumbs during those 2 years, but I firmly believe 2 years is a huge experience absorbing resource. Even 1 year, because in my second year new knowledge influx dropped exponentially - simply there was nothing new to learn.

[perdrix]

I don't know. I'm next to (I refuse to say I'm with) a team of 300 developers and quite frankly they have enough time to do a proper job of solving all the problems. They just lack the motivation and skill to do so.

I saw them burn 9340 hours on something that took me 30 minutes to fix. No shit. That one was fucking buried as well so the management didn't look like morons.

Been there seen that

D.

[SiliconWizard]

I don't know. I'm next to (I refuse to say I'm with) a team of 300 developers and quite frankly they have enough time to do a proper job of solving all the problems. They just lack the motivation and skill to do so.

I saw them burn 9340 hours on something that took me 30 minutes to fix. No shit. That one was fucking buried as well so the management didn't look like morons.

Been there seen that

Indeed.

[Kjelt]

Do not know what your justification fot 5 years experience comes from.... Many years ago I had 2 years of Extensive experience working in a specific area and I still carry on decades after and get hired and get paid for the knowledge I got from that time period. Granted, I did not sit twiddling my thumbs during those 2 years, but I firmly believe 2 years is a huge experience absorbing resource. Even 1 year, because in my second year new knowledge influx dropped exponentially - simply there was nothing new to learn.

Always exceptions and it also greatly varies with the domain and scope you are working on.
Surely you agree understand that the software architecture for lets say an thermostate is more limited than for a tv which is again more limited then for an electron microscope etc.
At my current company a new sw eng will only be productive eg earning money for the company understanding what the work is after two years. My previous company that was two months.

But to answer your question, the 3-5 years was the default HR evaluation period with a local large electronics company in the 80s till 2000s. Nowadays it is more dynamic, eg there are brilliant people that stand out and get a fast track.

[IDEngineer]

Sometimes code bloat IS the most efficient solution. "Good, fast, cheap: Pick any two." It totally depends upon the problem being solved. I bet the Apollo 13 astronauts didn't want to delay their return to wait for code jockies to slash a few cycles. On the other hand, they cared very much about optimizing current consumption because their fuel cells were gone.

Not every problem is a PhD thesis. Sometimes "good enough" is exactly the right answer.

[Siwastaja]

Sometimes code bloat IS the most efficient solution. "Good, fast, cheap: Pick any two." It totally depends upon the problem being solved. I bet the Apollo 13 astronauts didn't want to delay their return to wait for code jockies to slash a few cycles. On the other hand, they cared very much about optimizing current consumption because their fuel cells were gone.

Except that bloated shit usually is expensive, delivered late, and does not work, while efficient software is also delivered in time, cheaper, and works better. The correlation is strong.

This is because poor practices go hand-in-hand. If you can't write decent software, or manage a software project properly, then it will fail in many different ways.

Shaving off the last 1% of performance is of course totally different, but it's never about this really.

[Berni]

Sometimes code bloat IS the most efficient solution. "Good, fast, cheap: Pick any two." It totally depends upon the problem being solved. I bet the Apollo 13 astronauts didn't want to delay their return to wait for code jockies to slash a few cycles. On the other hand, they cared very much about optimizing current consumption because their fuel cells were gone.

Not every problem is a PhD thesis. Sometimes "good enough" is exactly the right answer.

The code in the apollo computers did pick compromises where appropriate.

A lot of the firmware is in the form of bytecode executed using an interpreter to save program space while some sections of code are executed as raw machine code in order to run faster. The computers they had ware not very fast, so speed optimized code was needed in some cases. These early computers also didn't have power saving states to drop into while running.

Optimizing too much in one direction is often a bad thing.I am not asking for people to optimize every last cycle of speed out of there code. Just do the basics to catch the worst speed bumps or resource hogs in code. Picking a slight shortcut that runs at 10% the original speed is not excusable by "It still runs fast enough on my 11th gen i7 machine"

[brucehoult]

The code in the apollo computers did pick compromises where appropriate.

A lot of the firmware is in the form of bytecode executed using an interpreter to save program space while some sections of code are executed as raw machine code in order to run faster. The computers they had ware not very fast, so speed optimized code was needed in some cases.

An obsolete concept.

Once you have registers the same size as the data you are manipulating (including pointers), and enough of them, a well-designed RISC ISA with nearly direct hardware control (i.e. simple decode, no microcode) implemented in the now classic 5 stage pipeline is both as fast as simple hardware can go AND as compact code as any interpreted bytecode.

There is no longer any need to choose between size and speed.

[Berni]

Yeah it doesn't make sense to do this approach on modern machines. Even just ARMs Thumb instruction set is reasonably compact and flash commonly comes in hundreds of KB these days.

Most of the reason this interpreter approach made a lot of sense on the Apollo guidance computer is that the instruction set on it was very limited (really couldn't do a whole lot per instruction in the couple of instructions it had). At the same time program memory was a lot more expensive when it had to be woven trough ferrite rings by hand and actually increased the total mass of the computer. That interpreter must have been a pretty fancy bit of software engineering back in the day.