What sounds interesting at GOTO Copenhagen 2015?

The GOTO Copenhagen conference is still a couple of months away, but I have taken a look at the talks, and spotted a few that I think will be interesting.

Generally speaking, I don't go for technology specific talks - by which I mean that I tend to go for talks about processes (e.g. Agile), concepts (e.g. Big Data) or general architecture, rather than talks about specific languages, or even worse aspects of languages, or about specific programs (e.g. a specific NoSQL database). I don't mind examples at a talk being language specific, but I prefer to be able to apply the concepts from the talk broadly.

Having said that, I am as prone to follow hype as everybody else, so if something new and exciting is presented, I might very well go there, even if it breaks my general preferences for talks.

When you see my list, you'll notice that I haven't filled my schedule. This is quite common for me - I rarely know what I want to see at a conference when I begin my day. Instead I like to hear the talks getting presented in the morning, and then decide what to go to.

If you tend to skip those talk presentations, I think you're really missing out. Some of the most exciting talks I've listened to was not remotely on my schedule until I heard them presented at the start of the day.

So... onwards to my list.

The first talk I noticed was Richard Lander's How to train your corporation to prefer open source.
Microsoft has gone through an incredible change in regards to their stance on Open Source in the last few years, to the degree where now they have Open Sourced most of the .NET platform. This is hardly something one would have guessed a few years ago (even though Microsoft has never been as anti-OS as some people think it has), so I definitely want to hear how this happened.

I don't usually go to IOS-related talks, but I might just go to Jorge D. Ortiz Fuentes' Test Driven Development (by controlling dependencies).
There is no description of the talk, but I am always interested in seeing how people handle dependencies, as I think this is an overlooked problem-area in my software development Projects. Given it is in the IOS and Swift track though, there is a high likelihood of me giving the talk a pass.

Other than the mentioned talks, I will probably spend the rest of the first day listening to talks in either the Game Changing Methods and Practices track or the Fast and Continous Delivery track.

On the second, and final, day of the conference, there are four tracks that all sounds interesting - Reactive Architectures, The State of Data, Front-end: The Bleeding Edge, and Security, Safety and Privacy.

In the first track, Reactive Architectures, I am probably going to Jonas Bonér's The Sadness at the End of the Happy Path and Dave Farley's Reactive Systems: 21st Architecture for 21st Century Systems.
Building resilient and high-performance systems is hard to do, and any ideas on how to do it better, are definitely welcome.

If I am not going to Dave Farley's talk, I will certainly be going to Dave Thomas' The State of Data 3.
I have seen Dave Thomas talk a number of times, and his talks are often quite amusing, but also, more importantly, highly informative. Big data is his field, so I expect the talk to be as great as always.

A talk that sounds interesting, is Phil Winder's Modern Fraud Prevention using Deep Learning, which is at the same time slot as  Andreas Halberg's Secure Coding Patterns - another talk that sounds useful for when developing systems.

As always, when at multi-track conferences, there are often several talks I find interesting at the same time, and which I won't choose between until the last minute. Again, much depends on how the talks are presented, and whether I have heard the speaker before. Usually there are a few speakers that are "must-go-to" for me at the GOTO conferences, but this doesn't seem to be the case at this conference. This is not a bad thing - it gives me the opportunity to get to know new great speakers.

Disclaimer: As a blogger who blogs from the conference, I get a free ticket (like I have done for the last couple of years). The deal comes with no strings attached, except for an agreement on me writing a certain number of blogposts about the conference. The conference has no say over the content of the blogpost.

Agile and pseudo-science

Back before I started blogging about IT-related stuff, I used to write about pseudo-science on my other (very quiet) blog Pro-science, and before I had that blog, I used to comment a lot on a number of science and skeptic blogs.

First commenting and later blogging about science and pseudo-science has helped enable me to be better at detecting woo and pseudo-science in my daily life. Woo is a term used in the skeptic community to indicate something which is based on anti-science and have no scientific validity or data to back it up.

Woo and pseudo-science exists everywhere, and I have found that the field of IT is absolutely no exception. Rather, there are certain areas which is rampant with pseudo-science, often bordering on woo.

One such area is the field of Agile.

The field of Agile is not a well-defined field, but is a loosely collection of methodologies, techniques, and tools, used for systems development. It is commonly understood as having formed as a result of the agile manifesto, but in reality, it started developing before then, and would probably have come into existence as a field, even if the manifesto hadn't been written.

As a software developer, I use Agile methodologies, techniques, and tools on a daily basis. I also go to conferences and meetups about Agile frequently.

Due to that, I can't help noticing that there is not a whole lot of science behind Agile. Not only that, many of the arguments people use to promote Agile is not exactly based in science or data, but rather on pseudo-science, often in the form of popular science.

This summer, I went to a conference which had a talk on Agile and NLP. I didn't go to the talk, so I can't say anything about the actual content, but let's be perfectly clear: NLP is pseudoscience (.pdf) - see also Thirty-Five Years of Research on Neuro-Linguistic Programming. NLP Research Data Base. State of the Art or Pseudoscientific Decoration? by Tomasz Witkowski (.pdf).

If you do a search on the words "Agile" and "NLP", you'll find articles like NLP Patterns and Practices for High-Performance Teams and Achievers by J.D. Meier. If you look at the blogpost, and are in any way familiar with the writing of people pushing pseudo-science, you'll notice the patterns there. There are appeals to effectiveness and popularity, but no actual data to back those claims up. 

It is highly likely that Meier actually believes that NLP helps, but there is no science to back it up - neither in the form of an explanation of how the NLP mechanisms works or in the form of data, backing up the claims of improvement.

This is, unfortunately, widespread in the field, and not just when it relates to NLP.

Agile (as all things related to systems development) is very much dependent on people, and since most realize this, there is a lot of focus on this aspect. 

This results in many speakers on the subject on Agile, will pepper their talk with references to neuroscience, but rather than looking at the actual science papers, they will get their knowledge from popular science books, by people like Malcolm Gladwell.

In 2012, Steven Poole wrote an article for The New Stateman on the subject of popular science books on neuroscience, called Your brain on pseudoscience: the rise of popular neurobollocks. While he, in many peoples' opinion, painted with too broad a brush, there was an important message in the article, which we'll do well remembering - popular science books often have an agenda, and they are simplistic, and, in many cases, get the science completely wrong.

E.g., as a rule, one should expect anything written by Malcolm Gladwell to be wrong.

I understand why speakers and authors tend to use popular science books as sources, rather than the real science articles. With popular science books, there is a good chance that the audience has already read them, and the science is presented in a form which is easy to digest and regurgitate.

Just a pity that the science is often presented simplistic at best and wrong at worst.

Some speakers, such as Linda Rising and Kevlin Henney, instead read the original science papers, and refer to them instead. Given that those two speakers are among my favorite speakers, I hardly think it takes anything away from their talk. It just makes them more accurate.

Having addressed the use of pseudo-science and popular science, I think it is also important to address the fact of data on which to evaluate things.

This is obviously connected to the other problems. Lack of data, leads to bad conclusions.

A simple example of the lack of data, is this: How do we know Agile works? 

Or put in another way: On what basis do we conclude that Agile works better than what was there before?

As far as I've been able to find out, there is no real data to support such claims.

Yes, there have been studies that indicate that Agile works better, but those are somewhat doubtful, since there was no baseline to compare to, no clear definition of what went before Agile, or even what Agile is.

People tend to compare Agile to Waterfall, but as Laurent Bossavit wrote in his excellent book The Leprechauns of Software Engineering, there is no clear evidence that Waterfall was ever used - at least not in the form that people commonly think of when talking about the Waterfall method. 

Personally, I believe there is great value in using Agile, but I am not willing to make any claims without data to back me up, and in order to have that, we need to try to not base the field on pseudo-science and misrepresentations in popular science, and instead try to use real science, and to collect and evaluate data.

Not everything fit into the scientific method, and in a field that is so heavily dependent on people, there will be times where personal preferences will lead the way, but this doesn't mean that we can't do better.

Think of it this way: We would not accept a new UX design without an AB test or some other empirical data to back it up. So why would we accept it when it comes to our methodologies, techniques, and tools?

Privacy should be a priority

Ever since Snowden started telling the World about the doings of the NSA and other government agencies, privacy has become much more of a focus area for a lot of people - this includes Tim Bray, who debuted a new talk at GOTO Copenhagen called "Privacy and Security, Policy and Tech".

At GOTO Copenhagen, the room was unfortunately full, and I didn't get to see it, which is why I was quite happy to get a second chance the week after at GOTO Aarhus.

The overall message of Tim Bray's session was that privacy is important, and that we, as developers, should make sure to project the privacy of our users' information as much as we can.

A lot of people have a quite relaxed opinion about privacy and security, though this has started to change after Snowden. As Tim Bray said:

A lot of people has realized that the internet is a bad place, and that their information is hanging out places where it shouldn't be.

Also, people have started to realize that just because they have nothing to hide now, it doesn't mean that they won't have in the future - if nothing else, then when laws change, and formerly perfectly legal things become illegal.

A historical example of that could be membership of certain political organizations in the US, which was prefectly legal, until the red scare and McCarthyism kicked in.

Another, more recent example, is simply being a LGBT activist in Uganda, which carries high risks of prosecution, even if their "kill the Gays" law was Struck Down.

Again, quoting (or rather, paraphrasing) Tim Bray:

Most people at this conference probably live where the government is fairly civilized, and won't get their door kicked in at the middle of the night. But while it is probably true for people at this conference, it is not true for a majority of the World population as a whole.

This is an important point. Even if we have nothing to hide, and don't expect ever to have anything to hide, the same doesn't hold true for most of the World's population, perhaps including a large proportion of your end users.

This should be obvious, but a lot of people tend to forget that, and don't even enforce the most basic of methods for enabling privacy such as HTTPS.

HTTPS was an area that Tim Bray dedicated a lot of time to, exactly since it is such a basic method, and so many systems don't support it.

This has to change.

Using HTTPS is such a low-cost, easy solution that there is absolutely no reason not to use it at all times, no matter whether privacy is needed. And as Tim Bray also pointed out, there is an asymmetrical cost to using vs. not using HTTPS. Using HTTPS costs a little all the time even when it is not needed, but not using HTTPS can come at a huge cost when it was needed. This is an unacceptable risk.

One thing Tim Bray didn't get into, which I also find important, is that if everybody runs HTTPS, and thus encrypts their Communications, it offers a type of herd immunity to those who really need to protect their privacy - their communication doesn't stand out from the rest.

This is the reason why Google encrypts its user's traffic (they were actually inspired by Cory Doctorow's book Little Brother).

So, all in all, the overall message of the session was that we need to think about how we can protect the privacy of the end users, and at the very minimum we need to ensure basic privacy measures like HTTPS.

Size doesn't matter

Big data.

A couple of years ago, at a GOTO Aarhus conference, I took a break from the sessions, and walked around in the vendor area. Here I was lucky enough to be able to listen in on a conversation between Dave Thomas and Jim Webber, where Dave Thomas was explaining to Jim Webber why graph databases, like neo4j, were not suited for the type of stuff he was doing. Basically, what Dave Thomas did, was to take all global stock data several times a day, and run some analysis on it (I am obviously simplifying it, and probably explaining it wrong).

This is the sort of things I think of when I hear the words "big data".

Since that's the case, I have been somewhat skeptical when people start talking about big data in Denmark, because we have very few domains where there are anything remotely close to such data amounts (health care probably being the one exception).

It turns out that I've basically misunderstood the concept of big data, and that I underestimated the amount of data out there.

At GOTO Copenhagen, I went to a talk with Eva Andreasson, where she gave an overview of the big data landscape, mostly at the vendor level. During this session, she made a number of important points, which made me realize I have to change my view on big data and its usage in Denmark.

First of all, Eva Andreasson made clear that only about 10% of all data out there is what we traditionally would consider data (e.g. data about companies or people). The rest of it is all the trace data that people leave around when they navigate the internet, doing whatever shopping or browsing they want.

Such trace data, put together with traditional data, allows companies to analyze end-user behavior much better than traditional data alone. E.g. while traditional data will tell you what customers bought, trace data will tell you what products customers spent a long time looking at, without buying them at the end - allowing the company to do some further analysis on what it would take to get the customers to buy the product.

Another thing that Eva Andreasson made clear, is that big data isn't just about working on large data amounts. It is also about aggregating new data sources into existing use scenarios of existing data, and about making new use scenarios of the data that you work with, allowing you to look at things in new ways, hopefully gaining new insights.

Based on these two points, it is clear to me that I have to reevaluate my understanding of when big data is relevant. And judging from the conversations I've had with other people about big data, I am not alone in this.

Aim for the stars

One of the great things at most conferences is the keynote talks, since they are usually picked by the conference organizers in order to expand the mental horizons of the conferences goers.

The organizers behind the GOTO conferences are, in my opinion, particularly good at this.

Every time I've been to a GOTO conference (or a QCon conference where they have been involved), there has been at least one keynote talk, that made me rethink things, and look at the field in new ways.

At GOTO Copenhagen, there were several such talks, but one of them stands out in particular.

Very moving keynote speech by @russolsen on the moon landing and the lessons we can learn from it #GOTOcph
— Kristjan Wager (@kriswager) September 26, 2014

On a two-day conference, the least attractive keynote slot must be the early one on the second day (after the conference dinner the evening before), and I am always impressed by the speakers who can go on stage at that slot, and leave an unforgetable impression.

At GOTO Copenhagen it was Russ Olsen who gave his "To the Moon" talk.

I hadn't heard Russ Olsen before, but judging from the keynote talk, he is a great speaker, and I'll definitely check out any talks of his I come across in the future.

So, what was so great about Russ Olsen's talk?

Well, as my tweet embedded above states, it was about the Moon landing and what we, as a field, can learn from it. Most people would probably find this interesting as it is, but my description doesn't do the talk justice at all - Russ Olsen manages to express the feelings of nerverousness and wonder behind the whole process, especially during the last 10 minutes of decent towards the moon.

Russ Olsen also has a great message - quoting Kennedy, he reminds people that they shouldn't do something because it is easy, but because it is hard, and that nothing is impossible.

So, if you're at GOTO Aarhus, I would highly recommend going to Russ Olsen's keynote talk on Tuesday, even if the conference dinner made you get to bed late. But in case you miss it, it can apparently be found online.

Ahead of my time

If you follow me on twitter, you'll undoubtfully have noticed that I've spent the last couple of days at the GOTO Copenhagen conference.

If you look at my last couple of blogposts, that might surprise you, since they were about going to GOTO Aarhus, not GOTO Copenhagen. Well, that's because I am going to GOTO Aarhus in my capacity as a blogger, while I went to GOTO Copenhagen as a "civilian" (i.e. together with some of my colleagues). Since GOTO Copenhagen and GOTO Aarhus have the same sessions, this means that I probably get to see more of the sessions than anyone else, perhaps excluding the speakers themselves.

Even though I didn't go to GOTO Copenhagen as a blogger, it won't keep me from writing a bit about my impressions from the sessions I attended there - this also allows me to make some suggestions for what people should go to at GOTO Aarhus.

Below is my schedule during GOTO Copenhagen:

Thursday:

• New Linting Rules - Kyle Simpson (Enterprise Architecture)
• From 'Agile Hangover' to 'Antifragile Organisations' - Russell Miles (People & Process)
• Fast Delivery - Adrian Cockcroft (People & Process)
• Deep Dive into the Big Data Landscape - Part I - Eva Andreasson (Enterprise Architecture)
• Lean Enterprise - Part II - Jez Humble (People & Process)

 

Friday

• The Future of C# - Mads Torgersen (Enterprise Architecture)
• What I Learned About Going Fast at eBay and Google - Randy Shoup (People & Process)
• Responding in a timely manner - Microseconds in HFT or milliseconds in web apps, its all the the same design principles - Martin Thompson (Enterprise Architecture)
• A retake on the Agile Manifesto Part I - Katherine Kirk/Prag-Dave Thomas/Jez Humble/Tatiana Badiceanu/Martin Fowler (People & Process)
• A retake on the Agile Manifesto Part II - Katherine Kirk/Prag-Dave Thomas/Jez Humble/Tatiana Badiceanu/Martin Fowler (People & Process)

 

As with most conferences, there is a rating system, where one can indicate what you feel about a given session. At GOTO it is the classic green-yellow-red system. All of the sessions I attended, with one exception, I gave a green - and the one I gave a yellow, I actually think in hind-sight also deserved a green.

 

I should probably add that I give a green based on either of two critierias:

1. Was it interesting/informative/entertaining
2. Did I get new insights out of it

This means that theoretically a speaker can be less than stellar, but able to give me new insights, and then receive a green vote. In reality, however, this happens very rarely, so green votes are usually given to great speakers, who usually are also able to provide me insights.

 

 

 

Is the Agile Manifesto outdated?

Looking through the program for GOTO Aarhus, I saw that one of the tracks is about people and processes. This is a track they have had at GOTO Aarhus for some years, and one that I usually go to most talks at. After looking at the program, I don't think this year will be any different.

The reason I go to this track, is that I feel that the greatest challenges in software development is not related to technology, but rather to the interaction between people - exactly what this track is all about.

Looking back at all the conferences I've been to the last few years, it has been talks about organizations and processes that has challenged my world-views the most, forcing me to re-evaluate my assumptions, and decide whether or not they were right or not.

A simple example - last year I listened to talks by both Jez Humble and Dan North, where they mentioned the fact that one has to understand the trade-offs in order to make informed decisions. Otherwise you don't know whether it is the right choice for your situation or not. This is a simple message, and one which is easy to grasp on the surface, but also one it is easy to ignore, when there is a choice that seems obvious.

Lets take source control, which most of us would always insist on.

Source control is without a doubt a must in just about all projects where there is more than one person working on code (and the majority of projects where there is just one person working on the code). Does that mean that we should always use a source control system? Well, no - we need to look at the individual situation, and decided whether it is appropriate or not, evaluating the trade-offs.

In most cases the trade-off is between risk-reduction versus speed and/or cost. Here most would err on the side of risk-reduction, but it could be that speed is of such paramount importance, that the time to set up the source control would make the project worthless, and in that case, then risk-reduction would be the wrong choice.

Personally, I have never been in this situation, and find it highly unlikely I ever will, but it is important to keep it in mind, even when the choice seems obvious.

This is just one of the ways talks related to people and processes has changed my way of thinking.

Another obvious way such tracks have changed my way of thinking, is to make me more cautious about Agile and especially the Agile Manifesto.

At GOTO Amsterdam 2013, Kai Gib gave a interesting talk How to Focus Agile so it delivers Value to your Stakeholders, where he correctly pointed out that the Agile Manifesto has very little focus on actually providing value to the business side (though it does pay attention to value in the principles). Since providing value is the actual reason for doing a project, it would seem problematic that this is left out of the actual manifesto.

Kai Gibs talk, and similar talks I've heard the last few years, have left me wondering if perhaps it is time to retire the Agile Manifesto, or at least put less emphasis on it. Given the fact that I see it presented less and less often as part of slides at a talk, I don't think I am alone in feeling this way.

Actually, looking at the GOTO Aarhus program, it seems like that even the original signees of the Agile Manifesto might feel this way, since there are two sessions on the first day of the people and processes track called A retake on the Agile Manifesto (part 1 and part 2), where five people will be takein "a closer look at what has happened in the last 13 years since the Agile Manifesto was published and evaluate where the development community is going in the future".

Three of those five people are co-signers of the original manifesto (Martin Folwer, Andrew Hunt and Dave Thomas).

I am very much looking forward to these sessions, and to to what they will bring. Maybe something new and exciting will come out of it.

One thing is sure, I expect that I, and everyone else listening, will learn a lot.

GOTO Aarhus changes format

It is no secret that one of the conferences that I really love is the GOTO Aarhus conference which takes place at the end of September. I've been there the last couple of years as a blogger, and expect to go there in that capacity again this year.

One of the things I've loved about the GOTO conference is the format, where there are several concurrent tracks spread across 3 days, where some tracks take up a whole day, while some only take up half a day. Many of the tracks are related, but the format allows you to spread your attention and explore areas you don't really have much knowledge about, without having to invest too much of your conference time.

Given this, it is with a bit of worry that I see that GOTO Aarhus has cut down the length of the conference to two days, and at the same time changed the format, so there are 5 tracks (including the vendor track) running across both days.

This seems like a step back to me, removing the possibility of the more quirky tracks like the open data / eGov track last year, which was only half a day, but which had some really fascinating speakers, presenting unique perspectives and problems.

Now, such tracks would have to be embedded in one of the more mainstream tracks, which is something I highly doubt will happen, especially given the fact that the conference is now one day shorter.

Having said that, I am sure the conference will still be great, and given the quality of the speakers I can see on the list, I am still looking forward to going there. I just think that the chances of having my mind blown has been diminished.

GitHub as a recruitment filter

When I was at QCon San Francisco, I heard a talk about recruiting software engineers, and one of the points of the speaker, was that you should check out the GitHub profile of the candidates. This is something I found a little worrisome, not only because I don't have an (active) GitHub profile, but also because it seemed to me that this would lead you to exclude a number of good candidates.

I am all for open source, but I don't spend time on them, since I have enough work to do on work and non-programming related projects for me not wanting to add more to it. Does this make me a bad programmer? Perhaps. But probably not. Currently I am mostly doing business analytics (i.e. trying to help define the needs of the customer), but when I am on a project as a programmer, I tend to average more than a full days work each day - I could spend the overtime on open source projects, but I frankly don't see how this is a better use of my time, in the eyes of optential future employers.

There are also numerous other reasons why using GitHub profile as a recruitment filter is a bad idea, and there are two great blogposts that explains this:

Ashe Dryden: The Ethics of Unpaid Labor and the OSS Community
James Coglan: Why GitHub is not your CV

They should be read in the posted order, as Coglan's post is an expansion on Dryden's post.

We got to do better - diversity at conferences

I have just returned home from San Francisco, where I and nine of my colleagues, spent 3 days at the QCon San Francisco conference.

As often happens at these conferences, the gender diversity was not impressive - according to the speakers page, there were 7 women out of 110 speakers, and none of them were keynote speakers.

This is, to put it mildly, abyssal, and we got to do better.

On the last day of the conference, they displayed a slide of all the track hosts in the conference. When I saw it, I immediately thought to myself (and of course tweeted): I think I now understand the gender imbalance at the conference.

 

 

 

At conferences like QCon SF, track hosts are heavily involved in selecting the speakers, and they tend to look at their own network when doing so. Unless you've done an explicit effort towards that not happening, your network tends to look a lot like yourself, and when people like the track hosts use their network to get speakers, the speakers end up looking like themselves.

 



Not all track hosts are like that of course - one of the track hosts in that picture is Jez Humble, who is very much involved in fixing the gender imbalance (2 of his 5 track speakers were women), and who has written a great blogpost about this: How To Create A More Diverse Tech Conference. That blogpost should be required reading for all conference organizers, and certainly wasn't read (or at least not followed) by the QCon SF organizers.

If the organizers don't want to follow the guidelines laid out by Jez Humble, then they could consider something as simple as trying to find a couple of female track hosts. That alone should help in the gender imbalance. Or perhaps just ask the vendors if they could use female speakers, rather than male speakers, on the vendors track, if possible - I know that at least one of the vendors had a great female speaker sitting in the booth on the first day, and she could easily have spoken on either the vendor track or in one of the other tracks.

Before anyone goes on about conference organizers having to choose the greatest speakers they can get hold of, I will say that that has been addressed by Jez Humble in his blogpost, and that at QCon SF, the level of the speakers was generally sub-par compared to similar conferences I've been to the last couple of years (which includes both QCon London and QCon New York), so looking towards diversity probably would have increased the quality.