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.
Simplicity
Keep 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 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!
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.
Social
The 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.
DevOps
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
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.
Architecture
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:
Technologies
From the technology point of view the major discussed topics of the conference were
- Mobile Web apps with HTML5 and JavaScript instead of native ones
- NoSQL and document based databases (like MongoDB)
- JavaScript and HTML5
My Notes of the Conference
You can find my personal notes taken during the conference
here.
Questions? Thoughts? Hit me up
on Twitter
