Last week I went to QCon in London and it was a great conference. Every day had 7 tracks with each 5 talks and an open space session. The overall quality of the talks were great and you could really see that the speakers had deep knowledge of their subject. Even though there were about 1300 people, there were almost no lines for food, drinks or toilets. The food during the lunch was delicious. A big thumbs up for the organization.
My take away of this conference is that I should read more articles with a focus on software science, instead of all the blogs concerning a specific technique. There were two talks I want to highlight that made the most impact on me during the conference and made me want to read more articles.
Unevenly distributed – Adrian Colyer
Adrian had two goals with his presentation. The first goal is to tell the attendees why he is reading so much papers and why the attendees (or you as reader) should read more papers. His second goal is to show some of the fun and amazing research that he has found. Over the course of approximately 1 year he has read an article every weekday and written a summary about every article. By doing this he has read over 350 papers! In his view there are 5 reasons to read articles and I will explain them below, combined with the examples of the researches he gave.
- Thinking tools
By reading articles you sharpen your mind. You’ll read a lot about the problems people faced and how they were solved. Learn to look at problems and concepts in a different way than you did before. As an example he asked if an application that scales linearly is better than an application that doesn’t scale linearly? Intuitively you would answer yes, however, Adrian shows that an article describes that (in this specific case) the system that doesn’t scale linear beats the linear scalable system every time on performance. This shows that the obvious answer is not always the right one and you’ll should think further to make the right decisions.
- Raise Expectations
Learn that you don’t have to settle for the status quo. These articles show you what is possible and help you lift your expectations. There are a lot of research papers pushing investigating into areas you never would have thought possible. One example that really stood out for me was the paper he showed about testing at Microsoft: “The Art of Testing Less without Sacrificing Quality”. The researchers in this article looked at the test reports and analysed the probability of a test finding a defect. By deferring tests that had a low probability of finding a bug or had a low cost of resolving when found later, they were able to reduce 1.6M spend on testing without sacrificing quality or productivity. Only 0,2% of the defects were not found at first possible moment, but only a few days later, when all tests run.This was a great cost improvement without sacrificing quality. This learns you to look differently at you expectations of testing.
- Applied Lessons
Articles aren’t only written by researchers, but also people who are working in the field. There is great value in these articles, as you can immediately apply the information from these articles. Adrian points to a paper from facebook, where they push all configuration through git. He encourages to read the paper as techniques described in the article are applicable to small scale businesses as well.
- The Great Conversation
If you are really interested in a specific area and you read a lot of papers about the subject you start to see how history builds. There are a lot of references in articles and when you follow these you can see how things changed over time. This will help you place things in context.
- Uneven Distribution
A famous saying goes: “The future is here, it is just not evenly distributed”. According to Adrian the here is in research papers. There already is a lot of knowledge about technology of the future in articles that is there to be discovered and ready to be applied by the industry. The gap between these researches and the industry is narrowing. By reading papers you can learn what is coming, or discover new things that you can apply today.
I really enjoyed this keynote and I will definitely keep an eye on Adrians blog “The Morning Paper” (http://blog.acolyer.org/).
Engineering You – Martin Thompson
We should focus on architecture principles, like loose coupling and tight cohesion. Rather pass in a single value if that suffices, instead of passing in the complete object with all it’s fields. It are these principles that will always survive in software development, no matter which technology you choose to use.
He shows that there we in IT are quite slow on picking on the basics. In 1968 there was a conference where agile was already described with the following description:
The design process is an iterative one:
1. Flowchart until you think you understand the problem.
2. Write code until you realize that you don’t.
3. Go back and re-do the flowchart.
4. Write some more code and iterate to what you feel is the correct solution.
It took a long time before this sank in, because only recently we started doing this. Another great quote was made by A. J. Perlis in 1968, stating “A software system can best be designed if the testing is interlaced with the design instead of being used after the design”, effectively describing TDD.
This talk has great connection with the talk by Adrian, because it shows that there is a lot of great knowledge to be found in articles, even if it are older articles. I would really like to broaden my knowledge by reading more articles. And during my quest to read more articles I will keep Martins advice in mind to get more knowledge about the key concepts of computer science.