Tuesday 27 October 2015

The Way Agile is Fast - Fast as in Orienteering

Dear Junior

It is often claimed that agile development is faster than the alternative approaches. However, "faster" used this way might be misunderstood. For example, we all know that running can be tiring, so running faster can be exhausting. 

Does agile development mean that we will exhaust the poor developers? And do so sprint after sprint? Does it mean we induce stress ulcer? Or will the developers have to cut down on testing, design, and quality to meet this faster pace of deliver?

Quite the opposite. Agile is faster in another way. It is not faster as in a long-distance runner being faster, rather in the way an orienteering runner might be faster - by making smart choices of route.

In agile we realise that developing systems is not running down a pre-routed track. It is more alike to make our way through wild terrain. When doing this it is crucial to early see if we are moving down a dead-end route, and then stop ourselves. To run down a dead-end route without getting anywhere is the most wasteful exhausting thing an orienteering runner can do.

In agile we try to adress this at as many levels as possible. To prevent the individual developer go down a dead-end without realising it, we have pair-programming or daily stand-ups as reality checks. At a team-level we have short sprints, or watch the kanban cycle-time, to prevent us from working on stuff in a bad direction for too long. At project- or initiative level we do impacts map and similar to ensure we do stories that matter. At the level of finance/funding and portfolio management we track effects to stop us from continue spending huge effort on stuff that give no or low effect. 

So, agile does not make us faster by making us run at a more exhausting pace. Agile makes us faster by giving us tools to take smart routes, preventing us from detours.



ps This is of course related to how Domain Driven Design makes us faster, even in the short run. Using the orienteering metaphor, what you to is to slowly jog for some a short period of time while exploring the map for different routes.

Tuesday 24 March 2015

Coding Kids, it is about Democracy

Dear Junior

These days it seems like a lot of people think it is important to teach kids to code. I would like to chip in my idea about why this is important. To me, it boils down to a question about democracy, but let us not start there.

Code as a Profession

The first argument is about job market. There is no doubt that today we are already short on good system developers, and all predictions and forecasts say that this is going to get worse. So, going for a career in system development seems like a good hedge. This is the argument seen from the perspective of the individual kid. On a side note, I'd like to add that I personally think that system development is an interesting mix of creativity, intellectual stringency and cooperation; so apart from being a job that will probably be in demand it is also a job that is quite fun, when done right.

This argument also have the macro-economic side: companies need system developers to be able to continue their development. With a lack of skilled developers, the companies innovation pace might come to a halt, which would harm society at scale.

So, learning to code is obviously a good way to take the first steps towards a job in systems development.

A historical parallell is that there was a time when reading and writing was only relevant for a small 

were jobs where reading and writing were essential skills: handling written text where in those days mainly done by priests and medieval administrators where in those days that where handling written text. Written text was irrelevant to the rest of society.

This as definitely been true for code. Code was essential for the coding professions - a limited number of engineers and researchers - but not outside those circles. Code was irrelevant to the rest of society. 

However, I think that has changed. Code is no longer important only for those that work as programmers. Today the ability to code to some degree is fruitful to other professions.

Code in more Professions

Thus, second argument is that more jobs will involve code. If we look outside the profession of system developers, there are already places where coding helps people do their job better. Imagine Susan in HR, who is working on gender equality issues and is curious about how the salary level compares across different department, different ages with respect to gender. 

Susan has all the data at hand, perhaps in a few spread-sheets, perhaps in some simple database. Now, she could ask the analysis department to do some statistics which she could analyse to see if there is something to her hypothesis. That would probably take a day or two before they come back. But, if Susan herself can put together some SQL-queries or some scripts, she can get the result the same afternoon. The difference in how well she can do her job - analyse if there are salary differences that should not be there - is significant.

Knowledge in coding is not just a profession in and of itself. It is also already a helpful tool in other professions, and I think it will soon be essential.

A historical parallell could be at the beginning of the industrial revolution. At this point written text was not something that was relevant for the text-professions priests and adminstrators. Suddenly the factory workers where supposed to be able read, reading written instructions or work orders. To start with only the foremen needed this, but soon enough literacy was expected from all workers.

I think this is where code and society is today.

Code in Society

Looking forward, I think it will not stop here. I think understanding of code will become even more important.

Let me start with the historical parallell. After industrial revolution society evolved together with the usage of text. Text weaved into the fabric of society. People who could read were able to follow the news in the spreading news-papers. People who could write were able to participate, write letters to the editors. In parallell civil associations arouse such as workers unions or the anti-drinking movements. These were all possible because their member were able to read and write, to document their meetings in protocols, to create pampflettes to spread their ideas etc. The raise of modern democracy was fuelled by people knowing text.

People who could not read or write were soon standing at the side watching society evolve, more or less unable to participate.

I personally had a revolving experience. An a journey in China in the mid-90s I found myself standing at a cross road in the middle of Beijing. Everywhere I looked I could see text, massive amounts of text. Every shop I could see had signs promoting their wares, there were banners and posters, there were road signs, there were advertisements for papers. Texts everywhere, massive amount of information, a world that everyone around me navigated trough without effort. And I did not understand a single thing. 

Here and there I could see a sign I could recognise, the sign for "north", the sign for "water" etc. But I was feeling totally alienated. Watching people around me naturally navigating on this ocean of information, it felt like being surrounded by magic.

It was not hard to relate to what it must have felt like being an illiterate while society quickly evolved, suddenly just assuming that people in general would understand text and could participate.

I think this is where code is going. 

A World of Automated Processes

Already today we are surrounded by automated processes - powered by code. Most of them are pretty trivial, for example paying a parking using your credit card by checking in and checking out. Some of them are a little bit more complicated, e g when you order goods online and you can track the goods until it arrives at your post office, coupled with status-notification to your mail or phone. Some are pretty complicated. In Sweden the taxation rules for partnership incorporated companies are somewhat complicated - there are several set of rules to chose from and they give different results. However, when declaring taxes on-line on the tax authority web site - then the system helps you chose the set of rules that are most beneficial to you. Even though I know it is just code, it feels a little bit like magic.

We are probably only in the beginning of this evolution. Within a few decades, automated processes will be in much more places, they will be much more complex, and they will probably be interlinked. They will be part of the fabric that constitute society.

Those people that know code, they will be able to understand, to participate, to protest, to support. The people who do not understand code will be standing at the side, watching society evolve, more or less unable to participate.

I realise this might seem like jumping to conclusions. But think back. When industrialisation was new and reading was mostly used by foremen to read work orders and instructions - did it seem probable that reading and writing would transform society, making those skills essential to participate in and effect society at large? 

I think that understanding code will be the literacy of tomorrow.


Teaching kids to code is not just about opening the door to the programming professions; it is not just about giving them a better chance to do their non-programming jobs well; at stake are giving them the foundations they need to participate in society; it is about democracy.

That seems pretty important to me.



Friday 13 February 2015

CSR, Knowledge, and a Student Conference

Dear Junior

At Omegapoint we have for a long time struggled with the question: How can we contribute towards society? Or, put otherwise, how can we pay back to the society to which we owe so much? To use the business lingo phrase: How do we exercise our Corporate Social Responsibility (CSR)?

There is the obvious non-answer: We already contribute to society though our business. We pay taxes without fuzzing or hiding. What we do for our customers must be good in a broader sense, otherwise they would not pay for it. So, obviously we contribute.

But our moral standard is somewhat higher than that kind of waterline mark.

Of course there is always the easy way out: Donate money to some beneficiary organisation. And of course we have done so. But it does not feel completely satisfactory. Anyone can donate spare money: should we not pay those money as salaries and let our employees donate at their own discretion? What could we as a company contribute with?

Also we have done pro bono work: helping NGOs with their web-sites and support systems. Also we have given pro bono aid and coaching to local startups. Of course this is better, but we were still not completely satisfied. Lots of other companies could do this, it did not feel unique to us.

Slowly has the realisation dawned on us. We define ourselves as a knowledge company with an attitude of openness. The epitome of this is our semi-annual two-days competence conference, affectionately named OPKoKo where we run presentations, workshops, and discussion - all powered by stunning colleagues and some occasional guest. This is the soul of Omegapoint, this is what we should share.

Sharing with whom became pretty obvious. At Omegapoint almost everyone has studied at a technical university, apart from some remarkable autodidacts. In Sweden university education has no tuition fee at any of the universities - it is funded through taxes instead. This means that even the best universities have a steady flow of talented young people from all corners society. Omegapoint as a company is build on this foundation. We should pay back to Swedish Academia, and its education of students in particular.

Once question phrased, answer was simple. This spring we will run our first student conference: Studentkonferens 2015 by Omegapoint Academy.

We have put together a one-day conference with three tracks: programming, security, and testing. We will bring our experts from the field to spend a day presenting, discussing and socialising with the students. 

We have tried to pick subjects that are as relevant to students as possible - not far-away is about "strategic architectural enterprise business process modelling", but rather about stuff they can relate to and hopefully use immediately. We ended up choosing "Craftsmanship" as the theme.

Now, "Craftsmanship" is a term that has been thrown around our community left and right, and I am definitely sceptical to some uses of the word. Still, I think the original message of craftsmanship holds: love the craft, pay attention to what matters, be pragmatic.

Yesterday we announced the conference to the public during the Datatjej2015 conference run by female-CS-student association Datatjej. This is not a coincidence. 

At Omegapoint we always hire on merit. The idea to select from non-relevant attributes as gender or ethnicity is completely foreign to us. However, we also do know that women have had (and still have) a harder time in our industry than men. Thus, we want to encourage initiatives that encourage young women to make a move in our industry. Hence, it makes sense to draw some attention to Datatjej2015 by selecting that event for announcing our own initiative.

Now, this is going to be fun. Also, I have been given the honour to present the opening keynote, presenting my view of Craftsmanship in software development. I am really looking forward to all of it.



PS To pay credit where credit is due, I really must praise my colleagues Lotta Hammarström and Daniel Deogun. They where both part of the original idea, and have really worked hard to it come alive.