sebastiandaschner blog

How to choose technology

saturday, march 04, 2017

In every software project — at least at the beginning — there is the big question of which technology to choose to do the job. Even if you’re not in the JavaScript world with new frameworks coming out every week, you might find a great variety of choices. Which aspects to consider?

We as developers of course tend to new hot technology, the current hype, and apply it immediately in our daily work. However 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) choose 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 that 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.

Coolness factor

Talking about coolness and hype: I discourage to blindly follow the last hype and apply 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 in you’re free time. As an employee consider to give your developers opportunities like the famous Google 20% projects to try out new things and gain experience and applying them later if proven well.

From time to time rather look into these timeless topics:

  • Design pattern & principles of good software engineering

  • Using Java effectively

  • Unix

  • Concurrency

  • 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 practise 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 realiable 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.

Enterprise frameworks

For choosing enterprise technology it depends not only 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 backwards compatability 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 the fact 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 well. Design for deletion not for reusability :-)

Whatelse is important is the tooling support available — including build tools, IDEs or database tools.

If you compare enterprise frameworks against eachother please consider the latest versions and up-to-date best practises 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 & the team on foundations of computer science