From the previous posts (or from those on my
Tumblr stream) you might have understood my participation at this year's QCon London. Actually it was my 1st
QCon conference and I enjoyed it a lot. Here is a quick recap of my personal impressions.
First of all, being my 1st QCon, what I really liked was the fact there were no technology
evangelists, no one stating that one technology/language is better than the other etc, but everything was a bit
more generic, more high-level. There was a bunch of interesting stuff so I'll try to just focus on the ones that
particularly caught my attention.
Keep things as simple as possible. Simplicity was definitely THE keyword of the conference. Don't
architectures, create easy and simple ones. Devs need to deliver value
and a good
architecture should leverage that and not hinder them.
It's about trade-offs!
Dan North's talk about "Decisions, Decisions,..." highlighted the fact that every taken
decision is about trade-offs. As such, while automated deploy is a known best practice, it's still a trade-off in that
people (once the deploy is automated) might loose the knowledge of doing it manually. Hence, in certain circumstances
you might even prefer a manual over an automated deploy just to keep things simple.
When you know you are trading off you can make informed decisions.
Dan North, QCon London 2012
Copy&Paste might be an option as well
Yep, you read right. You shouldn't always aim for factoring out
logic as much as you can and to then reuse that same piece of logic in every possible place. Because, every time you
factor out common logic, you create a new dependency
as well. Obviously that doesn't mean to c&p all the
logic around, if you have to fix a bug in 2 places you failed
. Instead, what it means is to not over-reuse
things. Often copy&pasting and removing the lines you don't need might work out better than taking in all the other
logic (which is not needed in that specific scenario). The rational behind: don't take it to the extreme
Keep the cycle short. While this might seem a quite obvious concept nowadays, especially when
you're doing agile, it was a core concept throughout the whole conference. Integrate mechanisms in your
that give you feedback as soon as possible. This starts from writing automated unit tests to
setting up a proper build pipeline as outlined in the Continuous delivery training session from the Thoughtworks
guys to Netflix's impressing metrics system.
The social aspect of the whole software development process was another important factor. IMHO the "How GitHub Works
by Zach Holman
was a highlight of this part. He highlighted some very important facts about how to
create a pleasant working environment and how to properly coordinate a distributed (GitHub) team.
those mentioned on his blog
, some things I
personally found interesting and valuable:
- Celebrate events (releases, birthdays,...)
- Have informal meetings, sit together, talk about interesting stuff
- Have Tech Talks held by employees
"Leave the ego at the door"
When you join meetings or pair coding sessions or whatever discussions, leave
your ego at the door
. That's the only way to learn! While this might sound obvious, try it yourself the next
DevOps is an often used term these days. In small teams/companies this is not really an issue as there
might not be any dedicated staff just doing operation activities like server configurations, DBA work etc.. The larger
companies get, the more difficult things become and the more arises the risk of building a gap between the development
and operation teams.
"No way, my servers are fine, it's probably because they don't know how to code
Sounds familiar? Aren't we one team in the end?? This is a major issue! Dan North talked about
one of the situations he experienced, where he personally joined the operations staff and worked there for a while, as
a fully integrated team member. In this way he learned about the problems there and was able (due to his programming
capabilities) to solve quite a bunch of issues by automating stuff. The same works vice-versa. An OP guy joining the
dev team might get a better insight into the application architecture and hence be able to more fine-tune the servers.
OP guys know how to configure, devs how to automate. The key is that both parts naturally fit each other and should
benefit from that.
Again, simplicity is the main key here. Don't create masterpiece architectures, but simple, extensible and understandable
ones. That's the only key they'll be properly adopted.
Beside that, architects need to code. They need to use their own systems, see how they perform and optimize
accordingly. This way an architecture can evolve. Everything else is bullshit and a waste of time.
Without going into detail any further, here are the 3 pics of the session with Simon Brown:
From the technology point of view the major discussed topics of the conference were
- NoSQL and document based databases (like MongoDB)
My Notes of the Conference
You can find my personal notes taken during the conference here