{"id":1703,"date":"2016-05-24T14:09:30","date_gmt":"2016-05-24T13:09:30","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=1703"},"modified":"2018-07-31T13:02:19","modified_gmt":"2018-07-31T12:02:19","slug":"i-t-a-k-e-2016","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2016\/05\/24\/i-t-a-k-e-2016\/","title":{"rendered":"I T.A.K.E. 2016"},"content":{"rendered":"

Last week I attended the I T.A.K.E. unconference<\/a> in Bucharest. This unconference<\/a> is about software development, and has tracks such as code quality, DevOps, craftsmanship<\/a>, microservices and leadership. In this post I share my overall impressions as well as the notes I took during the uncoference.<\/p>\n

Conference impression<\/strong><\/p>\n

\"itake\"This was my first attendance of I T.A.K.E, and I had not researched in high detail what the setup would look like, so I did not really know what to expect. What surprised me is that most of the unconference is actually pretty much a regular conference. For the majority of the two days, there where several tracks in parallel, with talks on various topics. The unconference part is limited to two hours each day during which there is an open space.<\/p>\n

Overall I enjoyed the conference and learned some interesting new things. Some talks were a bit underwhelming quality wise, with speakers not properly using the microphone, code on slides in such a quantity that no one can read it, and speakers looking at their slides the whole time and not connecting to the audience. The parts I enjoyed most were the open space, conversations during coffee breaks, and a little pair programming. I liked I T.A.K.E more than the recent CraftConf<\/a>, though less than SoCraTes<\/a>, which perhaps is a high standard to set.<\/p>\n

Keynote: Scaling Agile<\/strong><\/p>\n

Day one started with a keynote by James Shore (who you might know from Let\u2019s Code: Test-Driven JavaScript<\/a>) on how to apply agile<\/a> methods when growing beyond a single team.<\/p>\n

The first half of the talk focused on how to divide work amongst developers, be it between multiple teams, or within a team using “lanes”. The main point that was made is that one wants to minimize dependencies between groups of developers (so people don’t get blocked by things outside of their control), and therefore the split should happen along feature boundaries, not within features themselves. This of course builds on the premise that the whole team picks up a story, and not some subset or even individuals.<\/p>\n

\"ScalingAgile\"<\/p>\n

A point that caught my interest is that while collective ownership of code within teams is desired, sharing responsibility between teams is more problematic. The reason for this being that supposedly people will not clean up after themselves enough, as it’s not their code, and rather resort to finger-pointing to the other team(s). As James eloquently put it:<\/p>\n

\n

“Human nature is to form tribes and throw poo at each other.” @jamesshore<\/a> #itakeunconf<\/a><\/p>\n

\u2014 Alastair Smith (@alastairs) May 19, 2016<\/a><\/p><\/blockquote>\n

My TL;DR for this talk is basically: low coupling, high cohesion \ud83d\ude42<\/p>\n

Edit: you can now view the recording of the talk<\/a>. Sound is dodgy, but OK if you turn up the volume.<\/p>\n

Mutation Testing to the rescue of your Tests<\/strong><\/p>\n

During this talk, one of the first things the speaker said is that the only goal of tests is to make sure there are no bugs in production. This very much goes against my point of view, as I think the primary value is that they allow refactoring with confidence, without which code quality suffers greatly. Additionally, tests provide plenty of other advantages, such as documenting what the system does, and forcing you to pay a minimal amount of attention to certain aspects of software design.<\/p>\n

The speaker continued to ask about who uses test coverage, and had a quote from Uncle Bob<\/a> on needing 100% test coverage. After another few minutes of build up to the inevitable denunciation of chasing test coverage as being a good idea, I left to go find a more interesting talk.<\/p>\n

Afterwards during one of the coffee breaks I talked with some people that had joined the talk 10 minutes or so after it started and had actually found it interesting. Apparently the speaker got to the actual topic of the talk; mutation testing<\/a>, and presented it as a superior metric. I did not know about mutation testing before and recommend you have a look at the Wikipedia page<\/a> about it if you do not know what it is. It automates an approximation of what you do in trying to determine which tests are valuable to write. As with code coverage, one should not focus on the metric though, and merely use it as the tool that it is.<\/p>\n

Interesting related posts:<\/p>\n

    \n
  • Type Safety, 100% Coverage, and Uncle Bob: Who\u2019s Right?<\/a><\/li>\n
  • Test Coverage Bliki<\/a><\/li>\n<\/ul>\n

    Raising The Bar<\/strong><\/p>\n

    A talk on Software Craftsmanship<\/a> that made me add The Coding Dojo Handbook<\/a> to my to-read list<\/a>.<\/p>\n

    Metrics For Good Developers<\/strong><\/p>\n

      \n
    • Metrics are for developers, not for management.<\/li>\n
    • Developers should be able to choose the metrics.<\/li>\n
    • Metrics to get a real measure of quality, not just “it feels like we’re doing well”<\/li>\n
    • Measuring the number of production defects.<\/li>\n
    • Make metrics visible.<\/li>\n
    • Sometimes it is good to have metrics for individuals and not the whole team.<\/li>\n
    • They can be a feedback mechanism for self improvement.<\/li>\n<\/ul>\n

      Open Space<\/strong><\/p>\n

      The Open Space<\/a> is a two hour slot which puts the “un” in unconference. It starts by having a market place, where people propose sessions on topics of their interest. These sessions are typically highly interactive, in the form of self-organized discussions.<\/p>\n

      \n

      Open space agenda is ready to be setup @itakeunconf<\/a> #itakeunconf<\/a> #openspace<\/a> pic.twitter.com\/8LfE7WpMf1<\/a><\/p>\n

      \u2014 Vlad Salagean (@vlad_salagean) May 19, 2016<\/a><\/p><\/blockquote>\n