How to Take Trade-off Decisions in Programming?

I think this is part of the art of software engineering, but I have some heuristics:

- What do you need the framework for? What do you not need the framework for? Heavily weight your decision based on the needs you know you have, and not what the tool/framework says it does. They all do lots of cool stuff.

- Use Feynman's strategy: when you run across a new problem, try all your existing tricks on it. When you run across a problem you can't solve, put it on the back burner. When you find some new tool, take out all your unsolved problems and see if it solves any of them for you.

- Trade off performance before you trade off correctness. Incorrect stuff always bites you, performance more rarely bites and usually when it does it's easy to fix

- Think hard before trading off speed / correctness in order to save programmer time. The time it takes a programmer to code something is miniscule compared to how much time you'll lose to deploying something you know is incorrect

- Use a novelty budget. Mostly go with popular tools and frameworks that are at least a few years old. You can spend your novelty budget in a weird db, or new framework if you want to, but try to make few weird choices.

- Use what your team is more comfortable with. People can learn, especially developers, but ultimately if you pick some amazing dependently typed language, and your entire team is java developers, you're going to be fighting an uphill battle that is probably not worth it.

- Controversial, but know your developers' skill levels. If you have a lots of mediocre devs, give them a language like Go or Java. They really will tie themselves in less knots with these intentionally limited languages and there are way more stack overflow answers, etc etc.

- If all else fails, check how actively maintained the thing is, number of stars in github, activity level etc. Really sucks sometimes, but you may find the perfect tool and it's unmaintained. You might think "well, I only need it to do this one thing, I don't need updates" and what is happening is you are signing yourself up to be the maintainer when it breaks inevitably, in a way you didn't expect, 6 months from now.

It seems like these days the requirements are often an underappreciated way to help inform the architecture.

Consider basing your selection of tools on whether they actually help you solve some specific problem or operational goal.

Start with the programming language that you are familiar with. You can evaluate in relation to specific problems whether switching to an entirely different system gives you enough specific advantages.

So first make a list of the important things the program has to do. Try to think of how specifically you might program it. Is there a component that you can bring in that will help, and if so, how? What would the system look like if you integrated that? Is there another alternative that is easier to integrate or will work better? Sometimes you just can't know until you outline or try multiple solutions.

But don't add subsystems just because they seem popular or try to preselect everything before digging into the requirements and starting to analyze how you may implement them.

Don't try to figure out the entire program, just start with the most important pieces. Try to get something working, adding every few days or weeks. And for each problem, look at the architecture and tools available. Keep evaluating components and architecture as you go in relation to specific problems or performance/robustness goals. Some of these things you will know ahead of time and of course should try to consider early on. But be careful because many things you think are needed at the beginning turn out to be unimportant or can be eliminated by changes to requirements.

It's a fairly unpopular opinion, but after more than 20 years of software development, leadership and management, I propose the following:

1. is there a KO argument against a particular technology?

For example, high performance trading development is quite different from many other use cases. You really need a fast technology. But for most use cases the concrete technology is irrelevant.

2. Follow your team's passion.

After removing technologies that are not appropriate, just use what you are passionate about. In my opinion, the team learns very quickly when they are passionate about something. Of course, experience also plays a role, but a motivated team is more important to me. And after use a new technology, the team becomes even more experienced.

Most people will just choose a small set of tools they have experience with, or those that have been recommended (friends, salespeople, horror stories). If you care about doing better, rank the benefits and consequences of using them to take a decision. When time is not a constraint you should build a theory of which tools are the best to solve the problem, put them together in a quick way and test them (i.e. do performance testing) to find the bottlenecks and weak spots. Make plan B, C, D... to migrate to other tools in case something goes wrong. Learn from the experience, and hope you will choose better in the next project.

For important work, use the most effective stack you've used in similar situations. For side work or single-use tasks, use something new that you want to know about. As you gain experience with new things, they become the next main thing. The other thing is it hardly matters what you use vs how you use it. I've used everything from PHP to Scala and I can't say 100% which is better, both had pros/cons.

for me it should always consider business needs if it is for profit, otherwise user experience and developer experience.