3 ms·

Are there really people who still need convincing of this? At the same time you probably shouldn't be throwing more hardware at the problem without trying to un

by tjpnz 4y ago

Are there really people who still need convincing of this? At the same time you probably shouldn't be throwing more hardware at the problem without trying to understand it first. I've witnessed numerous times throughout my career what can be saved by tuning a few parameters.

papito 4y ago
It's the resource curse. Why think about it too much if you can just throw resources at the problem? This is not just an issue with builds. Seems like developers treat everything as "free", from HTTP round-trips to database queries. Not to mention the tendency to craft convoluted and heavy solutions to rather standard problems. Because "this is how it's done now". Standing here, holding my hammer. Lo, on the horizon: a nail!
KronisLV 4y ago
> Are there really people who still need convincing of this? Some might just not care that much, or nobody might speak up about the problem, not wanting to make it seem like they're just complaining, in the case of nobody being able to provision more resources, or optimize the build. For example, in some environments, getting a better CI node might be associated with red tape, lots of back and forth with a different department or something like that, especially if it's all on-prem instead of using managed services or cloud resources. > At the same time you probably shouldn't be throwing more hardware at the problem without trying to understand it first. I've witnessed numerous times throughout my career what can be saved by tuning a few parameters. This is an excellent point! In a context of containers (just an example, though illustrates some pitfalls nicely) there's a world of difference between using a base image that has the runtime and tools you need, vs installing them every time. There's a lot of difference between pulling in your dependencies every time, vs using a cache for it or an instance of Nexus that acts as a caching proxy (though that's not very nice to configure in most languages). There's even difference between making sure that packages install correctly from the cache, vs having them already be installed in some intermediate layer that you can just reuse when building your container. Even without containers, there can be lots of things to take into consideration, like whether you could build your back end and front end (in the context of webdev) or other components in parallel, whether you could run any tests you might have in parallel, or whether there's not duplicated work going on in there somewhere.

by tjpnz 4y ago

papito 4y ago

It's the resource curse. Why think about it too much if you can just throw resources at the problem? This is not just an issue with builds. Seems like developers treat everything as "free", from HTTP round-trips to database queries. Not to mention the tendency to craft convoluted and heavy solutions to rather standard problems. Because "this is how it's done now". Standing here, holding my hammer. Lo, on the horizon: a nail!

KronisLV 4y ago

> Are there really people who still need convincing of this? Some might just not care that much, or nobody might speak up about the problem, not wanting to make it seem like they're just complaining, in the case of nobody being able to provision more resources, or optimize the build. For example, in some environments, getting a better CI node might be associated with red tape, lots of back and forth with a different department or something like that, especially if it's all on-prem instead of using managed services or cloud resources. > At the same time you probably shouldn't be throwing more hardware at the problem without trying to understand it first. I've witnessed numerous times throughout my career what can be saved by tuning a few parameters. This is an excellent point! In a context of containers (just an example, though illustrates some pitfalls nicely) there's a world of difference between using a base image that has the runtime and tools you need, vs installing them every time. There's a lot of difference between pulling in your dependencies every time, vs using a cache for it or an instance of Nexus that acts as a caching proxy (though that's not very nice to configure in most languages). There's even difference between making sure that packages install correctly from the cache, vs having them already be installed in some intermediate layer that you can just reuse when building your container. Even without containers, there can be lots of things to take into consideration, like whether you could build your back end and front end (in the context of webdev) or other components in parallel, whether you could run any tests you might have in parallel, or whether there's not duplicated work going on in there somewhere.