What are IT conferences good for anyway
Recently I’ve attended GeeCON and during the after party I got into a heated discussion with a colleague of mine. Just to give you a little background, we work from home and there is no office. We are paid for the time we spend on conferences and may reimburse half of the ticket price.
Back to the fight — it started with my doubts what financial and non-financial value internal trainings have, if we cannot get our hands dirty right afterwards. In response I was asked:
Why do you go to conferences at all? What value does it have for you and the company?
Let’s try to answer it.
1) Nice to meet you
Being part of a remote software house we do not have the opportunity to meet on a daily basis in the kitchen to discuss all stuff that really matters. Although we have daily meetings, it’s just not the same thing.
Conferences are a great opportunity to see each other IRL and train our degrading social skills, like speaking clearly and verbalizing thoughts in a structured way as well as using knife and fork.
Additionally, we’ve found a restaurant with a round table (can you imagine that?!) and silent music — a great place to have conversations with more than the two people on your left and right.
2) Inspirations
In my previous project I learned a lot about Kafka Streams. The talk given by Jacek Kunicki on Reactive Integration with Akka Streams and Alpakka encouraged me to prepare a similar one, based on Apache Kafka, showing the differences in the approach of streaming data between external systems. Jacek split his presentation into two parts: an introduction into the world of streams and a live coding session keeping the audience awake. You can find the code here.
3) You’re doing it right
It’s always a good feeling to have company in what you’re doing. If you hear on a conference, that the approach you introduced in a project is adopted by others as well, it gives you confidence, you’ve done something right. Then, during the after-parties, when talking about that topic you can skip the obvious working parts and move straight to the pitfalls, as we all know — the devil is in the details which is mostly not mentioned during conference talks. Finally, thoughts around these pitfalls become the presentations of tomorrow.
At GeeCON I’ve found confirmation for what I did in my last project in the talks around streaming.
First Łukasz Gajowy introduced Apache Beam and encouraged us to always ask the following four questions when building a streaming pipeline:
- What results are calculated?
- Where in the event time are results calculated?
- When in the processing time are the results materialized?
- How do refinements of results relate?
You’ll find the answers in the Streaming 102: The world beyond batch paper and for the newcomers Streaming 101: The world beyond batch is a highly recommended read.
Then right after, Kamil Owczarek in his talk Data Streaming: which horse to bet on compared various streaming platforms. Although we know there is no silver bullet, my impression is that Kafka Streams is very close to that. There are areas where it is outperformed by Flink, Spark or Akka Streams, like ML on streams or heavily stateful processing. The lack of built-in connectors is in my opinion a non-issue, since Kafka Connect should cover you in most of the cases.
4) You’re doing it wrong
Krzysztof Dębski explained how to fail as an architect. In his talk When your boss decides to have an architecture team he addressed two scenarios: when you have to deal with a designated team of architects or even worse, when you’re promoted to be an architect.
Bad architects tend to stop coding and not showing up in meetings with developers. On their Ivory Towers they get no support from developers and miss what they are doing. By being placed in different branches in a company they do not cooperate and sometimes even compete with each other.
Finally a good architect is no longer just T-shaped, but rather 𝜋 or even m-shaped having a deep understanding in more than one field. Being an expert in CQRS or streaming may just not be enough.
5) Learning new things
Being in this business for over 13 years I’m still discovering new approaches, ways of programming or dealing with not so common problems. Like securing Java applications.
Bruno Bossola in his Overview of available open source tools to secure Java code mentioned 2 types of utilities, that should make it into your CI pipeline.
Static Application Security Testing apps perform static code and dependencies analysis as well as scan for sensitive information like API keys being committed into the repository.
Although I’ve found FindBugs or rather SpotBugs and PMD commonly used in projects, sensitive information scanners like gitleaks and truffleHog were new to me. Also static dependency analysis performed by dependency-check tells if third party libraries are up to date and what license they have.
The second type of tools are doing Dynamic Application Security Testing. They do not scan the source code but rather attack the working application.
Last thing I’d like to mention is Runtime Application Self-Protection. This requires an agent to be set up with the Java application and allows to shutdown a malicious user session. It also can be used to deploy code fixes at runtime 🙀 So far there’s only one open source tool available, openRASP. Let’s see if it shows up in the next year edition of GeeCON ;)
6) Entertainment
The comparison of shipping applications to delivering cars is from now one my favorite, when telling customers how important it is to write tests or doing other not-only development related tasks. A failure in production can cause financial and reputational damage, you’ve seen before. Just think about recalling cars to replace the airbag.
And have you ever heard:
Can we disable this for production? It slows us down!
Sure, let’s remove it, like brakes in a car, they slow it down!
7) There’s life in the old dog yet
Do you remember J2EE, JavaEE or application servers from JBoss, Bea, Oracle or IBM? Although some of them are really dead, the idea of relying on a standard backed or rather supported by the big players is still alive. This new standard of enterprise Java is called the MicroProfile. I must admit that during the talk about The Twelve-Factor App I was quite surprised how well you can copy-paste all the Spring Boot based micro-services tools and patterns.
Someone pulled out all the stops to save Enterprise Java. It looks useful again.
8) Food for thoughts
Some talks, like the one by Fred George about chaos development, were quite refreshing. When dealing with customers who have a clear understanding of what they want, you may pick the waterfall or Agile methodology. During my career I only met one such a client. My key take away from this talk is to apply chaos development, whenever the certainty of what to build is rather fuzzy than high, but still viable. Forget about TDD, teams of developers, various Agile roles, patterns. Instead build a quick and dirty one-class application to quickly deliver the business value, the client thinks will change the world. Having four developers around, build four different apps at the same time instead of having grooming and planning sessions, retrospectives and architecture board meetings.
I think it’s just fair to tell the customer, that it’s fine not to know what exactly has to be built but rather having a big picture in mind. Eventually we’ll get there experimenting with the domain in a time and cost-effective way.
I witnessed a project during which the development team was supposed to deliver three connectors to 3rd party services. After six months they ended up with one… being written twice.
9) Leaves you with doubts
GraalVM is celebrating its next major release and is getting more and more traction. Jaroslav Tulach in his talk Forget Go. Go Java, Go! was trying to convince me that I should give it a try:
And he’s not the only one.
I know, I know, there will be certainly cases, where fast startup time is an extremely desired feature. For example when the application controlling a plane has thrown an unrecoverable LeftEngineNoLongerRespondingException. It’s just that most of the apps I have delivered to prod wouldn’t really benefit from smaller size or faster startup. However, if building native packages is hidden in the CI/CD pipeline and all the various dependencies work, I wouldn’t object to give it a try.
Is it worth?
It depends. But if none of the above does apply to you, then you can do the math: the ticket costs 270EUR and you could attend 22 talks at most, which means that each talk should be worth at least 12 EUR. That is definitely not always the case, but on the other hand, the seats are very comfortable and chilling for 50 minutes with your eyes closed is just what you need to be ready for the next talks and the party later on.
