4 ms·
Performance matters, but I’m not sure people are saying that it doesn’t. I’m not a performance “first” type of programmer by any means, but I always keep it in
by devjab 3y ago
Performance matters, but I’m not sure people are saying that it doesn’t. I’m not a performance “first” type of programmer by any means, but I always keep it in the back of my mind, what I also tend to keep in the back of my mind is cost.
I recently “inherited” a couple of back-end services when a developer left our company. It turned out that the code was terrible and that they haven’t used, any, or our helper tools. Since we use Typescript everywhere ignoring our quite opinionated and a little fascist linter rules is almost impossible, but the developer in question had the authority to turn it off, which they did and in doing so shot themselves completely in the foot. The back-end services were developed in JavaScript more than Typescript and since both our linters and usual teat pipelines were disabled, and since it’s software that has been developed over almost a years worth of changes, it was just horrible. We’re talking loops comparing values, that were probably there once but are now just sorting things as undefined === undefined kinds of terrible.
The performance was also atrocious. Basically what the service did was gather info on a couple of thousand projects and link them with tens of thousands documents in Sharepoint, but because it was build wrong, it wasn’t pulling the correct documents and it was taking 5-10 minutes each run time. It’s now running at around 10 seconds for its complete run time. Which is a massive performance improvement, and it’ll be even better once I finish building the cashing. So you might think I’m inclined to agree with the article, but I didn’t rewrite it because of its poor performance, I rewrote it because it didn’t work correctly and the performance gains were simply a happy “coincidence”.
This is because the performance didn’t really matter. Yes, it was costing us at most $77 a over our 3 year Azure contract, but the time I spent rebuilding it cost the company almost exactly $1500. Those $1500 were well spent because it wasn’t working, but would they have been well spent in terms of performance? Not really. That being said, it wouldn’t take a lot of those services to become expensive, so it’s not like the author is really wrong either. It’s just that I’m confused with whom he is arguing.
- camgunz 3y agoThe points he lays out at the beginning of his post are basically Martin Fowler's (and thus 90% of enterprise engineers') position in Refactoring. Fowler was probably responding to engineers making code inscrutable in the name of (dubious claims of) performance, and Muratori here is responding to the ensuing overreaction.
- citrin_ru 3y ago> I’m not sure people are saying that it doesn’t In my career I've meet people who genuinely don't care about performance. For them code either works or doesn't. Back in the days when everyone used bare hardware if a developer would push a change which suddenly requires 10x more hardware (or makes 10x more requests to other's team service) it would break the system and force to do something about it - either order more hardware (takes time) or fix the software (usually faster). Nowadays cloud would auto-scale and such change would go unnoticed, the only difference will be the next month's cloud bill.
- fredrikholm 3y agoI'm not following. > [bad developer burns a year worth of salary building something that doesn't work] The cost you cite for the rewrite implies a week or two worth of work. Why did this developer spend an entire year on it? Really bad developers are really bad, yes. Double work is very expensive. > I didn’t rewrite it because of its poor performance > ... massive performance improvement, and it’ll be even better once I finish building the cashing. So even with the massive performance improvement, you still need to improve the performance even more? It sounds like you would of had to rewrite parts of the system even if it was decently written to begin with.