Impressions from SwanseaCon 2016

conference / agile / software craft

I attended the SwanseaCon 2016, a conference about Agile Development & Software Craftsmanship. I enjoyed most of the talks and took some notes for the most interesting stuff:

My two favorite talks

Immutable architecture

“Your servers are not your pets” - don’t give them names, don’t tend to them with complex state-based configuration management software like Puppet and Chef, don’t get emotionally attached. Just build the environment you need using simple tools like Ansible, deploy the code to it, put it behind your load balancer and throw the old one away. That is the idea behind “immutable architecture”. This avoids “configuration drift” where you don’t know the configuration/environment state of a machine, “works on my machine”, “special snowflake” machines, “cursed infrastructure” (a concept from RPGs where you can’t drop a piece of equipment).

It is important to realize that your “deliverable” (the “releasable increment” in Scrum terms) is not only code, but the code and the environment it lives in: Libraries and external software it uses, configuration for services it depends on, etc. Ideally, your app follows the “12-factor methodology” to fit well into the immutable infrastructure.

This talk by Gavin Davies was presented in a fun way: witty, with lots of images and nerd humor. No bullet point was harmed during the production of this talk.

Tech communities and fandom

This talk was about the heated discussions and toxic conflicts that befall tech communities (tabs vs spaces, Emacs vs Vim, Perl or Python) and fandoms (Sherlock vs Elementary, ___ was the best Doctor) alike. To outsiders or loosely affiliated members of the group, the issues seem trivial, not worth fighting over. For the core of the community, the issue feels like life and death. One explanation for this is that the “core people” have built their whole identity on “the thing” that they like and anybody who questions it, questions their identity, their existence. The other explanation is that behind the issues are often different and contrasting core values of the people.

One example was the ongoing discussion in the tech community of “Meritocracy vs Systemic Bias”. For people on the “Meritocracy” side of the argument, freedom, individual liberty and a sense of fairness (“hard work gives a reward, everybody can make it if he’s good enough”) are the core values. For people who challenge that world view by saying that the current culture perpetuates the existing bias of young, able-bodied, heterosexual white males the core values are community, participation and again - a sense of fairness.

“All communities are alike” was one of the messages of Jessica Rose: They are “bullseye-shaped”, that means they consist of a big circle of supporters and a small core of people who have invested a lot of passion, time, money and personal involvement into the community.

Memorable talks

Keynote: “Agile and architecture, finally friends after 15 years”

Simon Brown talked about his consulting experience where he encountered teams that “went agile” and threw out all planning, architecture and design. This might have been the backlash against process- and documentation-heavy waterfall software development and come from the false dichotomy of the word “over” in the agile manifesto. However, the quote from Dave Thomas of “Programatic Programmer” fame rang true for me: “Big design up front is dumb. No design up front is even dumber.” According to Brown the “up front design” should not be set in stone and be the blueprint for all the teams. Instead, it should be a starting point, a malleable crystallization core for the project.

Some suggestions for using design techniques from the “pre-agile” era:

Code smells and refactoring

The first part of this talk by Halima Koundi consisted of a description of what a code smell is and categories and explanations of common code smells. The second part was a live coding demo where she showed how to break up a lengthy method of a checkout process that did too much and had a switch statement for different payment types in it.

The presented code smell names were a good starting point for reading more about them. I was delighted to see some of them being actively avoided by me and was embarrassed that I still remember creating recent code containing some of them.

In the refactoring session some parameters were extracted into a value object. When I thought about it later, I asked myself if this refactoring did introduce another code smell - the “Data Object”. Luckily, this StackOverflow question gave the answer that the data object with lots of getters and setter is a case of an “anemic model” and that “Value Objects” are different, mostly because they are immutable and just used to pass related values around.

Continuously delivering continuous delivery

Kim van Wilgen presented the benefits of continuous delivery, how her company implemented it and what challenges she faced. My takeaways:

  • CD is only possible if the first three questions from the famous “Joel Test” (“Do you use source control?” “Can you make a build in one step?” “Do you make daily builds?") can be answered with yes.
  • If you have many microservices with different versions, integration tests that test all services in all versions against each other become impossible because of the geometric growth. Think hard and document which services consume each other and test only the versions that make sense, e.g. the currently deployed and the master version.
  • Sometimes instant deployment is too early, you need mechanisms for turning new features on and off. Typical solutions: feature triggers in configuration or cherry-picking into the production branch.

Continous Security

This presentation by Phil Parker was an introduction on what to keep in mind when thinking about security and why continuous deployment improves security: Small, incremental builds are easier to roll back than big rollouts. You can pinpoint and mitigate deployments that introduced security issues more easily.

When thinking about security, always think of the OWASP Top 10. Use the Metrics from the Common Vulnerability Scoring System (CVSS) to think about the risks and repercussions of security holes. Also have a look at the Building Security In Maturity Model (BSIMM) studies to see how other software companies secure their systems.

From Scrum to Flow using Actionable Agile Metrics

This talk was about ditching Scrum with its story points and rough estimates and instead using a Kanban board with many columns for the specific stages in the development process (analysis, dev, test, sign-off, deployment) and tracking how long each story (or its broken-down substories) stays in each column. This gives you concrete metrics, a visual representation of the metrics shows you where your bottlenecks are and a scatter chart of historic data gives you a date estimation of when the story will be finished (e.g. “we finished 33% of our stories in 10 days, 80% of the stories in 30 days, so if you want a confidence of 80%, then we will commit to finishing this feature in 30 days”). You get date-driven (or data-driven) planning.

Unfortunately you’ll probably have to rent the analytics software from Actionable Agile to get all the nice charts and visualizations.

User-Story-Point-Estimation

This talk was about finding rational, analytical and repeatable factors for estimating the complexity of a task. Instead of relying on your gut feeling for the estimation, you rely on factors that affect the productivity of your team (domain and technology knowledge, cohesion, etc) and factors that make individual use cases more difficult (asynchronous programming, special security concerns, nontrivial algorithms, etc). When you put these factors into a formula, you arrive at a point value.

What the talk did not answer, was if the point value of each user story is actually different enough from other stories to be actually meaningful.

Progressive Web Application: Instant Load and Offline Support

I did not enjoy the presentation of this talk: the slides had no contrast and were nearly unreadable and the “live coding” example did not explain what the web worker was actually used for and what the page should actually do.

However, the speaker gave a good metaphor for web workers: A proxy between the HTTP requests of the app and the real server. It can intercept the requests and give cached results, intercept the result and cache it and it gets notified if the browser is online or offline.

From what I’ve seen, the technology is still in its infancy and not widely supported. The possible performance gains have to be weighted against the additional effort for browser-sniffing and server-side rendering for browsers that don’t support the feature. On the other hand, Google is promoting Service Workers as a viable model for web applications.

The pessimist in me also reads the spec, which says “A user agent MAY use a stricter definition of being online” to mean “all browsers will handle bad network connections (GPRS, Edge, Hotel Wifi) differently.”

Closing Keynote - Beyond breaking bad. The current state of agile in ten easy lessons

I’ll not repeat all 10 lessons but the ones that stood out to me:

  • The original paper on software development methods that gave us the often-feared “waterfall” actually talked about how flawed the waterfall is and that there should be feedback loops between the steps and short cycles.
  • The Scrum guide is not a bible that excludes all other methods. Beware of “Dogmagile” and “Scrumdamentalism” and use as much methods and processes you need.
  • Stop using metaphors for software development (engineering, gardening, building). Would you go to a carpenter and say he should use software metaphors?
  • Stop using estimations, neither in story points nor in time. Only measure average time spent. Some stories are complex, some are not, the law of big numbers and the short cycles will give you the average number.
  • Stop using Scrum boards with “Todo, In Progress, Done”. Visualize all the steps that lead to “done” status as columns and place the task appropriately. This avoids tasks being “almost done” (meaning the code is finished but that’s not all that is to do). It also visualizes bottlenecks.
  • Don’t use sprints as mini-projects with an iron triangle (Time, Resources, Quality). Build a rough roadmap of creating and improving a minimum viable product (MVP) and organize your sprints/backlog around the roadmap.

Concepts and Ideas