I was at the QCon at San Francisco last week.If you are not familiar with QCon- it’s very heavily focused on Architecture . It draws an impressive line of speakers and generates an awesome content. Personally, I found it to be a very intense experience. There very many sessions with quite a few keynotes- all crammed to into one tight week.
1) Culture:
It was amusing how culture came up as a factor or as an impediment or challenge or side affect in almost all conversations – be it in the session or or keynotes or discussion with fellow attendees during breaks
Want to move to Cloud computing ?
Change persistence from RDBMS to NoSQL ?
Continuous delivery ?
Pair Dev and QA ?
For all these changes, you will need to address some sort of cultural transformation in your organization.
2) Conway’s Law
The design of your organization will betray the design of your architecture.
If the interaction between two groups who develop two applications which interact with each other is broken- the integration between the two applications will be flimsy as well.
Simple and astonishingly true. The other manifestations of Conway’s law will appear in other facets like – Do your QA and developers work in silos or is your testing strategy closely bound to your architecture ?
3) NoSQL
Yup ! It’s the new kid on the block. The sessions for NoSQL were most crowded. Seems like the organizers had gravely under-estimated the interest in this but clearly there was a huge interest among the attendees.
One of the message that stuck with me was- Consistency is over rated. It doesn’t really matter if you have inconsistent data in your system (almost all systems do.) What really matters is – how well you encapsulate the inconsistency and expose only the consistent data. I saw NoSQL solutions being chiefly suggested for two main use cases. One: The data model for your application is very malleable and you need to keep it soft. Two: The volume\nature of transactions is so huge that RDBMS can no longer solve your problem.
4) Cloud computing
Cloud computing is the new OS.
Its working and is here to stay.
Adapt with it.
Developers need to learn the new ecosystem, If you are a developer and you think – I just code and where and how it gets deployed- is someone else’s concern- you are in for a nasty surprise. Randy gave an excellent talk on how developers will need to adopt (all for better actually) with cloud computing. Coding for the cloud is not the same as coding for a regular system. The rules of engagement have changed. And if you are in Ops- you need to understand this new ecosystem as well (and maybe better and actually quickly). How can you contribute to the changing world?
5) Improving efficiency
There was an engineer from Google who talked about his team- whose responsibility is just to improve the efficiency of all other developers at Google. They inspect each and every step of development pipeline – ranging from code reviews ,check-ins , unit testing and see how the waste can be reduced or eliminated. Now to have a whole department dedicated to this may not be feasible or practical or even warranted for most of us- but it still behooves to pause and ponder- what are you doing to go faster…?
Automate ? Automate the automation ?
6) BDD
BDD is the new DD. I could see much buzz around this. BDD or ATDD clearly has won more acceptance than TDD among the community. One session was titled BDD with Puppet. Imagine putting all the scripts the Ops have in source control and testing them – finally 
7) DevQA pairing
When you talk about pairing and you still think of pairing two developers, you are way behind.The world has moved on. It’s now time to pair developers with QA. And this actually means having a QA engineer share a screen and keyboard with a developer. They will collectively figure out the test scenarios and maybe code the test harness together for BDD tools like Cucumber.
8 ) Continuous delivery
At this point- I am assuming you already have Continuous Integration in place. Now you need to think of Continuous Delivery. The build pipeline starts from development onto production.The pipeline moves the build from one stage to another: Checkin->Compile->UnitTest->AcceptanceTest->Deploy. Most of this happens automatically and sometimes manually.
When we deploy to production should always be a business decision and not a readiness decision. There were sessions with mind boggling titles and description – “Deploying to production every day” “Deploying 50 times to production in a day” “5 minutes from commit to production” . What really made me think very hard was “How much time does it take for you to move one line of change to Production ?”
9) Functional programing
Even if you are not using Functional programing , it would be a good idea to adopt some FP practices. You can go all the way with Haskell or go conservatively with Scala or Clojure or even more cautiously with FP libraries – right in the comfort of Java. Oner way or other- FP is the way ahead.
10) DevOps
If you thought pairing Dev with QA was mind boggling- you need to sit down for this one. Consider pairing Dev and Ops. Should Dev and Ops be really two teams ? This movement challenges the basic structure of the organizations. E.g. Netflix has no separate team for operations -they run every thing in the cloud.
11) DSL
DSLs have existed forever – in some form or other(CSS ? PL\SQL ?).
With DSL the conversation in the team between becomes more business like rather than technical. Languages like Groovy and Ruby are positioned very well to create your own DSL. I always thought DSL as something which would be applicable for some very specific cases- but I realised that the opportunity to create your own DSL maybe closer than you think it is… I didn’t hear much about DSL , but the keynote speech by Martin Fowler made an impression enough on me to add it here.
Also check out some quotes from QCon posted here and here. (Thanks Dennis !)
Recent Comments