Last week I attended the I T.A.K.E. unconference in Bucharest. This unconference is about software development, and has tracks such as code quality, DevOps, craftsmanship, microservices and leadership. In this post I share my overall impressions as well as the notes I took during the uncoference.
Conference impression
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.
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, though less than SoCraTes, which perhaps is a high standard to set.
Keynote: Scaling Agile
Day one started with a keynote by James Shore (who you might know from Let’s Code: Test-Driven JavaScript) on how to apply agile methods when growing beyond a single team.
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.
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:
“Human nature is to form tribes and throw poo at each other.” @jamesshore #itakeunconf
— Alastair Smith (@alastairs) May 19, 2016
My TL;DR for this talk is basically: low coupling, high cohesion 🙂
Edit: you can now view the recording of the talk. Sound is dodgy, but OK if you turn up the volume.
Mutation Testing to the rescue of your Tests
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.
The speaker continued to ask about who uses test coverage, and had a quote from Uncle Bob 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.
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, 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 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.
Interesting related posts:
Raising The Bar
A talk on Software Craftsmanship that made me add The Coding Dojo Handbook to my to-read list.
Metrics For Good Developers
- Metrics are for developers, not for management.
- Developers should be able to choose the metrics.
- Metrics to get a real measure of quality, not just “it feels like we’re doing well”
- Measuring the number of production defects.
- Make metrics visible.
- Sometimes it is good to have metrics for individuals and not the whole team.
- They can be a feedback mechanism for self improvement.
Open Space
The Open Space 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.
Open space agenda is ready to be setup @itakeunconf #itakeunconf #openspace pic.twitter.com/8LfE7WpMf1
— Vlad Salagean (@vlad_salagean) May 19, 2016
Open space ready to take off! @itakeunconf #itakeunconf Open agenda is ready @claudia_rosu pic.twitter.com/yegKxNMpWr
— Vlad Salagean (@vlad_salagean) May 19, 2016
Open Space: Leadership
This session started by people writing down things they associate with good leadership, and then discussing those points.
Awesome input on leadership skills at the #itakeunconf open space. Thanks everyone! pic.twitter.com/xdmRPBLJ8U
— Lady Retweetsalot (@Singsalad) May 19, 2016
Two books where mentioned, the first being The Five Dysfunctions of a Team.
The second book was Leadership and the One Minute Manager: Increasing Effectiveness Through Situational Leadership.
Open Space: Maintenance work: bad and good
This session was about finding reasons to dislike doing maintenance work, and then finding out how to look at it more positively. My input here was that a lot of the negative things, such as having to deal with crufty legacy code, can also be positive, in that they provide technical challenges absent in greenfield projects, and that you can refactor a mess into something nice.
I did not stay in this session until the very end, and unfortunately cannot find any pictures of the whiteboard.
Open Space: Coaching dojo
I had misheard what this was about and thought the topic was “Coding Dojo“. Instead we did a coaching exercise focused on asking open ended questions.
Are your Mocks Mocking at You?
This session was spread over two time slots, and I only attended the first part, as during the second one I had some pair programming scheduled. One of the first things covered in this talk was an explanation of the different types of Test Doubles, much like in my recent post 5 ways to write better mocks. The speakers also covered the differences between inside-out and outside-in TDD, and ended (the first time slot) with JavaScript peculiarities.
Never Develop Alone : always with a partner
In this talk, the speaker, who has been doing full-time pair programming for several years, outlined the primary benefits provided by, and challenges encountered during, pair programming.
pair programming is not a “go faster” strategy, it is a “waste less” strategy (which often results in going faster)
— Kent Beck (@KentBeck) February 12, 2015
Benefits: more focus / less distractions, more confidence, rapid feedback, knowledge sharing, fun, helps on-boarding, continuous improvement, less blaming.
Challenges: synchronization / communication, keyboard hogging
Do:
- Ping-Pong TDD
- Time boxing
- Multiple keyboards
- Pay attention and remind your pair if they don’t
- Share your thoughts
- Be open to new ideas and accept feedback
- Mob programming
Live coding: Easier To Change Code
In this session the presenter walked us through some typical legacy code, and then demonstrated how one can start refactoring (relatively) safely. The code made me think of the Gilded Rose kata, though it was more elaborate/interesting. The presenter started by adding a safety net in the form of golden master tests and then proceeded with incremental refactoring.
Is management dead?
Uncle Abraham certainly is most of the time! (Though when he is not, he approves of the below list.)
- Many books on Agile, few on Agile management
- Most common reasons for failure of Agile projects are management related
- The Agile Manifesto includes two management principles
- Intrinsic motivation via Autonomy, Mastery, Purpose and Connection
- Self-organization: fully engaged, making own choices, taking responsibility
- Needed for self-organization: skills, T-shaped, team players, collocation, long-lived team
- Amplify and dampen voices
- Lean more towards delegation to foster self-organization (levels of delegation)
Visualizing codebases
This talk was about how to extract and visualize metrics from codebases. I was hoping it would include various code quality related metrics, but alas, the talk only included file level details and simple line counts.