I had the privilege of attending the speaker sessions of Craft Conference last week, the central theme of which was software craftsmanship. There were many inspiring talks and so was the venue. Think of it as TED for software developers. The icing on the cake was free beer, complimentary Palinka, unlimited coffee and a blues band. 20% of the speakers were women (but only 4% of the attendees) and ~350 of the 900+ attendees were from abroad. The event was virtually flawless. The usual systems that breakdown at scale: WiFi, food and toilets, all just worked. Plus there were small thoughtful touches such as English translations of useful Hungarian phrases on the attendee badge. Everything about the conference was impressive, including the raffle prizes which included a R/C drone!
Other interesting features were the use of Sli.do to manage audience questions in real-time, and a live-projected twitter feed. I had the opportunity to interact with practicing or aspiring software crafts[wo]men from Ukraine, Japan (ok, technically SF), Netherlands, Sweden, North America, UK and… India!
I’ve tried to distil out the summary of talks that interested me. They are ordered by my preference, not the order in which talks were actually conducted. These are my interpretations and my views, so please bear in mind that they could be wrong or biased. There were 3 tracks (parallel talks) over 2 days, so essentially I attended only about 1/3rd of the total. Day 2 was the first day of the speaker talks… I didn’t attend day 1, which was workshops.
I strongly recommend checking out the agenda and viewing the talks that interest you online, you might find some that I didn’t attend but are of direct interest to you. To me the top 3 recurring themes of the conference seemed to be:
- State management in complex and distributed systems
- Better automated testing & TDD
- The abuse of agile (in development and in project management)
How I Learned to Stop Worrying and Love Flexible Scope
Probably one of the most-loved and honest talks at Craft. The storytelling was simply mind-blowing (an example of agile from 1628 AD, Ducati’s experience with the Second System Syndrome, threats to competitive advantage from Google & the Russians) and so was the message. I would highly recommend watching the video, Gojko is an outstanding speaker. The highlights were:
- The most common software development methodology these days is WaterScrumFall, in which all the essential planning is done upfront by management and the development is done in a [predictable] number of sprints
- This is because the concept of agile is not attractive to management, unless they truly believe in keeping scope flexible. Therefore agile generally remains underutilized.
- Agile is not just about continuous delivery, but also continuously reacting to local, temporal and human factors
- Project plans and roadmaps should not be linear, but literally a “map of roads”: multiple options with selection criteria (like a GPS). A roadmap with a pre-decided outcome is not a roadmap, but a road in a tunnel.
- Try new things, at a survivable scale and select the ones that work (Throwing away bad code is a way to reduce your technical debt)
- Don’t just ship software, make an impact
- On the topic of outsourcing: Usually the objective is to minimize costs, so the focus is not on excellence or flexible scope
- On User Stories:
- Are a way to delegate details
- Avoid translating the product roadmap into a set of JIRA stories, instead consider hierarchical backlogs
Add a victory condition to your user stories, which is related to changing user behavior rather than complying with the existing behavior (e.g. Monitor inventory *faster*)
- A good user story is a survivable experiment
- Adapt: Why Success Always Starts With Failure, by Tim Harford (specifically the Palchinsky Principles)
- What Customers Really Want, by Scott McKain
- 50 Quick Ideas to Improve Your User Stories, by Gojko Adzic
Agility and the essence of software architecture
This was also one of my favorite talks. I like to think of it as Minimum Viable Architecture for developers. Simon is an inspiring speaker, more so because he eats his own dog food. The premise was simple:
- Agile delivery does not imply agile architecture
- Agile development still requires upfront thinking to define the overall architecture
- The team must have a shared, consistent vision of the significant structural elements of the product
- With this pragmatic tradeoffs can be achieved: e.g. a monolithic deployment container, containing microservices
- UML was supposed to solve this problem, but it is poorly understood, not widely adopted and has its own overheads
The solution: NoUML! Abstraction is more important than notations. A team can define their own legend for these abstractions. Design diagrams are supposed to reduce complexity (through abstraction), not increase it. The 3 things that the team needs to have a common understanding of are:
In real life, we rarely have 1:1 mapping between design diagrams and code. In general, a hierarchical C4 architecture diagram can solve this problem:
- And optionally, Classes
And yes, while good architecture is a shared responsibility, it is important that only one person (or a small group of people) are responsible for maintaining the overall architecture definition.
- Just Enough Software Architecture, by George Fairbanks
- Software Architecture for Developers, by Simon Brown
Getting Things Done at Scale
This was a talk I could relate to a lot, because of GTD and the differences in corporate cultures of large, old organizations vs smaller, newer ones. Amber is a TED speaker, and it clearly shows. She shared her experiences during (and after) the acquisition of Geoloqi by ESRI.
Only 1 of 50 people she spoke to for advice had a happy acquisition experience, and the main reasons were:
|Crippling management/overhead to get simple things done||Culture clash|
|Founder flight||Jealousy/blocking from parent company employees|
|Lack of detailed transition plan||Sprinters vs Marathon Runners|
|Loss of passion for original product||Loss of respect and cross-compromise|
The solutions discussed were:
- Pre-negotiate, don’t be vague. Predetermine your outcome.
- Learn the local language (technical terms, tools, company culture)
- Win friends to influence people. Develop trust.
- “Beta test” people via small projects. Best code wins.
- Scale teams down from unmanageable numbers to 5-6 “doers”
- Communicate. Respect. Give first.
- Small revolutions
- Distribute stress
An interesting concept was the creative use of IRC bots, e.g. to send out a daily email summary of accomplishments (!done). Towards the end, she also shared an effective way of “organic hiring”: turning contractors into full-time employees.
It’s never too late to fight your legacy!
Mate delivered a very strong and reassuring message: Legacy code isn’t bad, just old or over-iterated… and, with some sensible planning, foresight, and many iterations of hard work, it can be replaced by more modern code. He explained how they achieved exactly that at ustream.tv. The presentation requires some familiarity with web programming but it would still benefit anyone working with legacy code… because maintaining legacy code builds character. 😎
Programming, Only Better
The core message was about how the introduction of multiple [mutable] states makes programs unmanageably complex. Topics included:
- Referential Transparency
- Representation of state using numbers instead of objects to it remains immutable
- “Encapsulated state” is still state
- Effect on concurrency
- Additional complexity added by control structures in contemporary program
The presentation itself was a work of art and for me the highlight was that Bodil was editing & running code from within the slides!
- Out of the Tar Pit, a 2006 paper about Functional Relational Programming by Ben Moseley and Peter Marks
Going Reactive: Event-Driven, Scalable, Resilient & Responsive Systems
Jonas gave an inspiring and pragmatic talk about how the nature of, and expectations from, applications have changed dramatically over the years. The highlight was that not only did he distill them into the 4 attributes mentioned in the topic of the talk, but also shared valuable insights into how to practically achieve them from a technical standpoint. Some of the approaches discussed were:
What Makes a Good Development Process?
Bruce Eckel is an industry veteran an author who needs no introduction (I read his textbooks in high school). I highly recommend going over his slides, they are very comprehensive, thoughtfully put together and highly informative. He has already distilled years of experience into a few pages, and I don’t think I can add any more value except quoting the one thing that stood out for me: The cognitive load of carrying tensions prevents us from doing creative tasks well.
Acknowledging CAP at the Root – in the Domain Model
This talk dealt with a very specific type of problem (CAP = Consistency, Availability & Partition tolerance), and solving it using a domain-driven programming model. One of the interesting concepts was that of defining aggregates within a distributed system. Instead of trying to keep the entire system in a consistent state, the contents of each aggregate are guaranteed to be consistent (even if equally stale). There is only a single point of reference into an aggregate. Aggregates are contained within a bounded context and transactional consistency must not cross these boundaries. Domain events interpreted within this context cause state changes. Eventually overall system consistency can be achieved through synchronization according to a reasonable SLA.
Don’t forget to check out Day 3!