tag:blogger.com,1999:blog-75732298865795935462024-02-20T01:47:12.602-08:00Ending error-driven developmentA blog focused on programming, systems development, and IT consulting.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.comBlogger48125tag:blogger.com,1999:blog-7573229886579593546.post-37158988114994124292017-10-02T11:31:00.001-07:002017-10-02T11:31:59.227-07:00Not-done-here syndrome is mental lazinessThe provocative title of this post, is one of the many great points made by <a href="https://twitter.com/jessitron" target="_blank">Jessica Kerr</a> at the morning keynote at today's GOTO Copenhagen. The keynote was called "Forget Velocity, Let's Talk Acceleration"<br />
<br />
Jessica Kerr gave an energetic talk, which covered a lot of ground - enough for several blogposts, which I hopefully will get around to write in the next few days. This blogpost, however, will focus on the point expressed in the title.<br />
<br />
Most of us have come across developers, some of them quite good, who suffered from the <a href="https://en.wikipedia.org/wiki/Not_invented_here" target="_blank">not-invented-here syndrome</a>, i.e. they'll rather spent the time it takes to write the code themselves, instead of using existing code written elsewhere.<br />
<br />
There are probably cases where it makes sense to write it yourself, rather than reuse or modify code made elsewhere, but it is rarely the case. Usually, it takes a lot of time and effort, and it ends up being not as good as the code you could have gotten elsewhere.<br />
<br />
I've seen it happen from <a href="https://en.wikipedia.org/wiki/Object-relational_mapping" target="_blank">ORM</a> over logging frameworks to even an entire <a href="https://en.wikipedia.org/wiki/Ajax_(programming)" target="_blank">Ajax framework</a>.<br />
<br />
I have always assumed that this happened because of the arrogance of the developers in question, who thought they were better than everyone else.<br />
<br />
Not so, says Jessica Kerr - it is due to mental laziness.<br />
<br />
This is based on the principle that programmers find it easy to invent new things, but hard to analyze existing code. This means that it is <b>mentally</b> easier to write a framework yourself, rather than take in a framework written by someone else, and get to understand it.<br />
<br />
Or put differently, the mental energy you have to spent on writing the framework yourself is less than the mental energy you have to spent on learning a new framework.<br />
<br />
Thus, people who suffer from a not-invented-here syndrome, are mentally lazy.<br />
<br />
This resonates with me.<br />
<br />
One of the followup points that Jessica Kerr made, was that if you look at something, and think that you should rewrite it, then you should stop up, and make sure that it isn't just mental laziness that is speaking.<br />
<br />
It is often necessary to rewrite existing code, but rarely to the extend that developers and architects wants to do so. Rewriting the code, however, spares the developers and architects for the work they need to put into analyzing and understand the current code beyond the basic level.<br />
<br />
So, in conclusion, rewrite code if necessary, but make sure it is really necessary, and not just done to avoid the hard work of analyzing the existing code.<br />
<br />
<b>Disclosure: </b>This blogpost mentions the <a href="https://gotocph.com/" target="_blank">GOTO Copenhagen 2017</a>
conference. As a blogger who blogs about that conference, I get a free
ticket from the organizers. The organizers don't dictate what I write
about, and don't have any say about the content of the posts. <br />
<br />
<br />Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-13347748092448363722017-10-01T10:44:00.003-07:002017-10-01T10:44:39.898-07:00Progress is slow if you ignore the pastI have just returned from spending my Sunday at the 1st day of the 21st Danish <a href="https://gotocph.com/2017/" target="_blank">GOTO conference</a> (not all of them were named GOTO, there has been some name changes over the years).<br />
<br />
As expected, it was a great day, with some great talks - if you want to see my running commentary on those talks, go look at my Twitter stream <a href="https://twitter.com/kriswager" target="_blank">@kriswager</a><br />
<br />
Most of the talks I attended were great, but I especially enjoyed the keynote <a href="https://gotocph.com/2017/sessions/233" target="_blank">Engineering You</a> by Martin Thompson, and Dan North's talk <a href="https://gotocph.com/2017/sessions/187" target="_blank">Beyond Developer</a>, both of which focused on how software engineers/developers should expand their knowledge and become better programmers.<br />
<br />
Both of these talks started out by looking back at the roots of the field. Dan North took us all the way back to Ada Lovelace:<br />
<blockquote class="twitter-tweet" data-lang="en">
<div dir="ltr" lang="en">
Taking us back to the roots. <a href="https://twitter.com/tastapod?ref_src=twsrc%5Etfw">@tastapod</a> starts his talk with going back to Ada Lovelace <a href="https://twitter.com/hashtag/Gotocph?src=hash&ref_src=twsrc%5Etfw">#Gotocph</a> <a href="https://t.co/exmt9OcroE">pic.twitter.com/exmt9OcroE</a></div>
— Kristjan Wager (@kriswager) <a href="https://twitter.com/kriswager/status/914473699545423873?ref_src=twsrc%5Etfw">October 1, 2017</a></blockquote>
Martin Thompson, on the other hand, only took us back to 1967, where "software engineer" was coined. He spent some time on the 1968 Software Engineering conference sponsored by the NATO Science Committee, where many of the issues raised, and experiences expressed, would fit well into a conference today.<br />
<blockquote class="twitter-tweet" data-lang="en">
<div dir="ltr" lang="en">
It is interesting how little we have learned in 50 years. Words on slide is from meeting in 1968 <a href="https://twitter.com/hashtag/Gotocph?src=hash&ref_src=twsrc%5Etfw">#Gotocph</a> <a href="https://t.co/XV1AxclpmQ">pic.twitter.com/XV1AxclpmQ</a></div>
— Kristjan Wager (@kriswager) <a href="https://twitter.com/kriswager/status/914389469242982400?ref_src=twsrc%5Etfw">October 1, 2017</a></blockquote>
The above tweet only shows one of Martin Thompson's examples from the conference.<br />
<br />
While it is easy to despair over how little progress that has been over the last 50 years, I think it is probably better to think about it this way: while our methodologies change, the problems we face are the same, and it makes sense to look at what people did in the past, to see if they have solved problems we face today.<br />
<br />
A lot of people tend to think of pre-Agile days as a period of endless, mostly failing, waterfall projects, but the truth is, that this generally wasn't the case in the early days, and probably wasn't as common later, as legend makes it sound.<br />
<br />
It is worth remembering that back in the early days of the field, people were not only building programs, they were also building the tools (e.g. compilers) they needed in order to build programs. These tools have evolved since then, but they are still based on the same solutions that we base our tools on today. Why should solutions to organizational problems be any different?<br />
<br />
<b>Disclosure: </b>This blogpost mentions the <a href="https://gotocph.com/" target="_blank">GOTO Copenhagen 2017</a>
conference. As a blogger who blogs about that conference, I get a free
ticket from the organizers. The organizers don't dictate what I write
about, and don't have any say about the content of the posts. <br />
<br />
<br />
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-17970668941586388952017-09-25T07:22:00.001-07:002017-09-25T07:22:28.622-07:00My schedule at GOTO Copenhagen<a href="https://gotocph.com/2017/" target="_blank">GOTO Copenhagen 2017</a> is just around the corner, and I have taken a look at the talks that I definitely want to go to this year.<br />
<br />
Unlike earlier years, GOTO Copenhagen starts on a Sunday this year, which makes some demands to the quality of the speakers, trying to lure people in early Sunday morning.<br />
<br />
Luckily, the conference delivers - there are two keynotes on at 9:00, and while both looks interesting, I am going for <a href="https://gotocph.com/2017/sessions/233" target="_blank">Martin Thompson's talk</a>. I have heard him speak a number of times, and every time the talk have been engaging and informative.<br />
<br />
After the keynote, there are some interesting talks, but the next talk I really look forward to, is <a href="https://gotocph.com/2017/sessions/187" target="_blank">Dan North's Beyond Developer talk</a>. Not only does the talk sound interesting and relevant, I also know that anything Dan North presents is going to be fun.<br />
<br />
Skipping to the talks on Monday, I have spotted the following talks I'd be interested in: <br />
<ul>
<li><a href="https://gotocph.com/2017/sessions/210" target="_blank">Eoin Woods: Secure by Design – the Architect’s Guide to Security Design Principles</a> </li>
<li><a href="https://gotocph.com/2017/sessions/238" target="_blank">Emma Arfelt: Privacy in Software</a> </li>
</ul>
The many security breaches in recent months, shows that security is still a hugely important topic, which is all too often ignored or neglected. These two talks addresses different, but equally important, aspects of security.<br />
<br />
Tuesday, there is a track called <a href="https://gotocph.com/2017/tracks/40" target="_blank">Herding Cats: The Human Factor</a>, where I plan to spend most of my time, for reasons I explained in <a href="http://errordrivendevelopment.blogspot.dk/2017/09/the-importance-of-people-tracks-at-it.html" target="_blank">my last blog post</a><br />
<br />
Other than that track, I am looking forward to <a href="https://gotocph.com/2017/sessions/184" target="_blank">the end keynote by Linda Rising</a>. Linda Rising is one of the most engaging and brilliant speakers I have ever heard, and it is a pleasure to go to one of her talks.<br />
<br />
<b>Disclosure: </b>This blogpost mentions the <a href="https://gotocph.com/" target="_blank">GOTO Copenhagen 2017</a>
conference. As a blogger who blogs about that conference, I get a free
ticket from the organizers. The organizers don't dictate what I write
about, and don't have any say about the content of the posts. <br />
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-86187067887375961762017-09-14T11:01:00.001-07:002017-09-25T07:21:15.223-07:00The importance of peoples tracks at IT conferencesLet's talk about the importance of peoples tracks at IT conferences.<br />
<br />
Some IT conferences only focuses on technical issues, but some conferences,
such as the QCon conferences and the GOTO conferences always include a
peoples track.<br />
<br />
I generally go to these tracks if I have the chance, since I think they are important.<br />
<br />
Last month, James Damore published his now infamous open letter, where he wrote a screed against diversity in Google and the tech sector as a whole. The screed was not only incredibly scientific illiterate, but also clearly demonstrated the need for people tracks at conferences.<br />
<br />
<br />
In the upcoming <a href="https://gotocph.com/" target="_blank">GOTO Copenhagen 2017</a> conference, there is a <a href="https://gotocph.com/2017/tracks/40" target="_blank">people track</a> that illustrates why I think they are important.<br />
<br />
The track contains five talks:<br />
<ul>
<li>The Engineering-Manager Transition: How to take great engineers and make them great technical leaders</li>
<li>Stress and depression – a taboo in our time</li>
<li>Scaling Engineering Teams</li>
<li>The 2D Kitten Problem</li>
<li>Build the right thing: how to survive the accelerating rate of business change through experimentation</li>
</ul>
While these talks are all about people, they are quite diverse, allowing the listeners to learn from the experiences of others, and to see new perspectives.<br />
<br />
In the above list of talks, it is especially the second and the fourth talk that I think makes the track worth my time.<br />
<br />
The second talk, <i>Stress and depression – a taboo in our time</i> by Gitte Klitgaard<i>, </i>raises a subject which is all too rarely discussed, and which most of us are affected by - either directly or indirectly.<br />
<i><br /></i>
The fourth talk, <i>The 2D Kitten Problem</i> by Laura Laugwitz, is described thus:<br />
<blockquote class="tr_bq">
<div class="session__description">
"Diversity" is one of those buzzwords that alternates between being
supercharged and sadly hollow. While many tech companies like to boast
about their diversity programs, the numbers regarding their employees
don't change much. But that's no reason to give up on the concept of
diversity just yet! However, we need to re-examine what actually
constitutes this term in order to make it sustainable: Diversity is more
than hiring a few "different" people, it's about empowering oneself and
others to create positive change.</div>
</blockquote>
<br />
<blockquote class="tr_bq">
<div class="session__description">
This talk will give back some meaning to the term diversity while
illustrating why it's still important. There will be some interaction,
some tangible examples and more than a few cats to help you through the
more challenging parts of theories and self-reflection.</div>
</blockquote>
While it is highly unlike that James Damore would ever go to such a talk, it is talks like this that would have allowed Damore to understand the importance of diversity.<br />
<br />
It is not possible to reach Damore and his irk, but there are other people out there who are not aware of the importance of diversity, who can be reached through such talks. This is why I think people talks are important, and why I hope conferences keep having them.<b> </b><br />
<br />
<b>Disclosure: </b>This blogpost mentions the <a href="https://gotocph.com/" target="_blank">GOTO Copenhagen 2017</a> conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com1tag:blogger.com,1999:blog-7573229886579593546.post-30978682173738064962017-09-14T10:14:00.001-07:002017-09-14T10:18:08.427-07:00Tearing down the walls<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br />
It is pretty widely accepted that one of the major challenges for IT projects is communications between the different parties involved.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTfKqS6z1dpms0qBB9tDBqGUd2UC7Mb3KQUtQnHa1LR-Q_3g0rXX8u7zxv3tr64LqoCxj45KvYgfMK3zZaSQEDaoLVvePJ2GjkDuD1Jltq3hE4kfqXFysWkpyr3QwQD9Ow52mhsOsoWEk/s1600/All+walls.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="405" data-original-width="1033" height="124" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTfKqS6z1dpms0qBB9tDBqGUd2UC7Mb3KQUtQnHa1LR-Q_3g0rXX8u7zxv3tr64LqoCxj45KvYgfMK3zZaSQEDaoLVvePJ2GjkDuD1Jltq3hE4kfqXFysWkpyr3QwQD9Ow52mhsOsoWEk/s320/All+walls.png" width="320" /></a></div>
<br />
<div class="" style="clear: both; text-align: left;">
The above figure demonstrates how a traditional IT project works, and why communication is such a big issue.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="" style="clear: both; text-align: left;">
The business have some wishes, which they give to the requirement people, who turns them into requirements, which are handed over to the development team. The development team then develops the system, and hands it over to testing. When the system is tested, it is handed over to operations, which puts it into production.</div>
<div class="" style="clear: both; text-align: left;">
<br /></div>
<div class="" style="clear: both; text-align: left;">
Such a process is characterized by each group being walled off from each other, often in a real physical sense. It is also characterized by a lack of communications between the groups.</div>
<div class="" style="clear: both; text-align: left;">
This means that it can take a long time to find misunderstandings, and that the requirements tend to become outdated before they reach production.</div>
<div class="" style="clear: both; text-align: left;">
<br /></div>
<div class="" style="clear: both; text-align: left;">
SCRUM and other Agile methods have tried to address this in different ways, but even so, communications problems still exists.</div>
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNAMvqbexPav4p1F7WUxfwwU3YNC0g_e9T0U0xr_0D1QT9eEXhChmSSBbe4sjE2NBwwaeSDUevB0pCNHMexyDKQPMV-q_8uj4-4-YAp_RXJ-Wo_0TmLaQVu6Zi1E8LAUtpIW7BxGDBZuY/s1600/Scrum+team+walls.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="396" data-original-width="963" height="131" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNAMvqbexPav4p1F7WUxfwwU3YNC0g_e9T0U0xr_0D1QT9eEXhChmSSBbe4sjE2NBwwaeSDUevB0pCNHMexyDKQPMV-q_8uj4-4-YAp_RXJ-Wo_0TmLaQVu6Zi1E8LAUtpIW7BxGDBZuY/s320/Scrum+team+walls.png" width="320" /></a></div>
The above figure illustrates an IT project using SCRUM. Here the developers and testers form one team, and the requirements specification is handled by a PO who represents the business.<br />
<br />
Due to the processes in SCRUM, the communication barrier between the PO and the SCRUM team is reduced, but there is still a barrier. Also, in most organizations, the barrier between the business and the PO is unfortunately as great as the barrier between business and requirements people in traditional projects.<br />
<br />
There is also a communication barrier between the SCRUM team and operations.<br />
<br />
The fairly recent concept of DevOps have tried to address the
communication barrier between the SCRUM team and the operations people. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiLB8BFuM9aMrkQXVBZND4WZ6ms22rjfSKbx746QbAdi7aaT33oPR88TGSXnsiq7WjUfb_NAxwZhnRZWOVyl2lY05c3pEH93TCUc83Z7MkthhFQqQin4XkJkhqKHPfnCCA56pC9BIWOsY/s1600/SCRUM+team+DevOps.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="388" data-original-width="791" height="156" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiLB8BFuM9aMrkQXVBZND4WZ6ms22rjfSKbx746QbAdi7aaT33oPR88TGSXnsiq7WjUfb_NAxwZhnRZWOVyl2lY05c3pEH93TCUc83Z7MkthhFQqQin4XkJkhqKHPfnCCA56pC9BIWOsY/s320/SCRUM+team+DevOps.png" width="320" /></a></div>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
As the above figure illustrates, this is handled by embedding the operations people in the SCRUM team (this is obviously a simplified description).<br />
<br />
Last November I was at a conference in Orlando, where one of the speakers were the PO for the SCRUM process, and he told us that there is a focus on adding DevOps to the SCRUM methodology.<br />
<br />
Unfortunately, he also said that they are not going to do anything about adding requirements specification to the methodology.<br />
<br />
This is, in my opinion, unfortunately, as it would help reduce the barrier between the business and the rest of the project, and between the PO and the SCRUM team.<br />
<br />
So, what can be done instead, in order to remove the barrier between the business and the rest of the project?<br />
<br />
Well, I think it will be hard to completely remove the barrier, but I think there are different ways of reducing the communication barrier.<br />
<br />
These are, in random order:<br />
<ul>
<li>Embedding a business person in the SCRUM team</li>
<li>Regular meetings</li>
<li>Techniques such as story mapping</li>
</ul>
These can obviously be combined.<br />
<h4>
Embedding a business person in the SCRUM team</h4>
This is an idea that was introduced with eXtreme Programming, though it probably existed before that as well.<br />
<br />
It is simply getting someone from the business sitting together with the SCRUM team.<br />
<br />
This is often hard to do, as it can be hard to get people released from their normal position in order to place them in an IT project, even if they continue to work on what they usually work with. This is partly due to the, probably reasonable, concern that the person will have much less time to do their job. But it is also often partly due to the fact that many bosses don't like not having people sitting apart from their usual team. On top of that, it might be hard for the business to see the value of embedding the business person in the SCRUM team. <br />
<br />
If you manage to get a business person embedded with the SCRUM team, it is worth regularly evaluating whether the business person is the right person for the role, or whether there should be a rotation of the business people, in order to keep the focus fresh.<br />
<br />
<h4>
Regular meetings</h4>
A simple, but effective way of enabling communication between the business and the rest of the project, is to plan frequent meetings.<br />
<br />
The sprint reviews in the SCRUM methodology is one type of frequent meetings, but there should be other meetings, such as requirements meetings between the PO and the business.<br />
<br />
These meetings can be used for presenting user stories before they are taking into a sprint, in order to get the input from the business, and clarify any unclear requirements. It can also be used to prioritize the requirements, based on the current situation, and to adjust the scope of the project, based on any developments.<br />
<h4>
Techniques such as story mapping</h4>
Requirements in SCRUM projects are often written as user stories, and there are some techniques that can be used while writing these, allowing the business to get involved.<br />
<br />
One of these methods is <a href="http://jpattonassociates.com/user-story-mapping/" target="_blank">user story mapping</a>.<br />
<br />
No matter what technique is used, it is important that to ensure that the business are willing to get fully involved. If they are not committed, no technique will help reduce the communication barrier.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxb6tcyUhyphenhyphenyCx0IkEkI08-bRGOCdOPlmRTdIm-iPdm1G_lKSTQ7Q0KBNbOa1uCMWSrIMv3IXdmLELRKJA0DJ7lUT3XfK1PtRSMGW97jAyAiJLVr9Ak29312XaVQWCN3osC3RsTxHwBjDY/s1600/Target.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="247" data-original-width="782" height="101" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxb6tcyUhyphenhyphenyCx0IkEkI08-bRGOCdOPlmRTdIm-iPdm1G_lKSTQ7Q0KBNbOa1uCMWSrIMv3IXdmLELRKJA0DJ7lUT3XfK1PtRSMGW97jAyAiJLVr9Ak29312XaVQWCN3osC3RsTxHwBjDY/s320/Target.png" width="320" /></a></div>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
In conclusion, it is unlikely that it is completely possible to reduce the communication barriers completely in an IT project, but there are methodologies, concepts, and techniques that can greatly reduce them, allowing for a greater likelihood of the successful development of a system which fulfills the needs of the business.<br />
<br />
One aspect I haven't touched on in this post, is the extra complications if the project isn't aimed at the internal business, but rather at customers outside the organization. External customers obviously adds an entirely extra complexity to communications, and is a subject for an entirely different blogpost.<br />
<br />
<br />
<br />Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-27902743198437421332016-10-03T13:27:00.000-07:002016-10-03T13:27:14.132-07:00Impressions from the first day of GOTO Copenhagen 2016I have just returned home after spending the whole day at GOTO Copenhagen 2016, listening to great speakers talking about software development.<br />
<br />
As I wrote in my <a href="http://errordrivendevelopment.blogspot.dk/2016/09/what-i-want-to-see-at-goto-copenhagen.html" target="_blank">last post</a> on GOTO Copenhagen, I had planned to spend the day watching the <i>Effective Delivery </i>track, and this is what I did.<br />
<br />
For someone like me, who works with projects in the public sector, this was a fantastic track.<br />
<br />
The first talk was Tony Grout's <i>Hand to hand with a gorilla won't work</i>, about how you introduce agile in a very large organization. <br />
<br />
Basically, it takes a lot of effort, and some cunning, and it won't be pure, but as Grout said, "good luck with pure". Sometimes you have to be pragmatic in order to reach your goal.<br />
<br />
One interesting thing that Grout said, was that a fairly simple, yet very effective tool, is an ordered list across the organization, allowing everyone to know what they should focus on first. Introducing such a list in Skype, increased the productivity ten-fold.<br />
<br />
Next up was Jez Humble's <i>When DevOps Meets Regulations: Integrating 'Continuous' with 'Government'</i><br />
<br />
This talk was about the efforts of introducing DevOps in government projects in the US. A big barrier to this are the regulations they have to follow when making "information systems".<br />
<br />
<blockquote class="twitter-tweet" data-lang="en">
<div dir="ltr" lang="en">
A partial list of regulations that <a href="https://twitter.com/jezhumble">@jezhumble</a> have to remember when launching government system in the US. Seems similar to Denmark <a href="https://twitter.com/hashtag/gotocph?src=hash">#gotocph</a> <a href="https://t.co/DZxepcDubP">pic.twitter.com/DZxepcDubP</a></div>
— Kristjan Wager (@kriswager) <a href="https://twitter.com/kriswager/status/782885221406502912">October 3, 2016</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
As I write in my tweet, the list doesn't seem overly long to me, compared to what we experience in Denmark. As the talk progressed, however, I realized that the US process for fulfillment is much more cumbersome than the Danish one, and it definitely needs an overhaul.<br />
<br />
One cool thing that Jez Humble introduced us for, is <a href="https://cloud.gov/" target="_blank">an open source cloud platform</a> for government projects in the US. This seems like a great idea, and I'd love to see something similar in Denmark.<br />
<br />
After the US, the turn came to the UK, in the form of Stephen Forshew-Cain's <i>Building an effective delivery culture</i>, where he talked about the Digital Service and its culture.<br />
<br />
I am planning on writing a longer blogpost about Jez Humble's and Stephen Forshew-Cain's talks and how they relate to the Danish situation, so I won't go further into the talk here.<br />
<br />
Having spent some time on government projects, the time came for talking about effective teams - this came in the form of Camille Fournier's <i>Building a High-Performance Team is Everyone's Job. </i>This was the title in the program, but she had given it a different name at the time of the talk (the title is unfortunately on a photo in my phone which has run out of power).<br />
<br />
I had never heard Camille Fournier speak before, but I will most certainly do so again, if I ever get the chance.<br />
<br />
It was a very amusing, and highly informative talk, where she spoke about her experiences, and what she had learned from them, when it came to leadership.<br />
<br />
<blockquote class="twitter-tweet" data-lang="en">
<div dir="ltr" lang="en">
"I came from finance where it was OK to yell at people. Apparently that's not the case everywhere" <a href="https://twitter.com/skamille">@skamille</a> on early mistakes <a href="https://twitter.com/hashtag/gotocph?src=hash">#gotocph</a></div>
— Kristjan Wager (@kriswager) <a href="https://twitter.com/kriswager/status/782933421907554304">October 3, 2016</a></blockquote>
last, but not least, on the track, Emily Webber gave her talk <i>Communities of practice, the missing piece of your agile organisation</i>, in which she talked about how to create communities of practice inside your organisation.<br />
<br />
All of the talks were great, and I certainly got a lot out of them. Hopefully the same will be the case tomorrow, when I spend my time at the <i>Tactics for better Teams</i> track.<br />
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-52036224995877778732016-09-21T03:20:00.000-07:002016-09-21T03:21:46.570-07:00It is time for Danish politicians to form an opinion on IT projects in the public sectorAs in most other countries, public IT projects have a bad reputation in Denmark. It seems that most people think that the public sector is horrible at doing IT projects (much worse than the private sector), and that the majority of public sector IT projects fail. <br />
<br />
This perception is caused by a number of very big IT projects failing, causing not only the loss of the money put into them, but also the loss of state revenue, due to necessary IT infrastructure not being in place in order to e.g. ensure that tax refunds are paid correctly.<br />
<br />
In my opinion, the public perception is wrong on two areas:<br />
<ol>
<li>The public sector is no worse than the private sector at doing IT projects.</li>
<li>The majority of public sector IT projects go well.</li>
</ol>
<div>
The reason for both of these misperceptions is that people don't hear about projects that fail in the private sector, nor about IT projects in the public sector that does well. </div>
<div>
<br /></div>
<div>
But even with this caveat, there is no doubt that there is uncomfortable large number of IT projects that fail in the public sector, having a negative impact on the Danish economy.</div>
<div>
<br /></div>
<div>
Given this, I think it is remarkable how little the Danish political parties seem to care about IT projects in the public sector. </div>
<div>
<br /></div>
<div>
The politicians generally seem to care only on the most superficial level, saying that the public sector need to get better at doing IT. If they go beyond that, they generally focus on ensuring that laws are not getting in the way of implementing new IT systems and work rutines.</div>
<div>
<br /></div>
<div>
I think it is great that they are willing to take a look at how the laws in a given area might get in the way of eg. digitalization, but this is not enough. The head of the Danish Business Authority, which has just gone through a fairly succesful five year modernization program, has stated that it is frequently not laws that gets in the way, just interpretations and existing workflows.</div>
<div>
<br /></div>
<div>
It is often not clear that the interpretations and workflows will get in the way of development of the new systems, before the actual development work starts.</div>
<div>
<br /></div>
<div>
So, in other words, it is not enough that politicians look at the laws, they also have look at fostering an environment, where it is not only OK, but pretty much required, for public servants to reevaluate interpretations and workflows. For this to be possible, it is necessary to get them directly involved in the IT projects, not only as end-users, but also as sparring partners for the developers. This requires that resources are put aside for this.</div>
<div>
<br /></div>
<div>
Another area where I'd like politicians to focus, is creating an environment where different ministries, departments, and agencies learn from one another. There are some great attempts at this on the local level (eg. some departments look around at other departments to see what works before they start up), but it has to be structured better, and the responsibility anchored in one place. </div>
<div>
<br /></div>
<div>
There are a lot of experience spread across the different ministries, departments and agencies, but all too often it cannot be easily located, and each IT project is cause of re-learning everything from scratch.</div>
<div>
<br /></div>
<div>
A good attempt of drawing on the experiences of others, is the use of <a href="http://www.digst.dk/Styring/Itprojektraadet" target="_blank">IT-projektrådet</a> to evaluate the risks of IT projects larger than 10 million kroner and to follow up on high risk projects. </div>
<div>
This is only done to federal projects however, and not on projects on the municipality level or regional level, even when they are much larger than 10 million kroner. </div>
<div>
<br /></div>
<div>
Obviously there are other areas where politicians could, and should, form an opinion on IT projects in the public sector, but I think that the areas mentioned above are some of the more important ones.</div>
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-650003198044187572016-09-18T04:06:00.002-07:002016-09-18T04:06:50.394-07:00What I want to see at GOTO Copenhagen 2016I have taken a look at the schedule of <a href="https://gotocon.com/cph-2016/" target="_blank">GOTO Copenhagen 2016</a>, trying to figure out what I want to see.<br />
<br />
On <a href="https://gotocon.com/cph-2016/schedule" target="_blank">Monday the 3rd</a>, there are a few interesting tracks for me.<br />
<br />
First of all, the description of the <i>Effective Delivery</i> track sounds very intriguing:<br />
<blockquote class="tr_bq">
Anyone with less than 15 years in IT has never known a time when there wasn’t Scrum or XP, or cross-functional teams or automated tests. They take these things for granted, but they also believe this is the state-of-the-art. Mainstream agile methods are around 20 years old now, and the world has moved on. Planning every 2 weeks makes sense if you have a 3 month release window, but what about if you are releasing every week, or even several times a day? Servers are now an inexpensive commodity, and cloud infrastructure means my expensive data center is now someone else’s pay-per-use model. How are modern practitioners taking advantage of this? What about challenges like large-scale delivery, regulated government departments, or heavyweight corporates? And how can you navigate a career when half the companies on your CV no longer exist? This track passes a critical eye over the current delivery landscape, and hopefully gives you some tools and techniques for navigating the modern world of Effective Delivery.</blockquote>
I like that the track takes for granted that we understand the basics of Agile development, as most of us have worked with it our whole career, and build upon this.<br />
<br />
It is highly likely that I will spend most of the day at this track, and there are a couple of talks I definitely won't want to miss. One of these is Jez Humble's <a href="https://gotocon.com/cph-2016/presentations/show_talk.jsp?oid=7754" target="_blank">When DevOps Meets Regulation: Integrating 'Continuous' with 'Government'</a>. As someone that works primarily with projects related to the public sector, this certainly sounds like something that I can use in my daily work. The same is probably true for Stephen Foreshew-Cain's talk <a href="https://gotocon.com/cph-2016/presentations/show_talk.jsp?oid=7755" target="_blank">Shepherding Government towards Effective Delivery</a>, but there is no description of this talk yet.<br />
<br />
If I am not at the <i>Effective Delivery</i> track, I'll probably be at the <i>Deep Learning Analytics</i> track, where there are several interesting talks, including Michael Hunger's <a href="https://gotocon.com/cph-2016/presentations/show_talk.jsp?oid=7745" target="_blank">How the Investigative Journalists of the ICIJ used modern Open Source Technologies to unearth the stories of the Panama Papers</a>, where <a href="https://neo4j.com/" target="_blank">Neo4j</a> will play a major part of the talk. Neo4j is a technology I have followed for years, and I would love to hear about how it was utilized by news organizations, so they could map the data.<br />
<br />
On <a href="https://gotocon.com/cph-2016/schedule" target="_blank">Tuesday the 4th</a>, there is no doubt that I will be spending my day at the <i>Tactics for better Teams </i>track. The track is described thus:<br />
<br />
<blockquote class="tr_bq">
Let's get practical. Often small simple changes have a huge positive
effect on team performance and work-life satisfaction. This track
presents a set of simple tactics that you can bring home to your team
and start using today to make a better team. The track will present both
technical ideas like software visualisation as well as more process
oriented initiatives.
</blockquote>
The reason I'll be spending my day at this track, is partly that it is the track that is most related to my daily work, but mostly because of the speakers on the track. Of the speakers, the only one I don't know if I have seen before is Corey Haines. The rest of the speakers of the tracks are people that I don't only know I have seen before, but also know that I love - especially Linda Rising, who is a brilliant speaker.<br />
<br />
Hadn't that been the case, I'd probably have spent some time on the <i>Microservices</i> track, trying to figure out what all the hype is about.<br />
<br />
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-77280210559878221702016-09-12T05:51:00.001-07:002016-09-12T05:51:43.846-07:00The Dangers of ConferencesIn just under a month, it is time for <a href="http://gotocon.com/cph-2016/" target="_blank">GOTO Copenhagen 2016</a>, which is the 20th anniversary of the GOTO conferences (which started out as JAOO). I am looking forward to listening to some great speakers and network with other participants and the vendors.<br />
<br />
When talking with other people in the field of IT, I often come across people whose employers won't pay for conferences, and sometimes even won't let them take time of to go there.<br />
<br />
I have in the past tried to make <a href="http://errordrivendevelopment.blogspot.dk/2013/09/why-you-should-allow-your-employees-to.html" target="_blank">the case for allowing employees to go to conferences</a>, but I think it is time to also acknowledge and address the dangers of allowing employees to go to conferences. <br />
<br />
The rest of this post will list the major explanations I've heard, and try to address them.<br />
<br />
<b>1. The company only work with legacy systems, and all the new stuff mentioned at the conferences is irrelevant for us.</b><br />
<b><br /></b>
A conference like GOTO doesn't only present new languages and technology, but also have sessions on methods, architecture and many other things that are several layers of abstraction away from actually systems development.<br />
<br />
Even if your company doesn't make use of the newest technology, conferences present a rich source for re-evaluating current practices, and address inefficiencies in the current setup. Many, if not all, of the speakers have not only worked on cutting edge <a href="https://en.wikipedia.org/wiki/Greenfield_project" target="_blank">greenfield projects</a>, but also on brown-field projects, that have turned into <a href="https://en.wikipedia.org/wiki/Big_ball_of_mud" target="_blank">big balls of mud</a>, so they understand the need for taking such projects into account.<br />
<br />
<b>2. When my employee go to a conference, they will met people from other companies, and be tempted to go there.</b><br />
<b><br /></b>
There is an old anecdote about a the leaders of a company talking to a consultant, and asking "what if we train our employees, and they all leave?" To which the consultant answers, "what if you don't train them, and they stay?".<br />
<br />
If you are afraid that the employees will leave if they hear about conditions at other companies, maybe you should address the conditions at your company, rather than letting them get worse, by not allowing people to go to conferences.<br />
<br />
Also, have you considered the idea that the employee might convince other people to check out your place as a potential workplace?<br />
<br />
<b>3. If I allow one employee to go to a conference, everyone wants to go.</b><br />
<div>
<b><br /></b></div>
<div>
First of all, I don't think that is true. In most companies, there is a large group of employees who don't particularly like going to conferences, and thus won't ask for it.</div>
<div>
<br /></div>
<div>
But even if that's the case, then I don't really think it is a problem. There might be an economic limit to how many can go, but that can probably be solved by creating a turnus, where employees get to go on alternate years. </div>
<div>
<br /></div>
<div>
If a large group of employees go, then they can either use the conference as a team event (if they work together), or as a way to get to know people in other parts of the organization better (if they don't work together). Either way, it makes for a closer knit mass of employees.</div>
<div>
<br /></div>
<div>
<b>4. Conferences are expensive</b></div>
<div>
<br /></div>
<div>
"Expensive" is relative. IT employees are usually highly paid, and hard to recruit. For many good IT people, conferences are a factor when considering whether to stay or change jobs.</div>
<div>
<br /></div>
<div>
If someone changes jobs, the cost of replacing that person is much, much higher than the cost of allowing them to go to a conference.</div>
<div>
<br /></div>
<div>
<b>5. My employees will get frustrated over hearing about new tech that they can't use</b></div>
<div>
<br /></div>
<div>
Yes, this is a real risk, but there are ways around that. Maybe allowing them to slowly introduce new tech in their current projects, or by allowing them some "play time" to build tools and other programs that can help them in their daily life.</div>
<div>
<br /></div>
<div>
Trying to keep them away from learning new tech is only going to work for the most incurious of employees. If you are fine with your employees not wanting to keep up to date on their field, that is fine, but if that's not the case, then you have to find a different solution than keeping them from konferences.</div>
<div>
<br /></div>
<div>
<b>6. My employees will try to implement the newest fad after the conference</b></div>
<div>
<br /></div>
<div>
Somewhat related to point 5. Yes, this is a risk, but you can limit the risk by ensuring that the employee get an outlet for their creativity.</div>
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-73602993619114719902016-09-04T02:07:00.002-07:002016-09-04T02:29:42.533-07:00Is microservices the new SOA?Within the last couple of years, Microservices has become all the rage of systems development.<br />
<br />
Microservices, like many other terms in systems development, doesn't have an exact definition, but I found a good working description at <a href="http://martinfowler.com/articles/microservices.html" target="_blank">an article by Martin Fowler and James Lewis</a>:<br />
<blockquote class="tr_bq">
<i>The term "Microservice Architecture" has sprung up over the
last few years to describe a particular way of designing software
applications as suites of independently deployable services. While
there is no precise definition of this architectural style, there
are certain common characteristics around organization around
business capability, automated deployment, intelligence in the
endpoints, and decentralized control of languages and data.
</i></blockquote>
Looking at the description, there is nothing that doesn't reasonable, and reading the article linked above, it becomes clear that Microservice Architecture is a valid way of building systems, and one that should be taken into consideration when designing a system.<br />
<br />
Unfortunately, it seems like people don't really consider it, but rather just choose it by default.<br />
<br />
A decade ago Service Oriented Architecture was all the rage, and all systems had to be based on SOA. Unfortunately a lot of people didn't understand SOA and thought it was all about having a servicebus as the central component through which all communication went through. This was so widespread that I and many others started to say that SOA stood for <i>Servicebus</i> Oriented Architecture.<br />
<br />
It seems like Microservice Architecture is moving down a similar path. <br />
<br />
Many systems supposedly based on Microservice Architecture are not really based upon it, but rather on a misunderstanding of what Microservices are all about, creating systems which mimics the properties of Microservice Architecture, but don't implement the actual characteristics of Microservices.<br />
<br />
Some symptoms of this misunderstanding of Microservices, could be:<br />
<ul>
<li>Code dependencies between services. If code changes to one services means that you also have to change the code of other services, then the architecture doesn't fulfill the concept of independently deployable services.</li>
<li>Functionality dependencies between services. If the system always have to call service A before service B, and only call service A when service B needs to be called, then it seems like the lines of the system hasn't been drawn the right place.</li>
<li>The need for a service portal (or even a servicebus).</li>
</ul>
<div>
There could be good reasons for each of these symptoms (though I am hard pressed to think of one for the first one), but they are definitely something that should make you consider whether you have really created a Microservice Architecture, or if you have just peppered your system with services.</div>
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com3tag:blogger.com,1999:blog-7573229886579593546.post-50791052643043147892016-08-29T03:15:00.000-07:002016-08-29T03:17:42.102-07:00Think smallerOver at my other blog, I mentioned the fact that the Danish Tax Department is going to go through a major overhaul (<a href="http://freethoughtblogs.com/kriswager/2016/08/28/denmark-overhauls-its-tax-department/" target="_blank">Denmark overhauls its tax department</a>).<br />
<br />
One of the major triggers for this overhaul, is the problems that the Tax Department have had with creating new IT systems in recent years. Two major IT systems have failed - one which was going to calculate the taxation value of property, and another which was going to be used to collect overdue taxes and other debt to the state.<br />
<br />
The failure of these IT projects have cost billions of dollars in both wasted development costs and in lost revenue to the state of Denmark.<br />
<br />
As a frontrunner to the overhaul of the Tax Department, the Ministry of Taxation had already decided to not let the Tax Department do the development of the property system but instead do it themselves. This was a major break away from the traditional roles of the Ministry and the Department, where the Ministry was focused on law-making, while the Department had the responsibility of enforcing the laws (e.g. collect the taxes), and make the systems necessary to do so.<br />
<br />
As part of the Ministry of Taxation's decision of taking the responsibility of developing the property evaluation system, they also decided to do it in-house, rather than using public tenders to get it developed.<br />
<br />
I was recently at a talk given by Steen Larsen, the head of development at the Ministry of Taxation, called "A New Way of Doing Public IT", where he explained the things they had done to create a succesful project, which would deliver a working system on time.<br />
<br />
This was very interesting, though I think the title was overselling it a bit, as there are several public agencies and departments which do much of the same as what he described.<br />
<br />
Listening to the talk, and seeing the ideas behind the overhaul of the department, I can't help worry if they have identified the right problem. <br />
<br />
It seems to me that they still have a tendency to think in large monolitic systems. <br />
<br />
As Steen Larsen described it, the IT system they were building was both a system for evaluating the properties, and for the case workers to do their work. <br />
<br />
It seems to me, that it should be possible to split these areas of concern up, so they could be considered two different systems, and making the sizes somewhat more manageable. Generally, this allows for a greater chance of success.<br />
<br />
Hopefully, the tendency of thinking in monolitic systems is only when they describe the systems, and not when they do the actual development.<br />
<br />
<br />Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-47819757424947883652016-08-29T02:24:00.001-07:002016-08-29T02:24:55.087-07:00Project managers vs Product ownersI frequently come across discussions on the internet about using project managers as product owners in Agile projects.<br />
<br />
These discussions often spring out of discussions on what the role of a traditional project manager is in an Agile project, and since project managers often prioritize work in traditional projects, it makes sense to think of using them as product owners, who, after all, should prioritize the work that the developers do.<br />
<br />
I disagree.<br />
<br />
When Scrum was created, and the roles of Scrum Master and Product Owner came into existence, the people who got those roles, were the traditional project managers - at least according to what Jeff Sutherland said when I got my Scrum Master certification at his course.<br />
<br />
That probably made sense back then, but I think it is a bad idea to do so now, for several reasons.<br />
<br />
<b>First</b>, and foremost, I think it is a bad idea, because you need the project manager to focus on the project and its priorities. Unless you run an extremely agile project, there is still a need for a project manager taking care of the non-development aspects of the project (e.g. resource planning, dependency management with other projects, and other tasks ignored by Scrum and other Agile methods). In other words, project managers need to focus on the restraints and barriers of the project, and ensure that these doesn't affect the project and its progress.<br />
<br />
Product owners, on the other hand, should represent the business/customers, ensuring that they get the most value out of the project as they can, within the boundaries set by the project manager.<br />
<br />
<b>Secondly</b>, I think the skillset required to be a good project manager is orthogonal to the skillset required to be a good product owner, and it is best to use people in the role they fits the best.<br />
<br />
A good project manager is good at forecasting and evaluating risks for the projects, ensuring that the people inside the project can perform optimally. A good product owner, on the other hand, understands the needs of the business/customers, and can translate this in a way that the developer team (including testers) can understand. This is why good product owners often are business analysts with a developer or tester background.<br />
<br />
<b>Thirdly</b>, in most projects, being a product owner is a full time job. The number of developers in a project generally outnumbers the product owner by a fair margin, and having the product owner do project management as well, will slow the project down - or at least limit the number of developers that can be in the project.<br />
<br />
All of the above is based on the premise that projects still need project managers, even if the development process (e.g. Scrum) doesn't call for it. If that's not the case, then the only relevant objection is my second point, about the necessary skillset being quite different.<i> But this is a major point! </i>In my experience, the role of the product owner is essential for the success of an agile project, and all too often, the selection of the product owner is taken too lightly.<br />
<br />
If you want to find a good place for your project manager, look at the Scrum Master role, which has many similarities, focusing on sheltering the developers and create the framework for the development process.<br />
<br />Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-53560440182994348352015-10-05T22:38:00.002-07:002015-10-05T22:39:19.710-07:00Looking back on the first day of GOTO Cph - missing a bit of edgeI am at GOTO Copenhagen these days, and thought I'd post a quick overview on my thoughts on the conference.<br />
<br />
First of all, unlike last year, it seems like the venue is too small for the conference. It is hard to get around, and many of the sessions are filled up 10 minutes before they start. It was said that the conference would be at a different venue next year, which I think is a good idea.<br />
<br />
The first keynote was by <a href="https://twitter.com/Doctor_Astro" target="_blank">Dr. Sengupta</a> and was about the Mars Curiosity Rover. It was absolutely fantastic, and when there were some technical problems with the sounds in the middle of the talk, she managed that brilliantly as well.<br />
<br />
Then there were the sessions. <br />
<br />
I mostly went to talks in the tracks "game changing methods and practices" and "fast and continuous delivery".<br />
<br />
I am not going to talk about the individual sessions, but I am going to quote a couple of tweets I wrote during the sessions there<br />
.<br />
<blockquote class="twitter-tweet" lang="en">
<div dir="ltr" lang="en">
It is probably due to me being at too many conferences, but I'd love more craziness at process/methods track <a href="https://twitter.com/hashtag/gotocph?src=hash">#gotocph</a> please blow me away!</div>
— Kristjan Wager (@kriswager) <a href="https://twitter.com/kriswager/status/651032074216951808">October 5, 2015</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
<br />
<blockquote class="twitter-tweet" lang="en">
<div dir="ltr" lang="en">
As it is, the talks fell too safe. Doesn't challenge the audience. We learn, but our minds are not expanded <a href="https://twitter.com/hashtag/GOTOcph?src=hash">#GOTOcph</a></div>
— Kristjan Wager (@kriswager) <a href="https://twitter.com/kriswager/status/651032752272355328">October 5, 2015</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
<br />
There is no doubt that the process/method track gave us new techniques for doing Agile, but in my opinion, it would have been greater if the process/method track would have challenged us, and made us re-evaluate how we do systems development, rather than just provide new tools for doing it the same way.<br />
<br />
An example of how this could have been done, would have been to find some organization that did waterfall projects with success, and get them to come an tell us about how they manage. One such organization is probably NASA, since I have a hard time imagining that the software for the systems used for landing the Mars Curiosity Rover was developed in an Agile project.<br />
<br />
I think many of us would have loved to have our preconceptions challenged this way.<br />
<br />
What I wrote could equally apply to the "fast and continuous delivery" track.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-67436680695198827692015-09-20T02:19:00.000-07:002015-09-20T02:19:02.607-07:00Code of conducts at conferencesLooking at the <a href="http://gotocon.com/cph-2015/" target="_blank">GOTO Copenhagen website</a>, I notice that there is a <a href="http://gotocon.com/cph-2015/antiharassmentpolicy/" target="_blank">code of conduct</a> linked at the bottom. The only reason why I found it, was probably because I went looking for it.<br />
<br />
As far as I know, this is the first year that has one for a GOTO conference in Denmark, though there might have been one last year as well.<br />
<br />
I am quite happy to see one, since I wasn't sure that there would be one, as Danes seems to have an aversion against codes of conducts for some reason or other. Earlier this month, I was at the <a href="https://coldfrontconf.com/" target="_blank">Coldfront</a> conference, which does have a <a href="http://confcodeofconduct.com/" target="_blank">code of conduct,</a> but where one of the organizers felt it was necessary to half-apologize for it.<br />
<br />
I am glad to see that code of conducts become more widespread, since I think they are necessary in order for conferences to become more inclusive.<br />
<br />
A code of conduct is important to conferences, especially with an international crowd, for several reasons:<br />
<ol>
<li>It sets up clear boundaries of acceptable behavior.</li>
<li>It helps enable people to speak out if they feel harassed or uncomfortable.</li>
<li>It explains people what they should do, in case of harassment.</li>
<li>It helps unveil the scope of the problem.</li>
</ol>
In regards to the first point, many people say that it shouldn't be necessary, and to some degree I agree, but unfortunately, experience shows us that it is necessary - especially at conferences where there is a large disparity between the genders.<br />
<br />
It is also worth remembering that at an international conference, there will be people will different social and cultural backgrounds, and there are different boundaries in different cultures and social circles.<br />
<br />
Regarding the point about enabling people to speak out, the existence of a code of conduct demonstrates that the conference cares about the well-being of all the participants. This in turn, encourages people to speak out when they feel that the boundaries are being pushed. <br />
<br />
Since it often comes as a surprise for people that they are making others feel uncomfortable with their jokes or behavior, it allows those people to change their behavior in ways that makes it a pleasant occasion for everyone.<br />
<br />
And even if there are some people that don't care if they are making other people uncomfortable, then there is the option of reporting them, which the code of conduct should provide clear instructions for.<br />
<br />
For the organizers, it also means that they will hear about serious incidents straight away, and not through some backdoor channel long after the fact.<br />
<br />
I think most of us would prefer that there was no need for a code of conduct, but history has shown us that this isn't the case, and it would be naive to think that if we ignore the problem, it will just go away. Instead, provide a code of conduct which provides clear boundaries and guidelines.<br />
<br />
It seems like GOTO Copenhagen is more or less adopting the <a href="http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy" target="_blank">code of conduct provided</a> by the Ada Initiative. Note that it has a public version, and an internal version for the conference staff, which includes clear instructions on how to enforce the code of conduct.<br />
<br />
The later part is an important part of the code of conduct, which all too often was lacking in the past, creating situations where conference staff either overreacted or ignored any reports they received, and where documentation of incidents were non-existent - allowing some conferences to claim that there had been no reports of harassment at their conferences, even though several people have reported such.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-80451097920227459572015-08-22T08:40:00.000-07:002015-08-22T08:40:49.341-07:00Social science and systems developmentA couple of weeks ago, I wrote a blogpost on <a href="http://errordrivendevelopment.blogspot.dk/2015/08/agile-and-pseudo-science.html" target="_blank">Agile and pseudo-science,</a> which led to an interesting discussion on my Facebook wall about the lack of science and data in systems development. <br />
<br />
As I wrote in my post, there is an unfortunately tendency of systems developers to rely on pseudo- or popular science, rather than proper science. A lot of decisions are made on assumptions for which there is no real evidence, but which somehow has become embedded in the world of systems development - be it project management, programming, testing, or some other aspect.<br />
<br />
We tend to think of systems development as off shot of computer science with some cognitive psychology thrown in. While computer science and cognitive psychology certainly are important for creating systems, they are very much related to the "systems" part of systems development, while they hardly add to the processes, methods etc. that adds up to the "development" part.<br />
<br />
A comment in the before-mentioned Facebook discussion suggested that we should look at social science when talking about science and systems development.<br />
<br />
This seems like a good idea to me. A lot of what goes on in systems development is about humans interacting with each other, rather than about math, algorithms, cryptography or other aspects of computer science.<br />
<br />
I once worked on a project where we had a horrible high turnover, which is definitely a well-known sign of a doomed team. Yet this team was one of the best teams you could imagine - continuously over-performing in the sense of delivering over scope, under budget and without flaws. From everything we know about team dynamics, this team should not have performed like this, but it did, and it could have been good to have had someone qualified there to analyse how this could be the case.<br />
<br />
Equally it would be good to have someone look at the opposite type of teams - the ones which in theory should perform well, but which continuously under-perform. The ones where good developers suddenly seem unable to actually finish anything, where simple requirements turn into hideous bloated things, and where the only cure seems to be to kill of the team, never to let them work together again.<br />
<br />
In both cases we know the anomalies relate to people, the interaction between them, and the culture of the team and the organization surrounding it. We just don't seem to be able to figure out how to create the first type of team, while avoiding the second type. <br />
<br />
Given how many systems development projects fail, maybe it is worth looking at these things? And if we do, maybe we should try to find the proper tools? <br />
<br />
Social science would seem like a good fit, and it would seem like a good idea for large organizations with many systems development projects, to take a look at how the research methods of social science could be applied to systems development, in order to become better at it.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-12277954415119087922015-08-22T07:56:00.001-07:002015-08-22T07:59:58.214-07:00What 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
So... onwards to my list.<br />
<br />
The first talk I noticed was Richard Lander's <a href="http://gotocon.com/cph-2015/presentation/How%20to%20train%20your%20corporation%20to%20prefer%20open%20source" target="_blank">How to train your corporation to prefer open source</a>. <br />
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.<br />
<br />
I don't usually go to IOS-related talks, but I might just go to Jorge D. Ortiz Fuentes' <a href="http://gotocon.com/cph-2015/presentation/Test%20Driven%20Development%20(by%20controlling%20dependencies)" target="_blank">Test Driven Development (by controlling dependencies).</a> <br />
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.<br />
<br />
Other than the mentioned talks, I will probably spend the rest of the first day listening to talks in either <a href="http://gotocon.com/cph-2015/tracks/show_track.jsp?trackOID=1150" target="_blank">the Game Changing Methods and Practices track or the Fast and Continous Delivery track</a>.<br />
<br />
On the second, and final, day of the conference, there are four tracks that all sounds interesting - <em>Reactive Architectures</em>, <em>The State of Data</em>, <em>Front-end: The Bleeding Edge</em>, and <em>Security, Safety and Privacy.</em><br />
<em></em><br />
In the first track, Reactive Architectures, I am probably going to Jonas Bonér's <a href="http://gotocon.com/cph-2015/presentation/The%20Sadness%20at%20the%20End%20of%20the%20Happy%20Path" target="_blank">The Sadness at the End of the Happy Path</a> and Dave Farley's <a href="http://gotocon.com/cph-2015/presentation/Reactive%20Systems:%2021st%20Architecture%20for%2021st%20Century%20Systems" target="_blank">Reactive Systems: 21st Architecture for 21st Century Systems.</a><br />
Building resilient and high-performance systems is hard to do, and any ideas on how to do it better, are definitely welcome. <br />
<br />
If I am not going to Dave Farley's talk, I will certainly be going to Dave Thomas' <a href="http://gotocon.com/cph-2015/presentation/The%20State%20of%20Data%203" target="_blank">The State of Data 3</a>.<br />
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.<br />
<br />
A talk that sounds interesting, is Phil Winder's <a href="http://gotocon.com/cph-2015/presentation/Modern%20Fraud%20Prevention%20using%20Deep%20Learning" target="_blank">Modern Fraud Prevention using Deep Learning</a>, which is at the same time slot as Andreas Halberg's <a href="http://gotocon.com/cph-2015/presentation/Secure%20Coding%20Patterns" target="_blank">Secure Coding Patterns</a> - another talk that sounds useful for when developing systems.<br />
<br />
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.<br />
<br />
<em>D<strong>isclaimer:</strong></em> 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.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-35814739753973686922015-08-02T05:22:00.000-07:002015-08-12T10:58:17.761-07:00Agile and pseudo-science<div>
Back before I started blogging about IT-related stuff, I used to write about pseudo-science on my other (very quiet) blog <a href="http://kriswager.blogspot.dk/" target="_blank">Pro-science</a>, and before I had that blog, I used to comment a lot on a number of science and skeptic blogs.</div>
<div>
<br /></div>
<div>
First commenting and later blogging about science and pseudo-science has helped enable me to be better at detecting <a href="http://rationalwiki.org/wiki/Woo" target="_blank">woo</a> and pseudo-science in my daily life. <i>Woo</i> is a term used in the <a href="http://rationalwiki.org/wiki/Sceptic" target="_blank">skeptic community</a> to indicate something which is based on anti-science and have no scientific validity or data to back it up.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
One such area is the field of Agile.</div>
<div>
<br /></div>
<div>
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 <a href="http://www.agilemanifesto.org/" target="_blank">the agile manifesto</a>, 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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
This summer, I went to a conference which had a talk on <i>Agile and NLP</i>. I didn't go to the talk, so I can't say anything about the actual content, but let's be perfectly clear: <b>NLP is <a href="http://www.scientiareview.org/pdfs/327.pdf" target="_blank">pseudoscience</a> </b>(.pdf) - see also <a href="http://www.tomaszwitkowski.pl/attachments/File/NLP.pdf" target="_blank">Thirty-Five Years of Research on Neuro-Linguistic Programming. NLP Research Data Base. State of the Art or Pseudoscientific Decoration?</a> by Tomasz Witkowski (.pdf).</div>
<div>
<br /></div>
<div>
If you do a search on the words "Agile" and "NLP", you'll find articles like <a href="http://blogs.msdn.com/b/jmeier/archive/2013/09/13/nlp-patterns-and-practices-for-high-performance-teams-and-achievers.aspx" target="_blank">NLP Patterns and Practices for High-Performance Teams and Achievers</a> 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. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
This is, unfortunately, widespread in the field, and not just when it relates to NLP.</div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
In 2012, Steven Poole wrote an article for The New Stateman on the subject of popular science books on neuroscience, called <a href="http://www.newstatesman.com/culture/books/2012/09/your-brain-pseudoscience-rise-popular-neurobollocks" target="_blank">Your brain on pseudoscience: the rise of popular neurobollocks</a>. 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.</div>
<div>
<br /></div>
<div>
E.g., as a rule, one should expect anything written by Malcolm Gladwell <a href="http://www.slate.com/articles/health_and_science/science/2013/10/malcolm_gladwell_critique_david_and_goliath_misrepresents_the_science.html" target="_blank">to be wrong</a>.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
Just a pity that the science is often presented simplistic at best and wrong at worst.</div>
<div>
<br /></div>
<div>
Some speakers, such as <a href="https://twitter.com/risinglinda" target="_blank">Linda Rising</a> and <a href="https://twitter.com/kevlinhenney" target="_blank">Kevlin Henney</a>, 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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
This is obviously connected to the other problems. Lack of data, leads to bad conclusions.</div>
<div>
<br /></div>
<div>
A simple example of the lack of data, is this: <i>How do we know Agile works? </i></div>
<div>
<br /></div>
<div>
Or put in another way: <i>On what basis do we conclude that Agile works better than what was there before?</i></div>
<div>
<br /></div>
<div>
As far as I've been able to find out, there is no real data to support such claims.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
People tend to compare Agile to Waterfall, but as Laurent Bossavit wrote in his excellent book <a href="https://leanpub.com/leprechauns" target="_blank">The Leprechauns of Software Engineering</a>, 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. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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?</div>
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-58444629120848648222014-09-29T03:09:00.000-07:002014-09-29T03:09:07.399-07:00Privacy should be a priorityEver 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 <a href="http://www.tbray.org/" target="_blank">Tim Bray</a>, who debuted a new talk at <a href="http://gotocon.com/cph-2014" target="_blank">GOTO Copenhagen</a> called "Privacy and Security, Policy and Tech".<br />
<br />
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 <a href="http://gotocon.com//aarhus-2014/" target="_blank">GOTO Aarhus</a>.<br />
<br />
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.<br />
<br />
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:<br />
<br />
<blockquote class="tr_bq">
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.</blockquote>
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 <span lang="EN-US" style="font-family: "Times New Roman","serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: DA;">perfectly </span>legal things become illegal. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Again, quoting (or rather, paraphrasing) Tim Bray:<br />
<blockquote class="tr_bq">
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.</blockquote>
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
This has to change.<br />
<br />
<span lang="EN-US" style="font-family: "Times New Roman","serif"; font-size: 12pt; mso-ansi-language: EN-US; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: DA;">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.<o:p></o:p></span><br />
<br />
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.<br />
<br />
This is the reason why Google encrypts its user's traffic (they were actually <a href="http://boingboing.net/2013/08/16/little-brother-inspired-google.html" target="_blank">inspired by Cory Doctorow's book Little Brother</a>).<br />
<br />
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.<br />
<br />
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-20446032315904939112014-09-28T01:25:00.001-07:002014-09-28T01:25:37.034-07:00Size doesn't matterBig data. <br />
<br />
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 <a href="http://www.davethomas.net/" target="_blank">Dave Thomas</a> and <a href="http://jimwebber.org/" target="_blank">Jim Webber</a>, 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).<br />
<br />
This is the sort of things I think of when I hear the words "big data".<br />
<br />
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).<br />
<br />
It turns out that I've basically misunderstood the concept of big data, and that I underestimated the amount of data out there.<br />
<br />
At GOTO Copenhagen, I went to a talk with <a href="http://gotocon.com/aarhus-2014/speaker/Eva+Andreasson" target="_blank">Eva Andreasson</a>, 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-5027865426574303742014-09-27T09:06:00.000-07:002014-09-27T09:06:38.324-07:00Aim for the starsOne 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.<br />
<br />
The organizers behind the GOTO conferences are, in my opinion, particularly good at this.<br />
<br />
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.<br />
<br />
At GOTO Copenhagen, there were several such talks, but one of them stands out in particular.<br />
<br />
<blockquote class="twitter-tweet" lang="en">
Very moving keynote speech by <a href="https://twitter.com/russolsen">@russolsen</a> on the moon landing and the lessons we can learn from it <a href="https://twitter.com/hashtag/GOTOcph?src=hash">#GOTOcph</a><br />
— Kristjan Wager (@kriswager) <a href="https://twitter.com/kriswager/status/515406416967139328">September 26, 2014</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
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.<br />
<br />
At GOTO Copenhagen it was Russ Olsen who gave his "To the Moon" talk.<br />
<br />
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.<br />
<br />
So, what was so great about Russ Olsen's talk?<br />
<br />
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.<br />
<br />
Russ Olsen also has a great message - <a href="http://er.jsc.nasa.gov/seh/ricetalk.htm">quoting Kennedy</a>, he reminds people that they shouldn't do something because it is easy, but because it is hard, and that nothing is impossible.<br />
<br />
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 <a href="http://russolsen.com/blog/2014/02/13/to-the-moon-talk/" target="_blank">found online</a>.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-42414444509400850752014-09-27T08:37:00.001-07:002014-09-27T08:37:12.264-07:00Ahead of my timeIf you follow me on twitter, you'll undoubtfully have noticed that I've spent the last couple of days at the GOTO Copenhagen conference. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Below is my schedule during GOTO Copenhagen:<br />
<br />
<strong>Thursday:</strong><br />
<ul>
<li><div class="subject">
New Linting Rules - Kyle Simpson (Enterprise Architecture)</div>
</li>
<li>From 'Agile Hangover' to 'Antifragile Organisations' - Russell Miles (People & Process)</li>
<li>Fast Delivery - Adrian Cockcroft (People & Process)</li>
<li>Deep Dive into the Big Data Landscape - Part I - Eva Andreasson (Enterprise Architecture)</li>
<li>Lean Enterprise - Part II - Jez Humble (People & Process)</li>
</ul>
<div class="subject">
</div>
<div class="subject">
<strong>Friday</strong></div>
<ul>
<li>The Future of C# - Mads Torgersen (Enterprise Architecture)</li>
<li>What I Learned About Going Fast at eBay and Google - Randy Shoup (People & Process)</li>
<li>Responding in a timely manner - Microseconds in HFT or milliseconds in web apps, its all the the same design principles - Martin Thompson (Enterprise Architecture)</li>
<li>A retake on the Agile Manifesto Part I - Katherine Kirk/Prag-Dave Thomas/Jez Humble/Tatiana Badiceanu/Martin Fowler (People & Process)</li>
<li>A retake on the Agile Manifesto Part II - Katherine Kirk/Prag-Dave Thomas/Jez Humble/Tatiana Badiceanu/Martin Fowler (People & Process)</li>
</ul>
<div class="subject">
</div>
<div class="subject">
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. </div>
<div class="subject">
</div>
<div class="subject">
I should probably add that I give a green based on either of two critierias: </div>
<ol>
<li><div class="subject">
Was it interesting/informative/entertaining</div>
</li>
<li><div class="subject">
Did I get new insights out of it</div>
</li>
</ol>
<div class="subject">
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.</div>
<div class="subject">
</div>
<div class="subject">
</div>
<div class="subject">
</div>
Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-8434639156203571882014-08-10T05:35:00.001-07:002014-08-10T05:38:23.623-07:00Is the Agile Manifesto outdated?Looking through the program for <a href="http://gotocon.com/aarhus-2014/schedule/monday.jsp" target="_blank">GOTO Aarhus</a>, 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Lets take source control, which most of us would always insist on. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This is just one of the ways talks related to people and processes has changed my way of thinking.<br />
<br />
Another obvious way such tracks have changed my way of thinking, is to make me more cautious about Agile and especially the Agile Manifesto.<br />
<br />
At GOTO Amsterdam 2013, Kai Gib gave a interesting talk <a href="http://gotocon.com/amsterdam-2013/presentation/How%20to%20Focus%20Agile%20so%20it%20delivers%20Value%20to%20your%20Stakeholders" target="_blank">How to Focus Agile so it delivers Value to your Stakeholders,</a> 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.<br />
<br />
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.<br />
<br />
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 <em>A retake on the Agile Manifesto </em>(<a href="http://gotocon.com/aarhus-2014/presentation/A%20retake%20on%20the%20Agile%20Manifesto%20Part%20I" target="_blank">part 1</a> and <a href="http://gotocon.com/aarhus-2014/presentation/A%20retake%20on%20the%20Agile%20Manifesto%20Part%20II" target="_blank">part 2</a>), 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".<br />
<br />
Three of those five people are co-signers of the original manifesto (Martin Folwer, Andrew Hunt and Dave Thomas).<br />
<br />
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. <br />
<br />
One thing is sure, I expect that I, and everyone else listening, will learn a lot.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-48483782308186228122014-06-22T10:01:00.004-07:002014-06-22T10:02:10.194-07:00GOTO Aarhus changes formatIt is no secret that one of the conferences that I really love is the <a href="http://gotocon.com/aarhus-2014/" target="_blank">GOTO Aarhus</a> 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.<br />
<br />
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.<br />
<br />
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 <a href="http://gotocon.com/aarhus-2014/tracks/" target="_blank">5 tracks</a> (including the vendor track) running across both days.<br />
<br />
This seems like a step back to me, removing the possibility of the more quirky tracks like the <a href="http://gotocon.com/aarhus-2013/tracks/show_track.jsp?trackOID=861" target="_blank">open data / eGov track</a> last year, which was only half a day, but which had some really fascinating speakers, presenting unique perspectives and problems.<br />
<br />
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.<br />
<br />
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 <a href="http://errordrivendevelopment.blogspot.dk/2011/10/reversed-roles.html" target="_blank">having my mind blown</a> has been diminished.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-36643777887640069332013-11-16T13:25:00.001-08:002013-11-16T13:27:01.412-08:00GitHub as a recruitment filterWhen 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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
Ashe Dryden: <a href="http://ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community" target="_blank">The Ethics of Unpaid Labor and the OSS Community</a><br />
James Coglan: <a href="http://blog.jcoglan.com/2013/11/15/why-github-is-not-your-cv/" target="_blank">Why GitHub is not your CV</a><br />
<br />
They should be read in the posted order, as Coglan's post is an expansion on Dryden's post.<br />
<br />Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com0tag:blogger.com,1999:blog-7573229886579593546.post-61551553646947710362013-11-16T09:16:00.000-08:002013-11-16T13:26:04.356-08:00We got to do better - diversity at conferencesI have just returned home from San Francisco, where I and nine of my colleagues, spent 3 days at the QCon San Francisco conference.<br />
<br />
As often happens at these conferences, the gender diversity was not impressive - according to the <a href="http://qconsf.com/speakers" target="_blank">speakers page</a>, there were 7 women out of 110 speakers, and none of them were keynote speakers.<br />
<br />
This is, to put it mildly, abyssal, and we got to do better.<br />
<br />
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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_SdbXeo6NeoPJP3YrpWzgSTUbttUuqZ2hml1CWqwG48NzE-v_U81e4POcRODesqOYnctMbZPwpMjOLMqXTslNAE8SVlXkVf_kWMwcSfIlYx19oOmtUIH6y9J5wdMfIY1YMt-hJ_7l3IQ/s1600/20131113_084853%5B1%5D.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_SdbXeo6NeoPJP3YrpWzgSTUbttUuqZ2hml1CWqwG48NzE-v_U81e4POcRODesqOYnctMbZPwpMjOLMqXTslNAE8SVlXkVf_kWMwcSfIlYx19oOmtUIH6y9J5wdMfIY1YMt-hJ_7l3IQ/s320/20131113_084853%5B1%5D.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: left;">
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.</div>
<div class="separator" style="clear: both; text-align: left;">
</div>
<div class="separator" style="clear: both; text-align: left;">
</div>
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: <a href="http://continuousdelivery.com/2013/09/how-we-got-40-female-speakers-at-flowcon/" target="_blank">How To Create A More Diverse Tech Conference</a>. 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.<br />
<br />
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.<br />
<br />
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.Kristjan Wagerhttp://www.blogger.com/profile/09555892468280743919noreply@blogger.com2