This was the first year I’ve attended the JAX London conference, and I must say I was impressed. The conference struck a nice balance between discussing the latest technologies in the Java space and also the ‘soft skills’ side of what we do as developers, which includes use cases and lessons learned from everyday life as a developer
Day One
Unfortunately the combination of the UK ‘Super’ Storm and South West Trains approach to business meant that I couldn’t make the first day of the conference, which was included a series of tutorials. This was a real shame, as I had been eagerly anticipating listening to Thoughtwork’s Neal Ford talking about Continuous Delivery. Thanks to Neal’s website I managed to get hold of the slides, but I’m still gutted that I couldn’t attend.
Day Two
With the Storm well and truly behind us the conference got into full swing. @monkchips provided the opening keynote “How Java got its mojo back”, which I thought was a great start to the conference. Key takeaways:
- Java is still very much alive a kicking, even with all of the competition of other languages
- Java may not be ‘cool’, but thanks to the JVM, the execution scales very well
- Twitter et al have moved from cool technologies (Ruby on Rails) to not-so-cool JVM-based technologies (Scala + Java) in order to meet the massive scalability demands
- Java may be missing a killer web-app framework (and who can deny the JSF approach is a little clumsy), and this may hinder the hipsters from adopting the Java ecosystem
- The Java development ecosystem shows the full range of governance available within our industry, from dictatorship (OSGI) to direct democracy (Apache). I thought this was a fun fact!
- NoSQL is rapidly becoming the de facto datastore of choice – is HDFS the new relational database?
- It’s now more difficult to sell software, and instead the focus is moving towards selling services and data
- Java is the architects choice, the engineers choice, but is it the developers choice?
As @monkchips himself noted, it was a slightly tough audience, and I’m not sure why. Maybe the combination of the previous day’s storm and an early start had set everyone up badly?
Next up with @mashooq talking about “TDD at Scale”. This was an excellent talk, and there were plenty of great points made:
- Doing TDD does not guarantee that good design will emerge from the codebase
- …this is further exaggerated by the fact that good a TDD lifecycle should include “Red, Green, Refactor”, but it’s all too tempting to just go “Red, Green, Red, Green…” Unfortunately I’ve been there and done that…
- It may be easy to split an application into components, but unless a component maps to a real business process, then it will be difficult to create real meaningful acceptance tests around this. This can lead to overly fragile tests, which simply test technical functionality.
- Avoid the test fixture ‘God’ Class anti-patten at all costs. This is created with good intentions to manage test fixtures, but soon grows out of control…
- …instead you could/should invest in creating a DSL to create test fixtures
- Classify tests into Unit, Integration and Component/Acceptance, as this allow some flexibility to choose when expensive/slowest tests are run
- Regularly email the team with the 10 slowest tests. Often the slowness is due to a simple design flaw in the test. Name and shame the perpetrators until they fix the tests 🙂
- Parallelise test execution (where possible)
- System tests are very valuable, and so don’t forget them. If implemented correctly then this truly can become ‘living documentation’
- Lisa Crispin’s ‘Agile Testing Quadrants’ provide an invaluable insight to the range and value of testing that is available in any software development project. This was a great nugget of wisdom!
- The foundations to successful software development are design, code quality, TDD and constant critique
For the third session I attended one of the Big Data Con talks about the ‘Lambda Architecture’. If you haven’t read about this architectural pattern then it’s worth doing some research, as I’m increasingly seeing this adopted by many of the Big Data shops. Although interesting, I didn’t particularly take away lots to share from this, and so I’ll skip notes here.
The fourth session I chose was an explanation (and demo) of the Apache Drill project, which is an open source clone of the much discussed Google Dremel project. The talk was more of a introduction to the project, and so I don’t have lots of notes to share here either. I would recommend having a quick read about Dremel, and also watching a few of the related videos floating around the interweb, as when completed I expect the Apache Drill project to create quite a stir in how we query Big Data sources.
For the fifth and final session of day one I attended @sandromacusso‘s talk on ‘Why other people don’t get it’, focussing on how to create a great development team, how to handle situations where ‘they’ (management) just don’t get it, and also how we as developers should take responsibility for ourselves and our careers.
I always enjoy Sandro’s talks, and this one was a personal highlight of the conference for me – the scene was perfectly set when Sandro opened the session with a question “Does anyone have complete freedom to do what they want in their day job?”. Three of us put up our hands, to which Sandro replied that we “should get the f*ck out, as we shouldn’t be in this session”. Fair comment! There was a lot to take on board here, and I was was quite engrossed to the actual talk, and so my notes are a little sketchy. I’ll try my best to summaries the key takeaways for me:
- In order to create a great software development team and company you have to:
- Define the culture you want to have in your company
- Don’t make your problem bigger. Hire allies
- Help people to help you
- Hiring great developers is not an easy process, but this is critical for creating a great team (and company)
- Good Developers want a good company. If you’re hiring developers then please remember this obvious but often forgotten fact!
- Don’t just rely on boilerplate job advertisements for recruitment (Sandro’s slides contained some great examples)
- If you wouldn’t promote someone on a criteria, then don’t use it for a job advertisement i.e. please don’t use the much maligned ‘X years experience of Y’
- Hiring developers should not be entrusted to the HR department. There doesn’t exist a simple process or test to find the best developers
- Look for passionate developers. Passion could/should be used as a CV filter
- If you have a problem developer at your company, ask yourself
- How was he hired?
- How was he nurtured when he got here?
- If you are looking for a job then publicly display examples of code you have created (OSS etc), personal projects and other involvement with the larger community. Show that you’re more than a 9-to-5er – show your passion for software development! Amen to that…
- Pairing is a vital skill to learn – this allows prospective colleagues to see how you think, how you code, and also how you will be able to transfer knowledge
- When looking to do something beneficial within your company, such as creating ‘brown bag’ technical sessions, or running software craftsman discussion groups, it is best to “ask for forgiveness, rather than beg for permission”
- If you are in a position of authority then you should lead by example
- If you are responsible, then you must also be accountable
- Managers of great teams must provide autonomy, mastery and purpose
- You are ultimately responsible for your career, therefore you must take responsibility. If you don’t like something, then take action to change it
That’s all for this first part of the JAX London review. Stay tuned for the second part later this week (hopefully… 🙂 )
The Tai-Dev Blog 