Devoxx Distilled

Didn’t go to Devoxx this week? Then read on for my subjective summary of the event.

Let’s go with the ‘exceutive summary‘ right away:

  • continue, or start doing, continuous integration, continuous delivery, or continuous deployment.
  • Java8 is already here and it’s different. The new API’s are powerful and have a definite learning curve, but start using lambdas/streams/new APIs right away or regret it later.
  • even dry-as-the-desert-banks are transforming to agile now (in what seems to be a successful and ‘correct’ fashion), no more excuses for anyone else to stick to age old Business vs IT barriers, waterflows and the like.
  • the market is exploding with cloud solutions for building, running, maintaining java applications. time to make use of them.
  • Java EE 7 (and above) is a new breed and much less cumbersome than previous versions. Have a look at it.

The ‘buzz’:

  • Docker
  • Rochefort 8 > Rochefort 6 …
  • Lambdas, Streams
  • Functional, Reactive
  • The Java Posse shuts down
  • Voxxed, a brand new Java community site
  • … Rochefort 10 > Rochefort 8!

As a conference, Devoxx…

  • … is very focused on Java and surrounding technology (obviously!); there are not many methodology, inspirational or alternative talks. Denise Jacobs talks on the creative mind, were, however, very good.
  • … has an excellent venue at the Metropolis Cinema with great audio and screens, great seats, and an easily accessible location (tram stops right outside),
  • … does not have the best quality or supply of food (!) although, there is plenty to drink,
  • … was jam packed with people that created queues for most things,
  • … is located in a country with great beer tradition.

All in all, I had a great time and I’d like to thank the Devoxx team for all their efforts, and Hybris for giving me the opportunity to attend. Hoping for a return next year!

 

Elevate: Continuous Delivery

This Monday, Neil Ford of ThoughtWorks held a talk about Continous Delivery at an Avega Elevate. I wanted to give a brief recap of this, not only due to the quality of the lecture but also because the topic touches on issues about moving organizations towards a Lean or Agile process.

With continuous delivery you strive to keep track of every change in your product. Not only does this mean to version control the code but it also includes keeping track of changes to the platform you are running the system on, the dependencies or 3rd party libraries, the application configuration files, the database schemas etcetera. You strive to build and thouroughly test each of these changes made to your product, so that there is always some deliverable ready to be shipped to a potential customer.

Now, continous integration in some shape or form is something I think most teams do today, or at least that’s my experience from the last couple of years. But what Ford argued is that you can now, with the increased quality in tools, automate a great deal of the, usually arduous, process of acually building and deploying your product. The idea here being that if you have total control of what components your product consists of, and you continously build and test it against a homogenous environment, you will be able to not only deliver, but also deploy, your product to production at every change in the product.

I won’t delve further into contious delivery here (I might retread the topic), because I think Ford hinted at other benefits of this than minimizing human resources and effort. If you really want to have an Agile organization, you would ideally want to be able to change your mind on a whim, and cast your product straight in the opposite direction of where it’s going, wouldn’t you? Ford didn’t like the abundant buzz around the word ‘pivoting’ but I’ll use it here, because it’s a very good word for this. How much time does it take for your organization to put a change of one line of code into production? If you have two companies in which one can deliver four times a year, and one can deliver 365 times a year; which one would most likely be most competitive? For me, this is a huge thing to think about when striving for agility.

I’d also like to mention the way Ford described the way his company worked when producing software. Everything needed by the developers, including IDE, machine setup (Ford reminded us a couple of times that yes, nowadays machines can be built from source code) was in version control. At the office, the work stations each had an exact copy of the version controlled environment so that every developer used replicas when developing. Furthermore, each day a work station would be manned by a pair of developers, pair programming for that day. The next day, the pairs were rotated and each developer might end up at a different work station where a new developer constellation would take on the challenges of software production (I should mention that each employee also had their own laptops that could contain personal software such as Itunes etc).

What a great way of incorporating XP practices, Agile, and team learning and interchange!