28 December 2017

Interview Gabriel Grill

I have known Gabriel since a long time. We met at an early meetings of the Java User Group Vienna many years ago. I noticed him sharing content concerning diversity. It was just a matter of time until I would make him share his views ;-)

Gabriel, please introduce yourself. Why did you choose to become a software developer?
My name is Gabriel Grill. Currently I am writing my Master's Thesis at the University of Technology, Vienna, and work at the Austrian Centre for Digital Humanities at the Austrian Academy of Sciences. I started programming in high school (HTL). My main reasons for choosing the field at that time were the possibilities for earning money afterwards and the high probability of having a secured job in the future. After I got to know programming more, I liked how seamless one could use this skill to create things, the puzzle solving aspects of it and the creativity one needs to find solutions. I always tried not to focus too much on computing only. Consequently - at university - I took lectures in the social sciences, was politically involved, played the drums, did theatre and so on.

brosI know that you are concerned with sexism. For example I noticed you sharing content about women in technology. Why does that matter to you?
I believe it is important to be socially engaged in groups, organisations, etc. one is a part of and try to improve conditions for marginalised people there. Inclusion helps everybody. I very much recommend to watch this video on gender-inclusive software design by Distinguished Professor Margaret Burnett, which explains this point much better then I could.

My engagement in tech is not limited to barriers women have to face, I think structural discrimination against this group is still a very big issue in the community. Structural means that the discrimination is ingrained into the culture, normalised, and thereby one has to actively learn, reflect and work against exclusionary mechanisms to change the status quo. In male majority communities, such as the developer community, often so called "bro" cultures emerge. They have certain unwritten rules of how one should act and look like, to be a part of them. An example to me is the beer with "the guys" after work. Bonds are often formed there which in turn may help the people participating to advance in their careers. But there are people who are not into that or do not have the time. Similarly smoke breaks allow those who participate to connect more. Another example, which I have noticed several times in conversations or talks at conferences, are various forms of sexualisation or objectification through jokes or comments, which have exclusionary effects. These seemingly small things together make up a culture in which some have it easier to be a part of. Many of these mechanisms are not unique to developer communities but prevalent in society. The "Pop Culture Detective" is a great YouTube-Channel with many videos on reflections of portrayals of culture in media. I recommend its videos on the "Big Bang Theory" and nerdom especially to male developers (Part 1 - The Adorkable Misogyny of The Big Bang Theory, Part 2 - The Complicity of Geek Masculinity on the Big Bang Theory). I think we all would benefit a lot from a more inclusive and reflective community where for instance I, as a man, would not have to act and dress in certain ways to feel "normal". I would love if our community was much more about supporting one another and thinking about how to improve society.

What other topics are you concerned about?
I usually do political work in the contexts I am directly involved in. Consequently I have been doing a lot of student politics working against different types discrimination based on income, gender, race, accessibility at university. I believe in Austria we have a special responsibility to reflect and remember our past and work against right wing tendencies that want to divide society. In this manner, I want to point to Karl Popper's "Paradox of tolerance" which states: "Unlimited tolerance must lead to the disappearance of tolerance. We should therefore claim, in the name of tolerance, the right not to tolerate the intolerant." I try to take part in protests or actions that I am fond of and generally work on awareness through campaigns.

I am also interested in net politics, privacy and ethics of programming or more generally algorithmic systems. I have created a seminar lecture at TU Wien together with professor Tompits and my colleague Matthias Fassl to enable students to read scientific papers on ethical and social aspects of such systems and have interesting discussions. I try to talk at events or conferences sometimes to raise points I find important. I think generally as developers we need to spend more time on reflecting and learning how to build systems for people. This entails taking diversity into account and creating software which is not only tailored for a small subset of people who are well-off anyway but also useful to people with little money or single parents. I educate myself through lectures mostly in the social sciences, blogs and papers. I recommend to look through YouTube and Twitter, and consume content of people who belong to marginalised groups, such as Feminist Frequency, Kat Blaque and Annie Elainey. There is a lot to learn about other experiences.

I think global warming is a big issue and my actions here are more on a personal level like eating only little meat.

Outside your personal topics discussed till now, what do you consider the biggest challenges (for humanity)?
That is a very tough question to answer. I think it would be arrogant of me to answer this question bluntly. Depending on your circumstances the answers would be very different. For instance to me climate change is a big issue, but there are many people out there who see this differently. I think it is very important to explain to them that doing nothing makes things worse, but there may be no universal human challenges on which everybody completely agrees on. As a middle European, white, male, able-bodied, computer science student to me climate change may be a big issue at the moment, but for people who are starving or live in poverty other priorities apply.

Many developers would probably answer this question somehow similar because it is still a very homogeneous group. That is why I believe questions like this should be asked to people with different backgrounds to get a better answer. This would necessarily include most people that are part of the global South. I think as developers we should look more outside our own bubbles to grow our perspectives. I consider dealing with remnants of colonialism as a very important issue and in turn exploitation of the global South as well as weapon trading and war. Most of the other issues I have mentioned in the previous question.

Speak up, make your voice heardWhat do you do to engage in the topics? For example, did you take part in public protests, donate money to NGOs or sign petitions?
I do things like trying to eat less meat and use public transport as much as possible, but ultimately I think most important are policies. The issues mentioned in the previous questions should be tackled collectively through democratic processes by engaging in a political party or other organisation, raising awareness through events or activism and learning on what issues are there and what they really are about. I do many of these things and the ones you mentioned in the question as well, but still time and money is limited and you have to prioritise.

I would like to see more impact of my regular work on these important topics. Do you think that is possible in general?
I do not know if it is possible in general, but I think as developers we are in the position to be able to choose were we want to work. We can ask critical questions, have a positive influence on the projects we work on, raise awareness on issues in the organisation we are a part of and so on. If many developers, consumers and other stakeholders are keen on social and ecological values, businesses will adapt. On the positive side, it seems that social responsibility is becoming a more important topic to many companies at the moment. I believe often more policy is necessary, e.g. to foster fairer working conditions and payment for people in the global south. I think little things like supporting people, talking to colleagues about political issues, learning about ethics or working on improving diversity, are contributions that should be highly valued. Unfortunately a lot of this kind of work, especially care labour, is not paid.

Which guidance do we have to navigate professional decisions? Did you take specific decisions because of your values and social responsibility?
I think it is important as a developer to be aware of your responsibilities and educate yourself on how to deal with them. The social sciences, political science and philosophy or more specific the fields of social informatics and human computer interaction have a lot of knowledge on how to navigate when being faced with political decisions. I strongly suggest to read more literature from these fields.

I want my development to be human-centred. I think about for whom I create something, am I really inclusive, is it ethical or bad for others and how can I best include stakeholders in the decision processes. These question usually do not have a trivial answer and that is why it is important to give them attention.

I have not encountered a situation where I was asked to write a piece of code which I considered to be very unethical, but I am aware that I have made ethical decision myself when coding. In my Master's Thesis I use text mining methods to extract information from news articles. There are many parameters to tune and models to choose and depending on my choices the results will be different. It is my obligation to document this process very well. How I get results and how I present these results is very political. I suggest reading this article which critiques a study that claims to be able to identify sexual orientation through images given to a trained machine learning system.

How do you think about selecting industry, customer and project based on your values and social responsibility?
I think one definitely should take their values and the social responsibility of the company into account. I would not be willing to work for a arms manufacturing company. Thorough research is required here because some companies do not state directly that their work or research may have a secondary use in armed conflicts. I would not like to work at companies in the gambling business or with a focus on surveillance.

DiversityDo you have problems with any industries?
It depends on the context very much. I would not want to work for an animal factory but if there is not another option or the factory is somehow vital I would probably reconsider. I think I am not able to give a general answer here, but animal factory and weapon manufacturing are as close as it gets to a no for me. This includes companies like Thales or Glock.

Did you ever reject a customer based on your values?
I did not need to reject a project offer so far, but I have chosen consciously not to apply to certain companies. During my studies I have chosen my projects in a way I felt they could benefit society.

On the other hand, what would be projects that you would love to work on?
At the moment I consider to go into research and work on ethical and social implications of algorithmic systems. I think research in this area could be useful to society. The current trend is towards putting more decision making algorithms in our lives but when these are mostly developed by a homogeneous group with almost no education on ethical and political issues, this becomes a democratic problem on who gets to decide what the algorithms do or what their optimisation goals are. Big companies are looking into these topics, due to critique from the public. I like developing very much. Working on projects that support marginalised people in some way would be interesting, like working on accessibility, support for campaigns or apps against hate. Projects that are very interesting from a technological point of view would also be options for me.

Thank you Gabriel.

12 December 2017

Code Cop Knit Doll

Sometimes I present books to individual developers. On one side I am thanking them for "listening" to me - that is the good collaboration and supporting me - and on the other side I want to push them more into reading mandatory books. In preparation for Christmas I gave away a few pieces of Bad Tests, Good Tests by my friend Tomek Kaczanowski. Now imagine how surprised I was when Corinna repayed me with a Code Cop knit doll:
Code Cop Doll (click for high resolution image)
This is amazing. I love the number of detail she put on it:
  • I am obviously a cop with both gun (on my right side) and handcuffs (on my left side). The doll is also showing my age, especially the wild hair, grey beard and round belly. ;-)
  • There is the Ruby Logo on my police cap and chest. I did not know how much I evangelise the use of Ruby. It is true, Ruby is my favourite programming languages, although I am not using it that often any more.
  • I am going nowhere without my own keyboard, so there has to be a Das Keyboard in front of me at all times.
  • One of my mantras in trainings is to "Refactor Mercilessly". It seems I am using that one a lot.
Merry Xmas Everybody!

3 December 2017

PMD Check and Report in same build

lane one, lane twoI am working together with senior developer and (coding) architect Elisabeth Blümelhuber to set up a full featured continuous delivery process for the team. The team's projects use Java and are built with Maven.

Using PMD for Static Code Analysis
After using Jenkins for some time to run the tests, package and deploy the products, it was time to make it even more useful: Add static code analysis. As a first step Elisabeth added a PMD report of a small set of important rules to the Maven parent of all projects. PMD creates a pmd.xml in the target folder which is picked up by Jenkins' PMD Plugin. Jenkins displays the found violations and tracks changes over time, showing a basic trend graph. (While SonarQube would be more powerful, we decided to stay with Jenkins because the team was already "listening" to it.)

Breaking the Build on Critical Violations
I like breaking the build on critical violations to ensure the developers' attention. It is vital, though, to achieve the acceptance of the team members when changing their development process. We thus started with a custom, minimal set of rules (in src/config/pmd_mandatory.xml) that would break the build. The smaller the initial rule set is the better. In the beginning of adding static code analysis to the build process, it is not about the code but getting the team aboard - we can always add more rules later. The first rule set might even contain a single rule, e.g. EmptyCatchBlock. Empty Catch blocks are a well known problem when analysing defects and usually developers agree with the severity of having them in the code and accept breaking the build for that. On the other hand, breaking the build on minor or formatting issues is not recommended in the beginning.

Here is the snippet of our pom.xml that breaks the build:
        ... other settings
This is more or less taken directly from the PMD Plugin documentation. After running the tests, PMD checks the code.

Keeping a Report of Major Violations
We wanted to keep the report Elisabeth had established previously. We tried to add another <execution> element for that. As executions can have their own <configuration> we thought that this would work, but it did not. PMD just ignored the second configuration. (Maybe this is a general Maven issue. For example the Maven Failsafe Plugin is a copy of the Surefire plugin to allow both plugins to have different configurations.)

The PMD plugin offers a report for the Maven site which is configured independently. As a workaround for the above problem, we used the site report to check the rules listed in src/config/pmd_report.xml. The PMD report invocation created the needed target/pmd.xml as well as a readable target/site/pmd.html.
    ... other plugins
        ... other settings
Skipping Maven Standard Reports
Unfortunately mvn site also created other reports which we did not need and which slowed down the build. Maven standard reports can be selected using the Maven Project Info Reports Plugin. It is possible to set its <reportSet> empty, not creating any reports:
    ... other plugins
            <!-- empty - no reports -->
Now it did not create the standard reports. It only generated target/site/project-reports.html with a link to the pmd.html and no other HTML reports. Win.

Skipping CPD Report
By default, the PMD plugin invokes PMD and CPD. CPD is checking for duplicate code - and is very useful - but we did not want to use it right now. As I said before, we wanted to start small. All plugins have goals which are explained in the documentation. Obviously the Maven report invokes PMD plugin's goals pmd:pmd and pmd:cpd. How do we tell a report which goals to invoke? That was the hardest problem to solve because we could not find any documentation on that. It turned out that each reporting plugin can be configured with <reportSets> similar to the Maven Project Info Reports Plugin:
    ... same as above
Putting Everything Together
We execute the build with
mvn clean verify site
If there is a violation of the mandatory rules, the build breaks and Maven stops. Otherwise site generates the PMD report. If there are no violations at all, Maven does not create a pmd.html. There is always a pmd.xml, so Jenkins is always happy.

(The complete project (compressed as zip) is here.)

29 November 2017

Interview Rea

Palestinians Collect Belongings from Gaza RuinsThe last Coderetreat was one of the rare Coderetreats that I was participating instead of organizing. I used the opportunity to pair with strangers and Rea was one of my partners. We came to talk about the sponsor of the Coderetreat and if she would work for a company offering products in the defence sector. So I asked her to answer my usual questions. These were her answers:

Rea, why did you choose to become a software developer?
I consider myself a beginner in the field of software development. I chose to switch to software development because in this world where computers play an increasingly important role I don't want to be a bystander, but be able to help shape it. I believe that in the near future software development should be as basic a skill as writing and arithmetic.

You said that you would not work for a company in the defence industry. Why is that so?
Call it defence industry or call it arms industry - its goal is to build something that harms or kills other people. Calling it defence industry rather than attack industry is just a euphemism. In the end it doesn't matter who started it. No defence industry is meant do be just passive-defensive. It always includes active attack as well. I don't want to have a part in this. I don't see why some humans should be worth living, while others can be harmed, maimed, crippled or killed at the whim of somebody in an office somewhere far from the actual action. Even thinking that there is a state funded - and therefore tax payer funded - industry that has the goal to kill makes me sick.

What other topics are you concerned about and what do you do about them?
I am concerned about many topics: Microbial resistance, climate change, loss of privacy, growing fear that manifests itself in hatred against others. I am not a politician and don't want to be one. What I do is to think hard about what I, as a single human being, can do, and then take little steps, one at a time. Even if they are not the most comfortable steps. Doing something, as little as it may be, is more valuable than to despair and do nothing at all. "Many a mickle makes a muckle" - I am convinced that each and every little step counts.

To be more specific, I do my little share against climate change, try to reduce waste and emissions, and have a small footprint. Although I have given up being a strict vegetarian (which I was for about 20 years), I eat meat less than once a month. I don't own a car and try to avoid using one as often as possible. I don't think it is necessary to travel extensively, although I really would love to see the world. I just think the harm it does is worse than the benefits I get. I buy locally and seasonally whenever possible. For me, this has precedence over organic food.

I have recently read that the volume of insect biomass has declined by almost 80% in the last 40 years in areas where it was measured, and other areas are likely to have seen a similar decline. This frightens me. Especially as the reasons can only be speculated about, and there is nothing I can do.

I speak up against racism, homophobia, sexism, etc. when I encounter it. I embrace diversity and try to raise awareness in others. I try not to judge what I don't know. Often, its not a matter of 'good' versus 'bad', but just of 'different'.

As for loss of privacy, again, I try to raise awareness. When people tell me they don't mind being under surveillance, I tell them this: You have nothing to hide when you go to the bathroom. But I bet you would rather not have me watch you there. I don't own a smart phone and still resist the urge to buy one. I try to reduce being tracked while surfing the Internet. I don't want a smart TV or any other smart device in my apartment. I still have an email address with Google, this is something I want to change soon. I do quite well without most of social media. And I wonder again and again how much longer I can keep up this retro lifestyle.

Methicillin-Resistant Staphylococcus aureus BacteriaWhat do you consider the biggest challenges for humanity at the moment?
I think bacteria resistance to antibiotics is one of the biggest dangers we are facing. This, combined with today's mobility, is all you need for a ghastly Hollywood movie scenario. I hope reality won't be as bad.

What could we do to engage in topics like meat mass production or pollution? For example, did you take part in public protests, donate money to NGOs or sign petitions?
As to what we can do - see my answer above. Signing petitions with Avaaz is something I did for a while. I realised that doing this makes me lazy in other ways. Signing gives me this feeling of accomplishment, but there is more I can do, in my own vicinity. The best way to fight meat mass production is not to consume this meat. For some people this is a bigger departion from their habits than for others, granted. But if you skip meat once a week, this is better than nothing. Or skip every other day. Or have meat once a week only. Just reduce your consumption. I think the difference in production cost between vegetables and meat should be reflected in the price. Not only the monetary price, but also the price as concerns the ecological footprint.

I have a split relationship with NGOs. I used to support Greenpeace, for example, but don't do that any more. One of the reasons is that I strongly disagree with their campaign against GMOs. Let's not get too deep into this here. But I do support NGOs as such, I think it is important that there are organisations that are independent of governments and other big influencers.

Do you think it is possible to work on "the right things"?
This is not my own idea, and I don't remember where I heard it first, but it had a great effect on me: Thinking about how much good I can do with my own work and how much good can be done with the money I earn, I have to realise that my money can do more than I can. While I would prefer to do both - work a job that matters and give money to others to do good stuff, I am not currently in the position to do so. I find it hard enough to avoid doing things I am not comfortable doing, working for industries I would rather not support. But what I can do is live a frugal life and give away the money I don't need to help others do better things. Again, not because I don't want to get my hands dirty or anything, but because other people or organisations are better suited to doing this stuff.

I wish I could do both: work on the things I believe to be the right ones, and support others to do the same at the same time. But then again, what I believe to be the right things might turn out to be completely wrong. I think it is important to keep an open mind on what the right things are, and change directions in the face of new evidence.

If it happened, please tell the story of your decisions regarding your work because of your values and social responsibility.
I don't remember any such decisions in my short life as a developer. I imagine that they would include security or privacy issues, or issues of inclusion/exclusion of certain groups. Before becoming a developer, I worked at a staffing firm for a very short time. After about a month I figured out how they treated their staff and quit immediately. I did not want to be associated in any way with such business practices. In hindsight I regret not having done more for the staff.

How do you think about selecting industry, customer and project based on your values?
An important choice for me was to work with a company that embraces Open Source Software instead of working for a closed source company. However, the software we produce is not Open Source, which I deeply regret. Choosing the customers I work with directly is unfortunately out of reach at the moment. This is something I aspire to.

Do you have problems with any industries? Why? What about Porn industry or weapon manufacturing?
I don't think porn is bad per se, as long as it is consenting adults working in it. (Of course, more could be said about the gender issues in most porn, but this is not the place and time for that.) As for the industries I don't want to work for: I don't have a list ready. But it is very obvious for me that the weapons and defence industry definitely have place high on that list. I would put animal factories and suppliers on that list too. As a teen I had to work as a farm hand for a few weeks, and was assigned to a small scale chicken farm. Every morning I had to walk through the big hall with all the chicks and collect the ones that had choked over night. Not a good memory.

Cow PortraitObviously, companies that use child labour are out of question as well. I also see combustion engines as a problem for climate change - although there are bigger problems, and worse polluters. Many car companies are looking into ways of making individual transport more sustainable making it a less clear-cut question. On the other hand, I would not want to work for companies in the petrochemical sector. Banks and insurance companies probably get a space on that list as well. And the pseudo-pharma industry that produces and sells pseudo-medicine. I mean those who sell sugar beads or other quackery and convince people they are as good as - or even better than - proper medicine. Any company, basically, that is concerned more with benefits for the few, instead of adding value for the many. Which is, unfortunately, quite common practice.

Did you ever reject a customer based on your values?
As I mentioned in an earlier question, I quit a job I actually needed because of fraudulent behaviour on their side.

On the other hand, what would be projects that you would love to work on?
I would love to work for social and educational projects. I see education as the most important tool to build a better world. Education on all levels, and for all social groups, everywhere. I am convinced that education is the only way to solve the problems we have today. (This is one of the reasons why I don't want to give up my small teaching gig.)

Some branches of research are important too. No future development without research. Not related to any specific project or customer, I find the use, propagation, and development of Open Source Software to be of great importance. Apart from the often mentioned four freedoms, I see it as a means to more equality. I have used and propagated Open Source for a long time, and want to start contributing to it as my next goal.

Thank you Rea for taking the time to answer my questions. (I saw the time of your last email was 1:18 am.)
Thank you, Peter, for the opportunity to think about these topics in a structured way! If anyone has any suggestions, please let me know.

30 October 2017

Managing the Difficulty of Coding Exercises

There are different scenarios when we might want to change the difficulty of coding exercises. This depends on our skill and the topic we want to practise. If an exercise is too easy we get bored. There is still value in repeating the very same exercise, e.g. internalising certain patterns or improving keyboard navigation, but boredom does not help learning. Here is an unsorted list of options to increase (and decrease) the difficulty of coding exercises:

Most DifficultMaking it Harder: Constraints
A constraint, or activity, is an artificial challenge during an exercise. I have discussed some of them in the past. Some constraints like No If, Cyclomatic Complexity One or Only Void Methods are easy to follow but make it hard to write your usual code. To have more challenge chose constraints that work against the assignment, e.g. use an algorithmic challenge together with Only Void Methods. Algorithms are often functional in nature but void methods are no functions. Win!

To make things more interesting, constraints can be combined. For example, Object and Functional Calisthenics are constraints that combine several rules. When creating combined constraints, it is important to make sure the constraints work together. There is no point in forcing a functional style with No Void Methods and an object oriented style with Only Void Methods at the same time. When Martin Klose and I combined the Brutal Coding Constraints we spent around 20 hours experimenting and fine tuning them. By the way, these Brutal Coding Constraints are probably one of the most challenging.

When the list of constraints gets long, it is easy to make a mistake and forget to follow one or another. In these situations you need a reviewer, e.g. Coding Dojo facilitator, pair programming partner or static code analysis tool, who checks for violations of constraints.

Harder: Changing Requirements
Another way to spice up an exercise is to introduce requirement changes. This is particularly useful for groups, e.g. Coding Dojos, when participants do not know which requirement is going to change. For the usual Coderetreat exercise Game of Life, several interesting changes have been proposed, e.g. Hex Life, Vampire Cells and the toughest constraint (Wormholes) by Adrian Bolboaca.

I witnessed Martin Klose taking this to the next level: In his exercise Wind of Change, he puts on a tie (because he is the product owner now) and keeps changing the requirements every few minutes. This is a lot of fun and adds some time pressure as well.

Requirement changes is useful to verify a design, usually used in double sessions on software design during Coderetreats. When you are on your own, as soon as you finished the exercise, you think of changes to the requirements and how they would affect your current design.

Harder: Algorithmic Challenges
Algorithmic challenges vary from easy to impossible. Project Euler even has a difficulty rating on each exercise. Often algorithmic challenges are based on mathematics, which makes them not useful for people with less academic background. Also, as soon as you found a solution, the exercises get boring. Using additional constraints can make them fun again, but that would be different exercises then.

I have seen senior developers being more interested in algorithms than XP practises like Pair Programming or TDD. Algorithms are a perfect way to "lure" them into attending Coding Dojos. After a few dojos, people understand the value of practise and will agree to do basic katas with focus on TDD.

If you need a challenge, go for an algorithmic kata and chose a difficult exercise like Potter, Searching or one from Project Euler above number 20.

Harder: Try to be Faster
I do not like to apply time pressure during exercises, because people get sloppy when under pressure. On the other hand, this is what needs to be trained to not get sloppy. Houssam Fakih explains this with a short video (where three people throw basket balls. One is a beginner and fails from time to time, one is experienced and wins repeatedly and one, a "master", is doing the same, but much faster.) Houssam's suggestion is to do the same, but try to be faster. I did that once because I wanted to squeeze an one hour life refactoring demo into a 45 minutes presentation slot. It was hard work, exactly what I wanted.

When using constraints and other techniques I describe above, it is easy to go over the top. The exercises become too difficult and working on it is frustrating and eventually we stop doing it. While this might be OK for yourself, it must not happen when working with a group. Exercises like Brutal Coding Constraints are very difficult and not - I repeat - not suitable for a general audience. People tend to overestimate their skill and get frustrated easily.

When facilitating a Coding Dojo, I want to stay in control of the difficulty of the exercise for all participants. I aim for easier, simpler exercises and keep the difficult ones for myself. In rare cases, when I meet very skilled people, I assign them individual constraints, because I know them and I am confident that they will handle. I also make sure everyone understands that it is difficult what they want to do.

Making it Easier: Simpler Assignments
Start with a simple problem. There is always a smaller assignment, The smallest kata I know is FizzBuzz, it is just a single function. There is nothing wrong with FizzBuzz and its friends. I do it from time to time when I explore a new language or try different constraints (or when it is very late and I feel tired). Some function katas like Prime Factors are small too, but algorithmic in nature, so stay away from them. These katas are called FizzBuzz or Function Katas.

Easier: Use Well Known Problems
Solving a programming assignment includes many steps: e.g. understanding the problem, finding a solution, implementing the solution, testing it, etc. The assignment is easier if we get rid of some of these steps. If we use a well known problem, e.g. a ticket machine or a game everyone knows, we already know what is expected.

Easier: Clarify/Understand the Problem
Often the problem with an exercise is that people do not understand the problem. We are eager to get into the code, but we need to understand the assignment first: Take time to analyse the problem you want to solve. Google it. If it is a game like Tic-Tac-Toe, Minesweeper or Pac-Man, find an online version and play for a while. Draw some sketches or diagrams of what needs to be done. Create an list of initial acceptance criteria. To find them, you have to think about the problem. In Coding Dojos I ask people to spend the first ten minutes on creating a test list. This forces them into thinking about the problem.

If you practise with a partner, which I highly recommend, try Adi's pair programming game Solution Seeker. Solution Seeker makes you find at least three different solutions to your problem before you are allowed to implement one of them. This forces you to think hard about the problem and different options to solve it.

As a facilitator, make sure you fully understand the problem so you can answer any question about it. Give more explanations and discuss the problem from different angles. Provide posters or handouts of the problem for participants for later reference.

EasierEasier: Repeat the Same Exercise
Repeating the exactly same exercise is considered boring, but it helps. You will understand the assignment better after working on it once. After implementing it several times, maybe even in different programming languages, more and more aspects of the implementation are known and you can go deeper. (This why we run Game of Life in a Coderetreat six times. We do not want to fight with a new problem each session.) This is especially true for hard problems or if you are not satisfied with your process or final solution.

Easier: Focus on One Thing
After repeating the same exercise one or more times, the problem is sufficiently known and you can shift your focus to something else. Using a well known problem is also a way to focus on one thing, in this case you do not focus on solving the problem. There are exercises that isolate different aspects of development: For example, if I want to focus on finding test cases and designing unit tests, I go for the Gilded Rose. If I want to practice refactoring, I do Tennis or Yatzy. Both code bases contain ugly code which is more or less fully covered with tests, making it safe to refactor. There are exercises isolating other things, like incremental development, emergent design, SOLID principles, etc.

Koans belong into this category. Koans are series of little exercises, starting with basic things and building on each other to move to more advanced topics. They are useful to learn programming languages. They contain a list of failing test cases, where tiny pieces of code have to be filled in to make them pass. The idea is not only applicable to programming language constructs. For example I have created Unit Testing Koans to teach xUnit assertions and life cycle to junior developers.

All these exercises require prepared code. For example Gilded Rose is available in 26 languages, including lesser common ones like ABAP and PL/SQL. Trivia even contains COBOL and VB6 - which is very suitable for a legacy code exercise. Obviously prepared code limits the number of languages which can be used. If you want to practice in a new language like Elixir, Elm or Swift, you might need to port the code base first. Although, if the new language is trending, chances are high that someone already ported it.

Easier: Prepared (Helper) Code
Prepared code is useful in many situations, especially outside the core of the practise. Even code snippets or cheat sheets help. For example when I run the Data Munging exercise with focus on functional programming in Java, I show participants code snippets how to read the text file. File IO is not related to the exercise and I want them to spend time working with Lambda expressions and Stream.

Prepared code allows us to focus on one thing, but we need to understand the code first. Unfortunately this adds extra complexity. Unless you want to practice working with unreadable code, prepared code must be simple and super clean. Try to make it more expressive, maybe even verbose, than your usual code and use very descriptive names. Describe the code in the assignment. If there are more methods or classes, visualise their relations. For example in my Test Double exercise, I added a simple diagram of the prepared classes and their collaborators.

Easier: Guide Step by Step
Alex Bolboaca once told me that as facilitator of an exercise it is most important to manage participants' frustration. When I notice that most of the participants are unable to move forward, I take control of the group and guide them step by step. I am not giving them answers, but moderate the necessary process. Maybe we need to discuss the problem before hand on a white board. Or we discuss potential solutions up front. To get an initial test list, I keep asking how we will verify our product until we have a reasonable number of test cases. Sometimes I switch to Mob Programming where the whole group works on the assignment together and I am able to support them best (a.k.a. micro manage).

There are many options to make coding exercises easier or more difficult. I recommend starting easy. There is no point in hurting yourself or others. ;-)

Thanks to Kacper Kuczek and Damian Lukasik for discussing this with me.

15 October 2017

Introducing Code Smells into Code

Sgt. Sniff-a-lotCode Smells
Code smells are hints that show you potential problems in your code. They are heuristics: Like in real life, if something smells, look at it, think about it, and change it if necessary. In the classic book Refactoring - Improving the Design of Existing Code, Martin Fowler describes 21 code smells like Long Method, Primitive Obsession, Switch Statements, Feature Envy and other anti-patterns that indicate deeper problems in your code.

The Brutal Refactoring Game
Adrian Bolboaca came up with the Brutal Refactoring Coding Game. He explained the history of the game and the game itself on his blog. I attended his workshop at the XP conference 2013 and experienced the game first hand.

In the game participants are asked to write the cleanest code possible. If the facilitator spots any code smell, participants must stop and immediately remove it. Adding functionality is forbidden until the facilitator agrees that the smell has been removed. In his workshop, Adi gave us a numbered list of smells and gave cards with the appropriate number to pairs where he saw a code smell. And he was mercilessly flagging the smallest problems in our code. ;-)

Code Smells Used in the Game
Adi chose these code and test smells for his game:
  1. Lack of tests
  2. Name not from domain
  3. Name not expressing intent
  4. Unnecessary if
  5. Unnecessary else
  6. Duplication of constant
  7. Method does more than one thing
  8. Primitive obsession
  9. Feature envy
  10. Method too long (has more than six lines)
  11. Too many parameters (more than three parameters)
  12. Test is not unitary
  13. Test setup too complex
  14. Test has an unclear Act
  15. Test has more than one assert
  16. Test has no assert
  17. Test has too many paths
Adi told me that he chose these smells because he saw them most often in his clients' code bases. His list definitely misses duplication, deeply nested conditionals and a some more. A more complete list might contain 30 items, making it more difficult and potentially frustrating for participants. (Maybe I will come up with the Moar Brutal Refactoring Game in the future...)

Observations during the Brutal Refactoring Game
This article is not about the Brutal Refactoring Game, but about code smells introduced into code. The game allows observation how and when code smells are introduced (because the whole point is to spot and remove them). As part of my refactoring training I facilitated the game more than ten times. Each time took 3 to 5 hours and had six to eight participants. The teams were average teams with several senior developers and an occasional junior developer. People worked in pairs and implemented Tic-Tac-Toe. Most teams used Java, two teams used C.

Discussion of Introduced Code Smells
Here is the code smells statistic:

Code Smells Introduced
The chart shows the number of problems I flagged during the last ten games. The different colours of the bars show the different teams. Obviously not all smells are introduced equally often. The first smells appear 10 to 15 minutes into the exercise. One team using C had difficulties with the setup and was going forward very slow - they produced little code and very few smells.

The first smell I usually see is 1 - Lack of tests. Even people following the TDD cycle happen to create "more production code than is sufficient to pass the test." This happens in the beginning and also later during the game.

Naming is hard. Not surprisingly the most common smells (number two - Name not from domain - and number three - Name not expressing intent) are naming related. Naming things after the problem domain seems twice as hard as pure technical naming. Any non trivial method could be named process or execute, but that does not help understanding the code at all.

Primitive Obsession (number eight) is the most common single code smell I have seen during the game. It is introduced early in development when method signatures are created and APIs are designed. It occurs roughly as often as the naming related smells together. Most Tic-Tac-Toe implementations are (publicly) based on numbers, pairs of numbers, arrays of numbers or the like. Primitive Obsession is very dominant in many (Java) code bases. In my code reviews I am used to method argument lists like String, String, String, String, String, int, long, long etc. Instead of using all these primitive values, they should be wrapped and should not be visible at object boundaries. (I have written more about primitives in the past.) This is an object oriented design smell.

The third most often flagged code smell are long methods (number ten). This smell is introduced later, when logic is added to existing methods. I see this smell more in the second part of the game. Even when using TDD, this smell is introduced if the refactoring phase is skipped or taken lightly. Long methods are also very common in legacy code bases and difficult to understand or change. Everyone hates these 1000 lines long methods, still I find them in every (large) code base I look at.

Code Smells Categories
To conclude this analysis let us have a look at problem categories. I aggregated Adi's 17 code smells into four groups:
  1. Problems in test code
  2. Naming related smells
  3. Missing object orientation
  4. Complexity
Code Smell Categories
It seems that unit testing is the least problem - which it definitely not true. Most teams I work with have no automated (unit) tests for their production code. Maybe there were less testing issues during the game because the teams had learned about testing smells before. I practice refactoring with my teams after we have worked through all of unit testing.

Initially I was surprised to see missing object orientation high on the list. Now, after writing about it, I think it is also related to my "coaching/ learning plan". After refactoring I go for naming and finally object orientation. (Maybe the order of topics is wrong, but unit testing is easily sold to management and refactoring is asked for by developers often, making both topics ideal to start an improvement initiative.) I do not expect less naming problems, even after a few sessions on naming, because - as discussed before - naming is hard. I would expect the object orientation of the solutions to improve.

Samir Talwar wrote about his experience with the game. As facilitator he had a different focus, e.g. he was more strict about unnecessary if, treating it more like a No If constraint. He also saw different code smells being introduced. (I recommend reading his summary.) We both agree that naming is hard and causes many problems.

Comparison of Team Performance
While the participants were industry average - maybe even above - they were in need of improving. (Who is not?) The following bar chart shows the number of code smells introduced into the code by each team. (To compare the teams I removed the one with setup problems.) Some teams ran the exercise twice. Some of them improved, some did not.

Code Smell Categories by Team
On average, each team introduced 17 issues into their code base, right from the beginning of a small project, during a few hours of work. I am sure they tried hard because I was watching them, still this result is very disappointing. I am scared of the massive amount of code smells lurking in real world projects.

There is a noticeable difference between individual teams. Some teams created only half as many smells as other ones. Better teams introduced less code smells creating less technical debt.

Adi claims that you can have legacy code after 15 minutes. It is true. In a short time, the teams introduced many code smells into their code. The most common smells were bad names and Primitive Obsession. Different smells were introduced during different development activities. Some teams introduced less smells than others.

We need to focus on code smells. Noticing smells in our code is an important skill which can be trained. A good place to start practising are refactoring code katas like Emily Bache's Tennis Game and Yatzy. (Both exercises are available in many programming languages.) "Listening to code smells" improves our design. Finally I want to encourage you to watch out for primitive values on object boundaries as Primitive Obsession seems to be the most common problem in object oriented code.

Final disclaimer: The game is no scientific experiment throughout our industry. Only a few teams participated and the results are biased. Nevertheless I wanted to share the results.

23 September 2017

Verbs instead of Nouns

Verbs instead of Nouns is a basic Coderetreat activity. It was used right from the beginning of Coderetreat. I tried it the first time during the GDCR 2012. The goal was to focus on verbs instead of nouns (obviously ;-). By searching for verb names, we did not think about what a class represented or contained, rather what it did.

Constraints in General
A constraint, also known as an activity, is an artificial challenge during an exercise, e.g. code kata, coding dojo or Coderetreat. It is designed to help participants think about writing code differently than they would otherwise. Every activity has a specific learning goal in mind.

Constraints are the primary tool to focus a coding exercise. For example, to improve my Object Orientation, I will practise Jeff Bay's Object Calisthenics or even Brutal Coding Constraints. Some constraints are an exaggeration of a fundamental rule of clean code or object oriented design and might be applicable during day to day work. More extreme ones will still help you understand the underlying concepts.

Learning Goal
Verbs instead of Nouns is listed as stretch activity. Stretch activities are designed to push you out of your usual coding habits - your coding comfort zone - and broaden your horizon by showing you new ways how to do things. By design stretch activities might look awkward, ridiculous or even plain wrong.

The learning goal of Verbs instead of Nouns is to push you out of noun oriented thinking. Noun oriented thinking is a way of object orientation, where the nouns of the problem description become classes, and the verbs become methods. This is the classic definition of Object Oriented Analysis and Design. As with any technique, following it blindly is not healthy. According to Alan Kay Object Oriented Programming is about messaging and encapsulation. He wanted "to get rid of data". His objects are defined by the messages they accept. Object orientated programming becomes verb based, if we focus on behaviour.

In functional programming, verbs are natural. All activities are functions. For example Steve Yegge describes functional programming as verb based in his humorous critique of 2006's style Java. Verbs instead of Nouns is an object oriented constraint.

VerbInterpretation of the Constraint
Besides its name there is no information about this constraint available on the Coderetreat site. There was a discussion how to meet the constraint (which has been deleted to make space for the new GDCR organisation): Separate value objects from operations and build service objects for the operations, which would be named with a verb. Or do not consider what a class contains or represents, but what it does. This keeps the concerns separated and the classes small and simple.

Being a Value
Obviously not everything can be named with a verb. Values, at least primitive values, are things: 2, true, "Hello". The Oxford Dictionary explains value - the way we use it in code - as the numerical amount denoted by an algebraic term; a magnitude, quantity, or number. Now "Hello" is neither a quantity nor number, it is a constant term. The entry about Value Object on Wikipedia defines a value object as a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object.. The definition uses "having the same value"... I am not getting anywhere.

On the other hand, in the Lambda Calculus, even numbers are represented as functions. For example the number two can be represented by the higher order function n2(f,x) = f(f(x)), see Tom Stuart's Programming with Nothing. Being a function makes it verb based but which which verb would name n2(f,x)?

Suitable Exercises
For a stretch exercise, a suitable exercise is challenging. There is no point if everything goes smooth. We need an assignment that does not support the constraint. Everything that is functional in nature is not suitable, because functions are verb based. This rules out algorithmic exercises as algorithms are usually functional. We need a kata with some state - some "values" - and the need to mutate that. Let's try different problems.

Discussion of Game of Life
As I said, I did Verbs instead of Nouns first on the Game of Life. While Game of Life is a larger exercise, most of it can be implemented in a functional way, lending itself to the constraint. Here are some of its classes:

Classify has two implementations, ClassifyPopulation and ClassifyReproduction. Both classes check if a population is optimal for survival or not. There is one public method and its arguments are passed into the constructor. These classes are functors, function objects, the representation of functions in object oriented languages. The class name suits these class and the verb oriented thinking helped in extracting and evolving them.

LocateCell represents the position of the cells in the grid. It contains two integers x, y and an equals method to identify same positions. What is the verb of being a coordinate? A coordinate locates, as it discovers the exact place or position of something (Oxford Dictionary). Here Coordinate might be a more natural name.

I am unhappy with LookupLivingCells. It has two methods reproduce and isAlive. The verb Lookup only points to the second method. A proper class name should contain all functionality the class offers, so LookupAndTrackLivingCells is more appropriate. I do not like class names with And in them because they violate the Single Responsibility Principle. On the other hand - in an object oriented way - the class is fine as it encapsulates the collection of LocateCells and represents a Generation of cells.

Discussion of Trivia
Next I tried refactoring towards the constraint. Refactoring towards a constraint allows a more fine grained transition. Together with fellow craftsman Johan Martinsson we worked on the Trivia exercise and spent several hours extracting "verbs" from the legacy code base. (Many of the observations I describe later were made by Johan or found through discussion with him.) Let's look at some of the classes we created:

We extracted Ask. An noun oriented name might be Questions or QuestionsDeck. It is a closure over the list of questions and it does ask them.

MovePlayerOnBoard contains the board of the Trivia game. We felt being unable to escape our mental model of objects as state. On the other hand, the code for the class was chosen only by looking at the behaviour. It must be good. MovePlayerOnBoard has one public method but is not a functor because it contains mutable state, the positions of the players on the board.

Score is a similar reasonable class by object oriented standard. A player scores by answering correctly, or does not score by answering wrongly. Like MovePlayerOnBoard and AllowToPlay, it is a real object with internal, encapsulated state and various methods manipulating its state. These classes are far away from functors and functional programming.

Verbs are abstractions, too. There are "small verbs" like increasePurse, and higher level ones like moveAndAsk. Smaller verbs are easier to identify and to create or extract. Most of our verbs encapsulate primitives. If the code is primarily state, finding a suitable verb is hard. These verb names feel even more "wrong" than other verb oriented names. Maybe, when we only behaviour of a class is mutating the subject, we should show the subject in its name.

A method that does much is difficult to name with a single verb. In the refactoring exercise, we moved out logic to make the describing verb(s) simpler, clearer and "pure". During refactoring we had trouble finding concise verbs for convoluted legacy methods. I guess when creating verb based code from scratch, such methods would never exist. Naming classes as verbs helps to split logic into more classes containing different aspects of data.

Many verb oriented classes are functors, objects with a single method. Some are closing over state. There are classes with different aspects of the same verb, e.g. answerCorrectly and answerWrongly in a class Answer. Despite some weird names, the resulting design was always good. The constraint drives to nice, small, focused objects.

Usefulness as Exercise
The constraint is difficult. Especially when dealing with state, it is hard to find verb oriented names. It forces small, focused objects and discourages state oriented designs like Java Beans. Intermediate Object Oriented programmers will gain most of the constraint. They understand the basics of objects and usually create noun based classes. With more knowledge of object oriented design principles like SOLID, the constraint might have has less impact on the design.

Example Code

20 August 2017

Same procedure as every year

One advantage of freelance work is that I can take as many days off as I like. Since 2013 I am not visiting clients during summer, instead I am working on a different project. This year, my wife wants us to reach production, I am pushing hard, working 14 hours some days.

My Trustworthy Hammer Drill

27 April 2017

Interview Dirk Rombauts

Next in line is Dirk Rombauts, a fellow software developer from Vienna, whom I met at the Vienna BDD Meetup.

Dirk, please tell us a bit about yourself.

I decided to become a software developer around the age of 16. I was into natural sciences, math, astronomy and computers at the time, and a lot of my older friends were studying to become software developers. I used to play with Lego all the time as a kid, and software development is a lot like building Lego things: you have building blocks - frameworks and libraries - and if you put them together in meaningful ways, you can create quite cool things.

My university studies did a good job of giving me a basic understanding of software development and of the limitations of what a computer can do. They also pushed me in the direction of curly braces, since our main projects were done in C++. I did a bit of work in Java and C++ before jumping on the C#/.NET bandwagon in 2003, and I've enjoyed the ride ever since.

The thing I am most proud of is the work I've done on Pickles, the open source living documentation generator. A living documentation is a documentation that is always up-to-date with the newest insights. Wikipedia is a living encyclopaedia, but unlike Wikipedia, with living documentation you do not need human intervention: assuming your specification is written in the Given/When/Then style of Cucumber or SpecFlow, Pickles will contain those (frankly quite boring-looking) specification files and turn them into a much better-looking web app. That means that non-technical people can read the specification files without needing a programming environment - or in other words: it becomes easier for non-technical people to participate in the discussions. Pickles has emerged as the leading living documentation generator, and receives regular code contributions.

RespectYou are vegetarian and mentioned ethics of work several times during our conversations. Why does that matter to you?

I eat vegetarian for two reasons: I consider the way animals are treated in the food industry to be unethical (there is that word again). I do not object to people raising animals, killing them in a quick and painless way and eating them - while it is done in a respectful way. Stuffing stalls to overflowing with animals, treating them like inanimate objects, hauling them hundreds of kilometres to a place reeking of fear and death to slaughter them - that is a far cry from treating animals with the respect that every living creature deserves. The other reason is that I believe - based on the results of scientific studies I've seen - that by eating vegetarian, I significantly reduce my risk of cancer or cardiovascular diseases. I do not try to convince people of my views: everybody should decide for themselves, I detest proselytising, and the sad truth is that for every scientific study that supports my view there is another study that says that another diet is much healthier. So it comes down to what you choose to believe.

What other topics are you concerned about?

As with the animals, I believe we should treat other people and the environment with respect. Cheating people is not respectful. Doing work that harms people is not respectful. Doing work that damages the environment is not respectful. Therefore, work ethics are important to me. I believe women and men are of equal value and should be granted the same rights, the same opportunities and the same compensations for the same job. That makes me a feminist, and I am proud of that.

We live in a world where everybody with an Internet connection can watch hours of pornography, and yet it's rare to see a positive attitude towards sexuality. This is very obvious in the way society treats sex workers: they perform a very important service and ought to receive gratitude and respect for that - instead they are treated like dirt, the name of their profession is an insult, and in some regions they are indeed even prosecuted (but not their customers). I hope it goes without saying that I do not condone trafficking.

There is a chasm between the rich and the poor, and the chasm grows wider all the time. I begrudge no-one the spoils of their work. But I do not get that a manager should earn over 10 times more than regular workers. And I do not think it is right for "the rich" (be they people or companies) to exploit others for the sake of profit maximisation. I live a life that is affluent compared to many other places in the world, and I too have the desire to earn a bit more, but at some point enough is enough. At least in my opinion - many people with big salaries seem to think otherwise.

And then there is this fixation on working a lot. In the 1950s, when automated assembly and production became a thing, people dreamed of working only a few hours a day and devoting the rest of their time to family, friends, hobbies, art, ... In one of his short stories, renowned science fiction writer Isaac Asimov has one of the characters reminisce about the bad old days of a demanding four hour work week. Over half of a century later we are still working eight hours a day, and there is more and more talk about increasing that to 10 or even 12 hours a day. Something went wrong along the way.

What do you consider the biggest challenges for humanity?

I think the biggest challenge for humanity is the ingrained "us versus them" attitude of people. People tend to divide the world in two categories: us and the others. They will look after the interests of the "us" group, and ignore (or even sabotage) the interests of the others. Back in the days of hunter-gatherer societies this made sense: in order to survive, a human needs a tribe. So survival of the human becomes linked to survival of the tribe. A hunter-gatherer society usually operated in a scarcity environment, so it was important to make sure that the scarce resources were obtained by the "us" tribe and not by the other tribes. The "us versus them" mentality was a significant survival trait.

2nd FightEver since the development of agriculture and civilization, there have been plenty of resources and it is no longer necessary to divide the world in those two categories. The "us versus them" way of thinking is so deeply ingrained in our genes that it is very hard to overcome. We see it in rivalries between supporters of football clubs, in nationalism, in racism, in ethnic cleansing, ... Much of organised religion falls into that category as well, compounded by the fact that you now have a higher authority that tells you that it is right and proper that you look after people of your of tribe and creed, while being content to let the others rot in hell or even helping them along on the way.

If humanity is to evolve beyond its current state, we will need to overcome to "us versus them" way of thinking. If we do not, we will be fated to go through endless cycles of war and peace. As population sizes grow, those conflicts grow in scale and destructiveness too.

What do you do to engage these topics? For example, did you take part in public protests, donate money to NGOs or sign petitions?

To be honest, I am not convinced public protests do much good. They gather a bit of attention, but next week the focus of the media will turn somewhere else and the protest and its causes will be forgotten. I think that continuously doing small things has a bigger impact. If over time enough people do small things continuously, that will achieve a more lasting effect than a public protest.

I eat vegetarian so the meat industry doesn't receive financial incentives from me. I separate my trash in recyclable categories. I do not own a car - while I do use car-sharing from time to time, the first option I evaluate for getting from A to B is always public transport. I sign the occasional petition, but like public protests, I do not expect much to come from that. I donate money WWF (World Wide Fund for Nature), an NGO that protect animal diversity.

While I could quit my jobs and do charity work, I rather keep doing what I can do best and earn my salary as usual, just working on "the right things". Do you think that is possible?

It is not easy. Our society is geared toward earning money, spending that money in exchange for enjoyable things, and not asking too many questions about where those things came from. Working as software developer or IT administrator for an organisation like Caritas might be a worthwhile thing, but the pay would be such that it would be hard to make ends meet. My current strategy is to work part-time, earning enough money to pay the bills and also having time left to enjoy life.

During your professional career, did you ever have to take difficult decisions because of your values and social responsibility?

I haven't encountered any moral dilemma's in my work so far, except perhaps the target industry of my former employer. I hope that should I be asked to do something that I consider morally wrong - like tampering with emission control measures - I will have the courage to say no and to go looking for another job.

How do you think about selecting industry, customer and project based on your values and social responsibility?

I think it is important to follow your conscience when selecting a job. If you do not, and you end up working in a field that runs counter to your values, you will suffer. You may not notice on a conscious level, but it does have repercussions. Recent studies suggest that if your own picture of reality is at odds with reality itself, your body will release large quantities of cortisol (the stress hormone). Increased levels of cortisol are linked to increased illnesses, increased anxiety and unhappiness. If the reality is that you are working in some job, but your values (your picture of how reality should be) tell you that you should not work there, then you are setting yourself up for a cortisol trip with all the problems thereof.

Let us be more specific: Would you work for an animal factory? Would you work for a company producing equipment for an animal factory? Would you work for a sweat shop exploiting kids in Asia? Would you work for a company producing equipment for such a shop? Do you have problems with any industries?

The Slaughter of NatureI do not want to work for most of the companies you describe: exploiting animals or people is a no-go for me. Being accessory to the exploitation by working for a company producing equipment for an animal factory wouldn't sit right with me either. Even designing a website for such a company would make me uncomfortable. That said, I will do that kind of work if that's the only alternative. It may sound callous, but I would rather work for the company with the sweatshop than for the animal factory: there are far more human beings than animals, so I feel we need to devote more care to the well-being of animals.

I would probably be alright with working in the porn industry: there is nothing wrong with porn in and of itself, although there sadly is much more stereotypical and demeaning porn than there is sex-positive porn. As for the military: I could imagine myself working on a defensive system, but not so much on an offensive system. Still, if the choice is between the military and an animal factory, I will work for the military (unless the project involves animals like the Navy Marine Mammal Program in the United States of America).

I do not have a problem working in the gambling industry. I have done it before, and have recently accepted an offer to do so again. I consider it the responsibility of every single person to decide if they want to risk their money in gambling. The odds of winning are low, but you will at most lose your own money if you bet wrongly. When a bank bets on the wrong horse, they can lose the money of all their customers.

Did you ever reject a customer based on your values?

My previous employer is active in the financial industry. At first I did not mind but over time I began to realise that the work I was doing benefits only the rich: it helped the rich getting richer. The other, far more numerous part of humanity did not benefit from my work. Additionally, the speculations of investments banks can have a massive negative impact on society, like the financial crisis in 2008.

When I went looking for a new job after five years in the financial industry, I looked in different industries. I was offered several positions in the financial industry, but I declined those immediately.

On the other hand, what would be industries or companies that you would love to work on?

I would love to work for an animal-related NGO like WWF. I believe that when we learn to treat animals and the environment better, we will also learn to treat other humans better. I would also love to work for a space agency or company. I believe that more knowledge is the key to a better world. And we need space travel: if humanity somehow manages to survive the next couple of hundred million years, we will need to go in search of a new home among the stars when the Sun increases in luminosity and renders Earth uninhabitable.

Thank you Dirk!

You are welcome!

8 April 2017

33 Days of Education

Empty OfficeIT is a fast moving industry. Heinz Kabutz says that "we are in an industry with a knowledge half-life of at most 18 months. [...] Half of what you knew 18 months ago is worthless today, so you need to keep learning new things." We need to learn a lot, fast and continuously. Today even traditional companies recognise the need for professional development, also - or especially - for senior and expert level employees. (I could argue that senior tech people need more training than junior ones, because their time of dedicated learning in school or university has been longer ago, but I am digressing.) All companies I have seen, offered five days of professional training by year. (Unfortunately, not all employees take the opportunity to use this training budget, but that is another story.) A few companies have a stronger focus on self-development. For example the Swiss Zühlke Engineering offers ten days of professional training. (At least they did in the past, as confirmed by several Zühlke employees I met.)

Obviously ten days are twice as much as five, but I believe we need more. A few companies allow Research or Lab Fridays from time to time, following the idea of 20% time, made famous by Google Friday. While slack at work is focusing on innovation, the time is also available to learn. In the end, exploring new ideas is related to both. One of my clients runs a "Basteldonnerstag" once a month, which adds another ten days. sipgate runs Open Fridays every second week. So we are up to 20 or even 30 days for your professional development each year, I like that.

My Personal Development
As Code Cop I am working with my clients on different things. Some clients use technologies I have never seen before. Still my goal is to help them to improve. It could be as simple as writing unit tests with a xUnit styled testing framework - or as alien as modularising a legacy application written in an old, purely procedural language.

I learn a lot and need to learn more. I am conscious of the time I spend on learning. I think about learning methods and try different approaches, e.g. flash cards. I am still performing code katas, on my own and together with others.

When reflecting about last year, I think that I could have done better. I had interesting work and got a lot of new experience, but I did not attend all training that seemed necessary and I did not visit as many conferences as I needed to visit. I worked full time and had to squeeze in the occasional learning. Out of curiosity I counted the days spent on learning last year. I was very surprised when I found 33 full days spent on professional training:
  • 9 days of conference presentations. Last year I attended 5 traditional conferences, e.g. GeeCON, full of great talks and coding demos.
  • 6 days of classic training like training courses or workshop days before conferences.
  • 2 days of unconference sessions. Unconferences like SoCraTes are less structured than traditional conferences and enable discussion and deliberate discovery of new ideas. Usually I am hooked up with a new topic after attending.
  • 9 days of personal workshops. These include Journeyman Visits, Code Camps and meeting with other people to work on a research topic for a whole day.
  • 2 Coderetreats. While some unconferences include Saturdays, Coderetreat happens on Saturday by design. I am attending them rarely because usually I am facilitating them.
  • approximately 5 days of pair programming practise. I remember 18 sessions either remote pair programming or attending Coding Dojos. Usual sessions last 2 to 2.5 hours.
This list does not include books I read, user group meetups, side projects or writing blog posts - all these activities are an essential part of learning, too.

After seeing these numbers, I am impressed with myself. ;-) 33 days are a lot, and one third of them was spent on evenings and weekends.

Previous Years
So 2016 was a good year for my personal learning. How about the previous years?

Days of Learning by Year
2015, shown in the orange bars, is pretty similar to last year (blue bars). Surprisingly I spent 33 days on professional development, too: one workshop less and no Coderetreats, instead more remote pairing sessions. In 2014, shown in yellow bars, I fell a little short. I did not attend any training or unconferences and did fewer workshops. Becoming independent enabled me to visit (paid) training and I just discovered the opportunity of unconferences and workshops back then. Still I had more than twice as many pairing sessions, summing up to 27 days of professional development.

While I felt bad about my personal learning earlier, these numbers satisfy me. 33 days sounds much and I am starting to pride myself on them. I have no way to compare, I know people who attend at least one conference each month, which already sums up to 24 days at least. So maybe 33 days are not that many after all. So I might/ should/ could do more (MOAR PROFESSIONAL DEVELOPMENT!!1!), but I am pretty sure that I will not. I did not aim for 33 days in the past and I will not do so now. I am very busy, both with my work and my major ongoing side project. On the other hand, this year was full of opportunities and I already spent 12 days professional training in the first quarter.

27 February 2017

Time for Quality

Since one of my very first presentations in 2009 I have been asked how to make time for testing and code quality related activities. Keeping the code of high quality is difficult if your manager or product owner is only interested in deadlines and the number of hours spent on creating the software. People told me that in their organisation there is neither time nor budget for code quality and that their boss does not consider it necessary. While this is the perfect subject for an angry rant, this time I want to list some options instead.

First let me set the context for my answers:
  1. The demand for software developers and IT professionals in general is ever increasing. We are a highly privileged part of the entire workforce. While finding a decent job is always a (subjective but nevertheless real) problem, finding any work in software just to feed the family is not an issue. There is always another job.

  2. Testing is a mindset - you have to want it. There are thousand excuses why not to write a test or delay that particular cleanup. Some people pretend not to be allowed to create quality code, while they are just lazy. I would rather hear their honest views. I am suspicious of colleagues, who claim an interest in quality code but keep delivering crap on a daily basis.

  3. More often than the lack of interest is the lack of knowledge. For example many developers I meet are not sure how to write good automated tests, because they have written only a few in their entire career. Because they are unsure - they do not know how to start - they claim it to be time consuming and drop the idea. If I do something for the first time I will not do it well. Until I master the new skill I will be slow. These developers need training, more specifically they need practise. Every developer needs to be familiar with clean code, refactoring unit testing, and much more. If you feel not sure enough to apply these core skills in your daily work, ask for training, attend programming workshops at conferences or get a programming coach. Coding Dojos and Coderetreats are a great place to start.
So you want to write unit tests and are able to do it. But your boss has no interest in it or there is no team culture to do it. What could you do?

An argumentFirst read my favourite article of Joel Spolsky, Getting Things Done When You're Only a Grunt, which covers some organisational issues. Like Joel, I recommend staying true to yourself - just do it. This is hard in the beginning when you are alone, but others might follow. (It takes a lot of energy and several years to transform a whole team from within.) When complaints about your work start coming in you have several options:
  1. Do not try to defend yourself and avoid arguing. This is the way you work, end of discussion. Again, you need to be fluent and sure to be able to do that. Especially if you are a new employee you have some privileges. The team might accept your new style. If you are applying testing and clean code successfully others might follow.

  2. Argue for code quality. Sure you need some extra time to write these tests, but then you will not have to go back and fix the code again and again which results in less context switches, less defects and less hot-fix releases. I have not met any manager who would not understand that. But sometimes we (IT) do not use the right vocabulary to be understood by managers. When you talk to your boss, it is better to talk about cost, risk and financial benefit than technical issues. Using the management speak is a skill. Start by collecting hard facts about code quality related activities. Research the estimated cost and later benefit for your particular case and compare it to the risk and later cost of skipping it. The Technical Debt metaphor helps here. Create a simple Powerpoint (yes, blasphemy ;-) with these facts. End with the red traffic light or the estimated downward trend of the team's velocity. For example instead of "the code is ugly" you could say that "because of its inconsistent structure you are more likely to introduce mistakes when changing it." Charts displaying the absence of structure, e.g. class diagrams with edges all over the place, make the missing structure obvious for non-technical people.

  3. Silence, pleaseHide the activities. Push for code quality while you create the code. If you write the test before (TDD anyone?) or immediately after the implementation, writing unit tests is not visible as separate activity. The same is true for refactoring. Do not wait for Friday afternoon to clean up the code you wrote all week, because you might not have time for that. If you improve the code after each green test, there is no bad code even if you are forced to stop early. Further add the time for testing and cleanup to your estimates, but do not talk about it. I know some developers who estimate higher than others. Their estimates are accepted because their solutions are better and have less defects.

  4. Make excuses. Even technical managers do not know the exact details about the code you work with. Maybe there were some issues not anticipated during planning. There are always some. Communicate their (exaggerated) impact and argue that you needed some time to deal with them while in reality you had to restructure some legacy class to add to it.

  5. Finally, you can always find another job. Today you have more options than ever due to remote work.
There are several related questions on Stack Exchange which give more options, e.g. what do you do when your boss doesn't care about code quality or how can I convince management to deal with technical debt.

I wish you all the best for your quest for more code quality in your daily work!