sebastiandaschner blog

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. So which aspects to consider?

We as developers of course tend to new hot technologies, the latest hypes, and applying them immediately in our daily work. However, such premature implementation will probably cause some bad surprises later. But even if you’re just considering technology that has been around for years you’ll find a lot of choices.

Go with the consensus

First of all you should prioritize 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 worse: architect) chose 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 rather than adding 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 to apply new, hot stuff in real-world projects immediately. It’s always worthy to look into new technology — but just not implementing them right away. Rather stick with your “boring” but reliable and battle tested language and play in your free time. As an employer consider to give your developers opportunities like the famous Google 20% projects to try out new things, gaining experience and applying them later if reasonable.

From time to time rather look into these “timeless” topics of computer science:

Even for microservices, Docker, Kubernetes, Apache Kafka, Akka, CQRS or whatever will be used to solve problems tomorrow, these topics are the foundation of proper software engineering practice. They also help you understanding how your framework works 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.

Testing

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 for example Groovy- and Spock-based tests certainly is appealing. However, I claim the same productivity is realizable by applying principles of good software design — especially delegation and layers of abstraction — to our test code. Unfortunately style and quality of test code is often not treated adequately.

IMO JUnit is capable of providing effective and maintainable test scenarios for both small scale use-case driven unit tests and larger scale system / acceptance tests — if used with proper principles of software craftmanship. 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

Choosing enterprise technology depends not only on the team but on the lifetime of your project.

In longer running projects — which indeed are the majority — long term support and backwards compatability are 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 contains the fact how deeply the used framework should 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 available tooling support — 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.

Conclusion