Imagine a place with no distractions – no IM, no Twitter, in fact no internet access at all. Within, a dozen or more developers, designers, thinkers and doers. And a lot of a food. Now imagine that place is a fort. I talk about why anyone would want to go on holiday to do their day job, the bits of the internet we had to rebuild to work without the internet, and some tips you can use even when you don't have a fort.
Hyperautomation and AI/ML: A Strategy for Digital Transformation Success.pdf
/dev/fort: you can build it in a week @emw
1. You can build it in a week*
James Aylett
/dev/fort
* even if you get caught in a blizzard
/dev/fort is a tried & tested way of kidnapping a dozen people and
stranding them in an isolated spot where they are at risk of starvation,
hypothermia, whiskey and Carly Rae Jepsen parodies.
As a side effect we build websites.
2. What is /dev/fort?
A dozen people. An isolated location. No internet. No phones. A week to
choose an idea, develop it, design it & build it.
3. What is /dev/fort?
Some things we’ve built
WLNY (bit bucket). Mostly Final. Spacelog. History Mesh. BeHabitual.
4. Technology at about 8.5
I want to talk about one of the reasons I do /dev/fort. Because it’s a
holiday where you do your day job: it’s a bit weird. But in your day job
you’re balancing constraints of the real world against what you know
professionally.
We compromise; it’s rare that we get to turn technology up to 11. Or
even 10.
Before the first fort I’d pretty much given up programming. I didn’t have
any interest in it. I’d also had too many conversations that included
phrases like…
8. Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
9. Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
“I don’t care about security”
10. Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
“I don’t care about security”
“I don’t care about users”
11. Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
“I don’t care about security”
“I don’t care about users”
“We just need to ship this”
If your manager says this, he may mean “our CEO has heard agile means
we move faster”. If your CEO says this, he may mean “our investors have
heard agile means we move faster”.
12. Technology at 11
But in a fort we get to set our own constraints. We don’t have managers.
CEOs and investors can’t find us. Nor, as a point of fact, can Sainsbury’s
home delivery. Although we did get a book from Amazon once. This is
getting off point.
13. Technology at 11
Doing the Right Thing
We choose not to compromise on quality. We call it “doing the right
thing”.
And I came back from the first fort excited about building things for the
web again. Other people have as well.
20. Technology at 11
Doing the Right Thing
And we do this in a week
Since we started /dev/fort I’ve become much more hardline about doing
the right thing when I’m working elsewhere. Sometimes you have to
compromise, but more often than not I’ve been better off sticking to my
guns. I’ve started to feel uncomfortable if anyone suggests otherwise.
People who pay attention to these things have been looking at GDS
recently and saying things like that it’s (quote from Paul) “won [us] the
right to finally say ‘no’ and do less, better, to do it properly and stop
cutting corners”. This is basically the same thing. Maybe, *maybe*, now
we can stop having this argument with managers and so forth…in about
ten years when they’ve heard of GDS.
21. Internet in a box
Something we get asked a lot is “how do you do this without the
internet?”. And I tend to assume the people asking are intelligent and
mean things like access to documentation rather than Twitter.
So we take the useful bits with us. RFCs, Internet Drafts, w3.org, jQuery
documentation, CPAN, ruby gems, PyPI, npm.
22. Internet in a box
Package mirrors
CPAN, ruby gems, PyPI, npm…
23. Internet in a box
Documentation mirrors
RFCs, Internet Drafts, w3.org, jQuery documentation…
24. Internet in a box
Wikipedia
Wikipedia provide dumps of their content. Turns out that grepping
through giant XML files is a painful way of reading Wikipedia, so we
wrote our own browser.
25. Internet in a box
Twitter
Oh yeah, and we have twitter as well.
26. Internet in a box
Bugle
Or rather bugle, “group collaboration tools for hackers in forts”, which
Simon Willison wrote. In a fort. We keep on adding bits to it, so it’s not
particularly like twitter any more. Warning: *only* suitable for use in a
fort due to hideous security holes that don’t really matter when you’re
surrounded by stonking great stone walls.
27. Internet in a box
github.com/devfort
We try to release anything useful so other people can use it too. Bugle’s
up there, and Steve Marshall is taking the lead in making chef recipes to
build a copy of the useful bits of the internet.
Plus, we put the sites we build up there.
29. Internet in a box
github.com/historymesh
And a lot of places…
30. What can we learn from this?
There are obvious things like eliminating distractions. Everyone kind of
knows this, but seriously: turn off notifications, don’t let email or IM or
IRC or kittens suck you in. Too many meetings is pretty bad too; you
can’t get away with none at all, but informal talks are usually better.
But there’s other learnings too. Some of them may be more surprising.
31. What can we learn from this?
Collaborate better
Really quickly, too.
32. What can we learn from this?
Collaborate better
A group working together
towards a clear goal
It’s surprising how few teams have a clear idea of what they’re trying to
do. It’s surprising how few *companies* have a clear idea. And if they
do, they’re not always great at sharing this with everyone.
33. What can we learn from this?
Collaborate better
Mentoring works both ways
You don’t really understand something unless you can explain it to
someone else. Also, everyone knows something you don’t. It might be a
trick with vim, a CSS technique you haven’t seen before, or something
really complicated like how to slice an onion. Mentoring provides
benefits in both directions, and isn’t a waste of more experienced folks’
time.
34. What can we learn from this?
Collaborate better
Try eating together
Some companies have made this a cliché. It’s not about paying for
everyone’s lunch, it’s about socialising. Admittedly at forts we do more
than just eat lunch together; we eat, we cook, we laugh, we drink, we
give impromptu performances of Gangnam Style. You may not want to
go that far.
35. What can we learn from this?
You can do things properly and
still have velocity
Prioritise what’s important. Make sure things get talked through before
you start building. If someone’s still arguing it means something’s
wrong, although it might not be what they think.
36. What can we learn from this?
You can do things properly and
still have velocity
Tech doing it right seems to
affect scope less than design
Perhaps because these days there’s *lots* of off-the-shelf support for
what developers care about, but only *almost* what designers care
about. eg: Django ships with a password reset flow that sends a one-use
email token. But it doesn’t log you in after setting the new password,
and doesn’t send HTML email.
37. What can we learn from this?
Learn to love distributed
git means that you can commit from the battlements.
Scripted deployment (“continuous deployment”) means you can deploy
from anywhere, which means you can fix problems & do your job
anywhere. A pub, a restaurant, the deck of HMS Ocean.
I’d love to say that we’ve released a /dev/fort site from an airport, but
we haven’t. Although we did nearly get one running from a hotel in the
middle of a blizzard.
38. What can we learn from this?
Don’t get stuck in a blizzard
Seriously, those things are cold.
You may be wondering “how do I come to a fort?”. We run about two a
year, but forts are always popular so I’m talking to potential sponsors so
we can run more. In the meantime, get a recommendation from
someone who’s been.