Celebrations: Happy Thanksgiving to all our American readers!
Key learnings

6 software development wisdoms from the JAX London – Day 2

JAX Editorial Team
Photo: S&S Media / Katura Jensen

What do we do when microservices fail? What do we do when programmers fail? What have we improved in high-speed systems over the years? And what are the risks of unit testing? We take a look at the some of the most important takeaways from this year’s JAX London.

1. We need to think about what to do when people fail

Failure is inevitable. Especially in highly available systems, says speaker Jeremy Deane. And if you don’t have monitoring in place, you may not even know your system has failed until you get a flood of angry tweets and messages from your users. And that’s when you have to scramble to fix the problem, Deane told us after his session.

“If you implement resiliency principles and techniques, a lot of times, not only can you react very fast, in many cases you can add self-healing. And so you don’t even need to page that person in the middle of the night to come in and fix it. It just fixes itself.”

At the same time, Deane stresses that we need to take care of our company culture after such failures. Do we immediately start pointing fingers? Or do we create a culture where employees are not afraid to share their failures with the rest of the company, so that others can learn?

2. We need to think about what how microservices fail

In her session on microservices, Holly Cummins explained the importance of failure for microservices.

“Thinking about failure is critical,” says Cummins. “Imagine a little microservice teacup, bobbing along in those rough network waters, with occasional hardware lightning strikes. Not only is failure a possibility, it’s practically a certainty. Tolerance for failure needs to be built in at every level, and it needs to be exercised at every stage of testing.”

Speaking of ways to fail, don’t even think about approaching microservices without DevOps, says Cummins.

3. TDD has different styles – be smart about how you use it

You very rarely over-engineer when you’re using the Classicist approach of TDD – that’s on top of it being easier to understand. This makes the Classicist approach, popularised by Kent Beck, a great option for when we’re not entirely sure what we’re doing, or when “we’re exploring” in Sandro Mancuso’s words.

sandro mancuso

Sandro Mancuso at the JAX London (photo: S&S Media / Katura Jensen)

However, it’s not your only option, with the Outside-In approach a better option for when you’re looking to test behaviour, as opposed to the state-based test focus in the Classicist model.

But where does design fit into all of this? For followers of the Classicist style, design happens in the refactoring phase, but for Outside-In practitioners, its all happening in the red phase with zero feedback from your code.

4. It’s not the software that has improved. It’s the hardware.

Problems don’t change, they just get bigger and with history repeating itself in IT “every 17 years or something”, John Davies was quick to point out that it isn’t the software that’s improved things, but the hardware: “Where we have the advantage is the hardware, and its increased at a rate that from day to day, we don’t really notice it. The hardware we have is thousands of times better”.

Back in 1969, Apollo 11’s guidance computer had just 2k of memory and a 32kb computer. Today, we watch 1GB 1080p films on our mobile phones.

“Software is slowing us down,” says Davies. We’ve added layer upon layer of abstraction to hide the existing complexity and hardware, and while this might be good, we should be wary of how it slows things down.

JAX_London-9555

Expo reception chats (Photo: S&S Media / Katura Jensen)

5. Testing databases is tough

In many instances, unit tests can actually become a hindrance to getting the job done effectively, argues Colin Vipurs JAX London speaker and a veteran in testing. Mocking is one thing that Vipurs advised us against ever, ever doing.

“As with mocking any code you don’t own, what you’re validating is that you’re calling the third-party code in the way you think you should, but, and here’s the important part – this might be incorrect,” explains Vipurs. “Unless you have higher lever tests covering your code, you’re not going to know until it hits production. In addition to this, mocking raw JDBC is hard, like really hard.”

6. Java is faster than JavaScript!

Yes, joy be unto all Java developers, for Java officially outperforms JavaScript – at least when it comes to computational workloads, and things like calculations and transactions. Even with a simple “hello world” message test, Java is in the lead for performance.

But that doesn’t mean JavaScript can’t regains its edge within web applications. And it also doesn’t have to be Java or JavaScript – JavaScript is still best suited for the front end, says speaker Chris Bailey.

Comments
comments powered by Disqus