środa, 18 maja 2016

An illustrated analogy to carpentry

Code is like a building material. Imagine the code you work with is wood.

Just like wood and wooden appliances, it can have different structure.

Just like wood, it is exposed to external forces and to the pass of time.

Just like wood, it requires different tools to work with it and turn it into something usable and beautiful. Humans devoted many past years to the invention and enhancement of these tools. It would be foolish not to use them.

In both coding and carpentry, we need to learn to use each tool. Otherwise we are likely to cause damage.

Depending on the craftsmanship applied to woodworking, it is either harder or easier to maintain and repair a wooden appliance months and years after somebody started using it. Same is with code.

Different types of wood have been recognized as particularly good for different uses. And our OS kernels aren't coded in Javascript.

The code that you are developing today - which piece of furniture is more like it?

wtorek, 29 marca 2016

Be a human, not a compiler

A recent reading inspired me to make an observation on programming skills and differences between those the masters and the laymen.

This is not the kind of information you will learn at university or a conference. This can change your professional attitude, so read on.

From the very beginning of our programming education we are talked into thinking like a compiler. We gradually develop the thinking that in order to write a decent piece of code we need to ask ourselves questions like these below:
  • how is this thing going to be evaluated by the computer?
  • will this index ever go out of array boundary?
  • can this variable overflow under any circumstances?
  • will this statement correctly modify / concatenate / process these numbers / strings?
  • is it then this pointer that is going to point at the result when the function returns?
After years of doing that, we are even inclined to judge others at job interviews by how they are able to answer these questions. The funny (and upsetting, at the same time) thing about this is that all of these questions can be answered empirically, by executing a piece of code on a computer. We could use a unit test framework to do this or evaluate the code directly, if we work in an interactive environment.

While I recognize genuine reasons why people think they should turn their compiler mode on while working, I also think there is more value in asking ourselves completely different questions, like these below:

  • does the piece of code I've just written remind me of any of the code smells I read about?
  • will it confuse others when they need to read it or modify it?
  • is there feature of my code that would be error prone to others when they modify it?
  • is my function / method design going to cause, indirectly, code duplication or other code smells in other parts of the codebase?
  • have I covered this piece of code with Unit Tests to the extent that nobody is afraid of modifying it in the future?
  • do I still see a potential for refactoring?
I strongly believe these two sets of questions differentiate the master programmers from the laymen. I believe the master programmers are not afraid to admit they are human beings. They know their code may not be good enough, even though it executes correctly on a computer and passes tests.

I'm not blaming the laymen though - after all that's the attitude that is expected and required of everybody at universities and then when applying for a job and even later when one already has years of experience...

But now you can no longer claim you didn't know. Tomorrow, when you sit at your desk, do something to advance in your professional career: when you write a piece of code, ask yourselves questions from the second list.

czwartek, 25 lutego 2016

Start with something irrational

In this post I want to provide some examples how a Scrum Master can use irrational cases to foster discussion at Sprint Planning.

By irrational case I mean here asking the team for an opinion about an irrational amount of work or considering an irrational amount of time to complete some work. Here are the examples:

A Scrum Team is planning to execute some manual regression tests that they know cannot be completed in one sprint. They want to spread the execution through a few next sprints. The Product Owner wants to get agreement with the Development Team on how much of the regression can be completed in the current sprint. The regression has already been divided into well defined, small or medium backlog items.

The Development Team stucks in the discussion and they find it difficult to discuss how much of the regression they can do. The Scrum Master may ask questions like these:
  • (A) can you do exactly one regression backlog item in this sprint?
  • (B) can you do half of the regression in this sprint?
Question A has much more power than it seems. One item of regression is already something. It is definitely better than zero regression items. The Development Team is very likely to say "yes, we can". If they can do one, maybe they can do two. Continue asking...

Question B is targeted at establishing a limit: is there an amount of regression that we think is maximum we can take into this sprint. Even at the expense of not doing any functional stories, or very little functional stories. In order to establish this maximum amount, we can start from an amount that we know is not realistic, like half of regression.

Another example is the ability of a Development Team to work concurrently on a story. Sometimes it is a challenge for a team to have multiple developers working on a single story. The Scrum Master wants to guide the Development Team to establish how many developers can possibly work on that story to help them understand the possible shortest duration of work. So, similarly, the questions could be:
  • can this story be worked on by one developer? Certainly yes, but if so, can we have two? Or three?
  • can this story be worked on by 9 developers? It is not likely that this happens in real life, so they are likely to say "no". But then maybe 6 or 7 is good?
My last example here is about longer term planning. There is an epic that may take several months to develop. Everybody knows it is going to take some time, but nobody is willing to stand up and say "that's going to be three months". Again, we are after establishing boundaries:
  • can this epic be developed in, say two sprints? we know the team will say "no", but let's continue the discussion - maybe four sprints is enough?
  • assuming this epic is really tough and most of things that may go wrong actually go wrong - can this work extend beyond 9 months? No... that's unprecedented. Not even with the hardest and biggest epics we remember did it happen. OK, so then we know at least that it is going to take less than that. How about 6 months?
The examples given above may seem a bit naive and we can expect criticism along the lines "what use do we have from establishing boundary values that are so apart from each other?". Don't be discouraged by that. Even if, judging by numbers, the boundary values are not extremely useful, they are still great starting points for fostering discussion and clearly presenting some tangible points the Development Team can consider.

sobota, 2 stycznia 2016

Looking back at the year 2015

I want to share some of my reflections over what I experienced in the ending year 2015 in software development area.

I attended two conferences this year: Agile Central Europe and Scrumdays (and ran a Practical Scrum workshop at the latter). The most influential and interesting speeches, in my opinion, were these two:
At each conference, there were lots of Scrum Masters (probably more than 50% of the attendees), quite many Product Owners, many "other people" and very little developers. What were they doing while their Scrum Masters and POs were at a conference? What other kind of gathering they attended last year?
Scaled Scrum / Scaled Agile
It seems like everybody wants to be doing Scaled Something nowadays and everybody wants Scaled Scrum more than they want decent Scrum. When Gunther Verheyen gave his presentation about Nexus at Scrumdays conference he made a joke that everybody wants Scaled Scrum to produce more crappy software. I believe Scrum Masters and Product Owners should pay attention to doing Scrum well not at least to the same degree as to doing scaling well.

Programming languages popularity
Java is making a strong comeback. According to TIOBE, it now has about 20% share. It had 14% at the end of 2014 and now it is back at the level it had in 2005 (15 years ago!). The popularity of Java is corroborated by the amount of job offers in this domain. This is very interesting trend, because a while back it seemed it will go out of favor.

Interestingly, pure C language has not fallen below 15% for the last 7 years and has pretty constant share.