Read the article on my new blog under http://blog.js-development.com/2012/04/qcon-london-my-personal-recap.html
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.
SimplicityKeep things as simple as possible. Simplicity was definitely THE keyword of the conference. Don't create artwork 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 wellYep, 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!
Feedback...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 development process 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.
SocialThe social aspect of the whole software development process was another important factor. IMHO the "How GitHub Works" talk 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.
Beside 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 meeting.
DevOpsDevOps 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 properly!"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:
TechnologiesFrom 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.