As software engineers, how do we evaluate new technologies, programming languages, and practices such as code review? We must keep our goal in mind.
Our goal is to deliver working software. We need to achieve this goal with limited resources: we have only so much time, manpower, and computing capacity available.
The goal is not to perfectly follow a proceduce described by book. The goal is not to craft the perfect masterpiece of code. The goal is not to make you feel smart, either.
Forgetting this leads to arguments that look at the technolgies and the practices in isolation but forget about their context.
For example, at work I’ve thought about splitting up a Scala web service and re-implementing a part of it in Rust. The resulting microservice would be simple, but it would be under heavy load. It is one of the hottest nodes in our graph of services, so great performance is important.
Just looking at the technology, this seems like a no-brainer: surely Rust would offer us greater and more predictable performance than Scala on JVM. The size of the service would be so small that there would be minimal risk of screwing it up.
On the other hand, our team has zero Rust experience right now. Our JVM expertise does not transfer to operating Rust services. We would need to learn how to do it and keep the team staffed with people who are able to and want to work with Rust for years to come.
Is it worth it? It could be, it could be not.
On the other hand, I’m not here to argue that the ends justify any means. The goal may not be to make you feel smart, but software engineering is not supposed to hurt, either.
Consider crunching, the practice of working overtime to meet a deadline. It is common in the games industry where the games have big bang launch dates. Twitter is full of stories about how miserable this has been for everyone involved. They were trying deliver working, delightful software, but was the price acceptable?