ś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.

Conferences
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.



niedziela, 6 grudnia 2015

Limit WIP

Although Scrum Guide does not mention this explicitely, it is an important part of sprint planning and the sprint work itself to limit the amount of Work In Progress. Let's look at this aspect in detail and consider some examples.

Without the notion of WIP, several team members may just start work on several backlog items, say 6 developers start 6 different backlog items. In practice, this apporach often goes together with the phenomenon of one developer working on a single backlog item for several days - either because they are too big for one person to complete them quickly or because they are too big in general. If the backlog items are too big, each developer may work on their backlog item even for the whole duration of the sprint. Now, there are some disfunctions in a team that does this:

Teamwork
Each developer is focused on their backlog item, so there is no really teamwork there. If at least 2-3 developers focus together on one backlog item, it fosters collaboration and gives people common aim. Developers who work together on one item are also more exposed to changes being made in the code, because nobody is developing in a silo.

Predictability
It is very difficult to say if the team is going to each the spring goal at any point during the sprint - everything is in progress, everything is assigned, but what will actually be Done - this is unknown almost until the very last day. With smaller backlog items and 2-3 developers working on each, a substantial part of sprint backlog is completed during the sprint, so it is much easier for the team to gauge what will be completed by the end of the sprint (at least the items that are Done now wil be Done at the end of the sprint).

Sprint planning
With silo work and big backlog items the team is bound to miss important aspects of the spring planning meeting. After all, a developer that is going to work alone on backlog item A for 10 days will not have much to say about his plan. On the contrary, if a few developers work on each backlog item and the backlog items are rather small (say, doable withing 1-5 days each), the sequence of work is becoming very important during the planning. The team will not plan to start the bigger backlog items late in the sprint. They will consider the order of sprint backlog and the order of their planned work during the sprint to maximize the probability of achieving the sprint goal. They may even notice that what the Product Owner desires is not achievable in a sprint - not because there is too much work to be done but because the sequence of work puts constraints on the delivery.

In a well performing team, there should typically be more than one developer working on a regular backlog item. The backlog items should flow quickly from In Progress to Done, because they are small and two or more people usually work on each. The team may choose to set official WIP and put it on the corkboard - no more than 3 backlog items In Progress at the same time. Or they may just pay attention to it without setting the official limit. Finally, a good Scrum Team will pay attention to defining and splitting the backlog items so that they are small. It is not enough that a backlog item is just doable within a sprint. Smaller backlog items give the team more flexibility in the way they plan to sequence their work and allow them to start work on next backlog items even near the sprint end.

wtorek, 29 września 2015

C3 - the origins of XP

I think this is not widely known, even among Scrum/XP practitioners and therefore I would like to spread it: please devote 10-15 minutes of your time to learn about C3 - Chrysler Comprehensive Compensation project.

If you read even these three short entries:

you will learn why this project is regarded as the one that gave birth to XP and you will see which, now very famous, folks from XP/Scrum world worked on C3 in the '90s.

To give you a trailer, this is what Chet Hendrickson wrote in the article that I provided the link to (last from the list). Share this with your Product Owner :-)

When C3 was restarted under Kent Beck’s coaching, Marie sat down and wrote the user stories we needed for the first release plan. She was able to explain how the stories fit together. She assigned their priority. She questioned our estimates. She would have made the estimates, if we had let her, and she would have down about as well as we did. She approved every acceptance test. She did a hundred other things that we eventually took for granted.

We don’t know how Marie learned to do all of this. Marie didn’t know how she knew it. She must have known before we started the project, because we don’t know how Marie knew these things, we were not able to help her do them. And, because Marie didn’t know, she wasn’t able to teach others how to help her (...)