To think this was said in 1995 and probably thought about well before... and now here we are with Electron and all this nightmare fuel of bad optimization.. It makes me want to scream.
To think this was said in 1995 and probably thought about well before... and now here we are with Electron and all this nightmare fuel of bad optimization.. It makes me want to scream.
A lot of software is commercial. Business models often imply expansion of some kind. When computer performance becomes better, more features can fit into software within this expansion, until...
A lot of software is commercial. Business models often imply expansion of some kind. When computer performance becomes better, more features can fit into software within this expansion, until software hits lower tolerable performance limit with the current hardware.
Software tools used for developing consumer programs are also subject to industry propelled "arms race" of features and levels of abstraction to make development cheaper. This also leads to consumer software complication over time even when features remain the same.
I think it might often work the other way around too. Features get added and performance is optimized until the point that it is acceptable on current hardware. Lots of code can be made more...
more features can fit into software within this expansion, until software hits lower tolerable performance limit with the current hardware.
I think it might often work the other way around too. Features get added and performance is optimized until the point that it is acceptable on current hardware. Lots of code can be made more performant, but without good motivation, it doesn't make sense to spend time and resources streamlining code for marginal improvements when you could do other things instead. Management seeks to optimize profit, not code efficiency.
Heh, but sometimes that can come back to bite you. Developers get used to "not understanding the low-level bits going on". (At my company, we do 100's of SQL queries per page, when most of them...
Management seeks to optimize profit, not code efficiency.
Heh, but sometimes that can come back to bite you. Developers get used to "not understanding the low-level bits going on". (At my company, we do 100's of SQL queries per page, when most of them could get away with just a handful.) Because developers only optimize (and look "under the hood") infrequently, they don't get good at it. In fact, they may look at "heavy" features, and tell the biz guys "it can't be done without 100s more servers", when in reality it could be done by being clever.
Of course, I'm not saying you should always optimize, but you should always know where your bottlenecks are, and spend a small fraction of time grinding them down.
I wouldn't call that “optimising”. I would call that “having basic fucking competency”. Pardon the French, but really, I have met so many incompetent people on the job, that I sometimes think, if...
I wouldn't call that “optimising”. I would call that “having basic fucking competency”.
Pardon the French, but really, I have met so many incompetent people on the job, that I sometimes think, if this whole “software developer” thing is just a bubble, and if I should really consider investing my time into farming lessons.
To think this was said in 1995 and probably thought about well before... and now here we are with Electron and all this nightmare fuel of bad optimization.. It makes me want to scream.
A lot of software is commercial. Business models often imply expansion of some kind. When computer performance becomes better, more features can fit into software within this expansion, until software hits lower tolerable performance limit with the current hardware.
Software tools used for developing consumer programs are also subject to industry propelled "arms race" of features and levels of abstraction to make development cheaper. This also leads to consumer software complication over time even when features remain the same.
I think it might often work the other way around too. Features get added and performance is optimized until the point that it is acceptable on current hardware. Lots of code can be made more performant, but without good motivation, it doesn't make sense to spend time and resources streamlining code for marginal improvements when you could do other things instead. Management seeks to optimize profit, not code efficiency.
Heh, but sometimes that can come back to bite you. Developers get used to "not understanding the low-level bits going on". (At my company, we do 100's of SQL queries per page, when most of them could get away with just a handful.) Because developers only optimize (and look "under the hood") infrequently, they don't get good at it. In fact, they may look at "heavy" features, and tell the biz guys "it can't be done without 100s more servers", when in reality it could be done by being clever.
Of course, I'm not saying you should always optimize, but you should always know where your bottlenecks are, and spend a small fraction of time grinding them down.
I wouldn't call that “optimising”. I would call that “having basic fucking competency”.
Pardon the French, but really, I have met so many incompetent people on the job, that I sometimes think, if this whole “software developer” thing is just a bubble, and if I should really consider investing my time into farming lessons.