QCon NYC Day Two: Skills To Pay The Bills

[This is a slightly modified version of an internal travel blog post I wrote for the Vend crew]

It’s a dreary Thursday in downtown Brooklyn, low cloud, muggy – but at least I got some good sleep. The F-Train was packed this morning.

TL;DR: Embrace imperfection and change. Still no one doing transactional microservices.

Tweet of the day: https://twitter.com/darinrs/status/477191543577509888

The day kicked off with Dianne Marsh, Director of Engineering at Netflix. She didn’t elaborate a lot on what Aidrian said about Netflix culture on Wednesday, but did list through a bunch of tools they use to do their builds and deploys. They use tools like Asgard and Animator to manage and deploy Amazon Machine Images (AMIs) directly. Apparently this is pretty old-school compared to what we’re doing with Puppet; and Chef, and new containerised deploy tools.

She talked about freedom and responsibility at Netflix, using the example of an engineer who wanted to use Python (freedom), but was required to completely integrate it with Netflix build, deploy and monitoring stack (responsibility).

Next up was my favourite session of the day: Michael Feathers talking about Conway’s Law (http://en.wikipedia.org/wiki/Conway’s_law) and suggesting that we flip it around. What if we organised the company structure around the way we would like our architecture to look? We’re already doing this with our separation of POS clients and API, but if we were to run separate teams based on product area, would that cause us to define better boundaries between those components? Maybe.

Michael had some interesting thoughts about cruft and debt. What if we treated entire swathes of code as “open for extension, closed for modification” like OO classes? His point that there should perhaps be a more clear delineation when a section of code is “closed”, but teams instead tend to let things tail off a bit without properly “closing” stuff.

Michael also touched on constantly changing teams, and asserted that teams and employees will ALWAYS change faster than the structure of the application. So if we always assume that teams will change, then we design ways to cater for that. He suggested keeping teams small is a good idea – like smaller than 12 people per team. HAHA. LOL. [We don’t have many more than 12 engineers at Vend right now]

Also, Michael talked about combining Conway’s Law with Dunbar’s Number (http://en.wikipedia.org/wiki/Dunbar’s_number) to posit that there is an actual upper limit on the overall size of a feature that a team can manage, and therefore the overall size & complexity that an entire product could safely be given a number of teams and engineers. He referred to this as “human scale” software architecture, and suggested that these limits should be taken into account using careful “asset management” when planning new features, and that features should not actually be added if they can’t be supported. Interesting.

Then (fanboy moment) Eric Evans – Mr Domain Driven Design. Warning for designers: his book has the ugliest cover design in the history of technical book covers. Ugh. Anyway, digression. Eric’s talk was about embracing imperfection, which I think surprised much of the room given how dogmatic some proponents of DDD have become.

Eric talked about creating Bounded Contexts, and how useful these are in refactoring software. Define an area of the application that you want to work on, nail down a clean domain model for it, and build a translation layer (ahoy! API!) between that context and the rest of the app to abstract away imperfection. He went on to explain that yes, this will result in multiple different models throughout the app, but this is inevitable, and in fact desirable because it gives you more flexibility to cater for the specifics in each context.

One interesting thing Eric talked about was that adopting a “trendy new language” can in fact be a good way to force the creation of a new bounded context, because:

  • Early adopters tend to be very capable developers.
  • The new language marks the part of the software where “we’re going to do it right” – at least initially.
  • The new context makes connecting with other parts of the application in a loosely coupled way a conscious step

Of course there are all the downsides of early adoption too, like will the language still be around, and will people have the knowledge to work on it? No easy answers here, but Michael (in the prior talk) did make the point that longevity of a species implies death and rebirth, not immortality. Deep.

Finally Eric talked about acknowledging imperfection at small-scale via what he calls the “spill zone”. You’re building or refactoring something and you have a wonderful elegant model that solves 90% of the cases, is within reach of a further 5%, and simply can’t cater for the final 5% weird-cases. What do you do? You use an if-then-else and write a crappy “allTheRest()” function to cater for the weird cases. He suggests this is a faster, better approach than spending much longer attempting to reach an elegant model for 100% of cases. AND the “allTheRest” function doubles as documentation of the weird cases.

In closing: I’m glad I wrote this, because Thursday’s sessions didn’t feel as interesting as Wednesday, but in review there are some interesting nuggets there. I’m looking forward to Friday because there is an entire stream on Engineering Culture with talks from GitHub and others. Peace out.

Leave a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.