Is there an effective way to make trade-off decisions when programming?
- 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.
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.
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.