How to Choose the Right Technology for Your Project
Choosing the right technologies for your projects is a complex task. It's not just about being cool and using the latest thing out there.
Join the DZone community and get the full member experience.Join For Free
We as developers, of course, tend to gravitate toward new, hot technology, the current hype, and apply it immediately in our daily work, though that premature implementation will probably cause some bad surprises later. But even if you’re considering technology that has been around for years you’ll find a lot of choices.
Go With the Consensus
First of all, you should choose technology that the team of developers is familiar with. This may sound obvious but I’ve seen quite a few cases where a “rockstar” developer (or even worse: architect) chooses some technology they’re familiar with — without considering the whole team — and left later. In a Java-dominated team, the obvious choice is to go with plain Java or frameworks written in Java, and maybe not add Go just because it’s cool now. And: It’s probably also not desirable to overload the number of polyglot languages.
Talking about coolness and hype: I discourage blindly following the latest hype and applying new, hot stuff in real-world projects. It’s always worthy to look into new technology — but just not implementing them immediately. Rather, stick with your boring but reliable, battle-tested language and play around with the new tools in your free time. As an employee, consider giving your developers opportunities like the famous Google 20% projects to try out new things and gain experience and applying them later if they prove useful.
From time to time, rather, look into these timeless topics:
- Design pattern and principles of good software engineering.
- Using Java effectively.
- Transactions, distributed systems, and network protocols.
Even for microservices, Docker, Kubernetes, Apache Kafka, Akka, CQRS, and whatever will be used to solve problems tomorrow, these topics are the foundation of proper software engineering practice, and you indeed need to understand how your framework is working internally.
The topic of design patterns and principles is especially important to kill the need for a new, fancier language. If you design your program properly, especially taking care of delegation and layers of abstraction, you don’t need dynamically typed languages or a lot of syntactical sugar to produce readable code.
This is particularly true for testing. For our tests, we tend to be less strict with the choice of technology as this “is not production anyway.” The readability and maintainability of Groovy- and Spock-based tests is certainly appealing, but I claim the same productivity is reliable applying principles of good software design — especially delegation and layers of abstraction — to our test code. Unfortunately, test code style is mostly not treated with the same attention.
IMO JUnit tests for both small scale use-case driven unit tests and larger scale system/acceptance tests is capable of providing an effective and maintainable testing technology — if you’re in a Java-based project anyway. I’ve recorded a video to demonstrate this on implementing acceptance tests. But again: Go with what the team is most familiar with.
Choosing enterprise technology not only depends on the team but on the lifetime of your project.
In longer running projects — which are, to be honest, most of them — long term support and backward compatibility are indeed a topic to take into account. Who knows if the new framework that’s just been out for a year will be there in 2, 5, maybe 10 years?
That also includes how deeply the used framework needs to be woven into the code. A couple of annotations (à la Java, EE, or Spring) can easily be changed later — a programmatic API less so. Design for deletion, not for reusability.
What else is important is the tooling support available — including build tools, IDEs, or database tools.
If you compare enterprise frameworks against each other please consider the latest versions and up-to-date best practices to do the job. There’s no point bashing technology with destructive, uninformed FUD — like heavyweight J2EE, old-iron application servers, or Spring using bloated XML-based configuration.
- Choose what the team is familiar with.
- Don’t be cool — play in your free time.
- Choose the right tool for the job.
- Prefer principles of good software design over the latest hype.
- Don’t overload the number of languages.
- Educate yourself and the team on foundations of computer science.
Published at DZone with permission of Sebastian Daschner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.