As a first-time attendee I wasn’t quite sure what to expect from YOW! 2013. Seeing the range of speakers scheduled to be part of this, and having heard some good comments from previous years’ participants, I jumped at the opportunity to be there. It feels good being surrounded by peers that share similar passions to yourself. Attending regular local meetups I’ve realized how much can be learned by simply sharing knowledge gained through experiences. It was great to see some of the folks that help organize these recurrent local events getting involved and lending a hand at larger events like YOW! Kudos to them! In this post I will discuss some of the themes and talks that were of particular interest to me.
Dealing with Legacy Code
Hadi Hariri’s talk on dealing with legacy code resonated with me. He identified a number of code smells to look for when cleaning code bases, the top three being Commented-Out Code, Doing Too Much and Repetitive Code. Commented-out code simply has no place in our code base, specially given how common the use of source control tools like Git and SVN are in this day and age. If you must, there should be a special reason so be kind enough to include that reason as part of the commented lines.
The importance of not getting caught up in the No Unit Tests -> Can’t Refactor cycle trap was also discussed. If you think not having unit tests is an excuse for not refactoring and vice-versa, think again. Sure, unit testing is more difficult when it’s unclear what the intention of a particular method is (i.e. it’s doing too much and its badly named) but there are always integration tests. Knowing that a user scenario works as expected before and after refactoring may be sufficient. In fact Hadi mentioned how he values integration tests over unit tests, a point found hard to digest by some of the audience. Whether or not they are, using them as a way to start refactoring painfully inexpressive and convoluted code is certainly helpful.
The code coverage topic also came under scrutiny during the presentation. After the majority of the audience stated that they, in some way, were in fact using code coverage as part of their development practices the follow up question of ‘How much coverage do you consider good?’ rendered a silent room. Hadi’s point was that the true value of using coverage tools is often missed: using them as the means to identify unnecessary code. As mentioned, code may be fully covered and unit-tested but if the code is simply never executed under actual user interactions, it may be unnecessary code.
There’s something gratifying about hearing someone else talk about personal pain points. You know the feeling, that “Yeah that stinks… I feel your pain” :). As developers, we’ve all had to – and will most likely continue to – deal with legacy code. This made this talk both cathartic and informative, full of anecdotes and good recommendations.
Aided by the growth of cloud adoption, microservices architectures are becoming increasingly popular. In his session, Sam Newman went through relevant good practices, while compiling a list of useful tips when considering the use of this approach. It was a well delivered and encouraging talk on one of the ‘big topics’ nowadays.
After touching on some of the advantages of microservices (such as the ability to scale or deploy individual services within a large system upon demand and adopting or trying-out new technologies with relative ease) the talk then focused on a key point: Standardizing the gaps between services but being flexible within each individual node. This general approach enables freedom within teams to select technologies and implement services as preferred, while maintaining some level of commonality to facilitate interaction and frequent tasks.
The talk also emphasized that when adopting microservices we have to Get Much Better at Monitoring. Capturing metrics on each of the nodes and maintaining these in a central repository is a way to better deal with the increase in logged data that comes from adopting a microservices approach. Thankfully, now popular tools like logstash and kibana make it easier to deal with such large quantities of information.
Additional tips mentioned include the use of correlation IDs to track down bugs, and the importance of consistency in deployments, ie abstracting out environment details and differences between platforms on each service with the aim of providing a uniform deployment mechanism. Fabric and Capistrano are examples of tools that help with this, controlling the sporadic arise of different methods of deployment that may originate from selecting different technologies when implementing each service.
We all know that technology moves fast, and development approaches are no exception. Whilst in retrospect it may seem that progress is in a single direction and with a single purpose, looking forward it can seem more like things are expanding in different directions, with a multitude of tools, languages and approaches emerging all around.
Keeping up with all this constant change is like keeping up with music; it can be hard and at times even redundant, but it can also be enjoyable if you’re that way inclined. Besides, who listens to music if they don’t like music? Even as developers we sometimes pick what we like and we stick to it, forgetting there are alternatives and that approaches evolve constantly.