Experiences from programming with kids

I was kind of scared beforehand but afterwards I felt just great. Couple of hours ago I was teaching 1st to 6th graders programming and it was so much fun! Let me share with you my experiences so that you can do the same thing somewhere else.

Background

Keinutien ala-aste (elementary school, grades 1-6) in Helsinki decided to organize a special school day on Saturday 27th September, 2014. The theme of the day was the popup school. The idea is that anyone (kids, parents) can teach anything and the kids can decide what sessions to participate in. So I volunteered and decided to teach kids how to program. I wouldn't have done that unless there had been so much fuzz about code schools in Finland during the past year. Without that there probably wouldn't have been ready-made material available either so thanks to Juha Paananen et al. for making the koodikoulu.fi and Turtle Roy available for anyone!

Preparing

Because I wasn't sure what to expect when working with children I wanted to test it. First I tried my ideas with my 6 year old son who goes to the first grade next year. Since that went so well, taking into account his age, I was encouraged. Especially I got convinced how to start each session (I'll tell you more about that later). Next I tried the same things with my 8 year old son and his friend. I felt that I was pretty much ready for the show.

Couple of days before the school day I asked the organisers to check that our coding environment, Turtle Roy works as expected. The local IT teacher found out that it works with Chrome but not with IE. He tested moving and turning but unfortunately not sequences...

Right before the sessions

I was told that there are going to be 4 sessions with 20, 10, 7, and 16 students. Usually in code schools here in Finland each kid has a parent along and they work together in the same computer. In this case there were going to be even twenty kids and only one adult besides me! So I was a bit frightened if it's going to be just one big mess. One thing that I noticed when practicing the code school was that 8 years old kids need lot of support with the keyboard. So how on earth is it going to work if there are 20 children needing the support?! Well, luckily most of the kids were older than 8.

When I went to the computer room, I checked that everything works nicely. Oh shit, I wasn't able to type square brackets meaning that I couldn't write this important piece of code: s [fd 50, lt 90]. The brackets worked elsewhere but not in the command line of Turtle Roy. So we had to figure out a quick workaround, which was to write bracket somewhere else and copy it from there to the command line. (The square bracket issue has been fixed.)

Content of one session

Let me next describe the basic structure of each session. I decided to follow the steps described in the Turtle Roy Github page. Besides that I added one important step to the beginning, right after the introduction.

Introduction

First I introduced myself and told that I'm like a professional football player: some people pay me money for doing something that I feel is my hobby; I'm a programmer. Next I asked who has used some computer program this week. After only some of the kids raised their hands I asked another question: who has used a mobile phone or played any computer games this week? Now when everybody had raised their hands I explained them that the games are programs as well and someone has programmed them. I explained them that programming means that someone tells the computer how to behave and today the kids are going to do exactly that.

I had asked them to form pairs. One reason for this was that it halved the amount of helping we had to give for the kids. Another reason, which I told them, was that programming quite often is pair or team work. So these kids started their career by pair programming. :)

Practicing without (real) computers

Inspired by the experiences from ICT-portti I decided to start without computers first. I told the kids that I'm a computer now and they need to program me using the commands: "move forwards", "turn left", "turn right". Their task was to transfer me from my current location to the other side of the room. I emphasised that I won't understand any other commands. So for example if someone said "jump", "move" or "go left", I replied: "I don't understand the command".

The students got the idea quite nicely and every group managed to get me to the goal. Also in each group I got wrong commands. This helped me when getting to the next stage. Let's start programming with the real computers but remember kids, you have to be very specific when giving commands for the computer!

Moving and turning

We started the Turtle Roy programming with the simplest command that I had written to the whiteboard: fd 50 (move forward). This was trivial for most of the kids but even here some of the youngest needed a bit of help. The next commands were naturally about turning: lt 90, and rt 90.

When everybody got their turtles moving and turning, I encouraged them to try what happens if they write e.g. fd 100 instead of fd 50. This was actually one of my key thoughts: the kids should try and see what happens because that is actually quite an essential part of programming many times. In other words, there are no mistakes or wrong solutions. The only mistake you can make is not to try.

Since by trying (obviously they try what happens with the command fd 1000000) they got quite a mess for their boards, I told them about the fourth command: clear.

I also explained what the number 90 means in the turning commands by drawing it to the whiteboard. Basically, if you want to turn a bit less, try e.g. lt 30. If you want to turn a bit more, try e.g. lt 120.

For the older students who already are learning English I told how the commands come from English. fd means forward, lt is left turn and rt is right turn.

The square challenge

Then I gave the kids a challenge: they should try to draw a square. I helped them by asking how they should command me if I was a computer again. The kids started typing: fd 100, lt 90,...

This was the place when the first ones got really excited when they realised how they can draw something more meaningful.

When the squares were ready, I asked the kids that wouldn't it be nice if they could make a square with only one command? In order to get there I asked if they saw any repeating pattern in the square commands I had written to the whiteboard: fd 50, rt 90, fd 50, rt 90, fd 50, rt 90, fd 50, rt 90. This was a nice step to the next phase.

Sequences

The sequence was the most difficult thing during our session because of the bracket issue. So we had to help the kids a lot so that they were able to write the sequence command: s [fd 50, rt 90]. I felt that some of them had to give extra focus so that they don't get frustrated. But on the other hand when we got the command ready together, they got excited again.

Here I also advised them how to use the arrow keys so that they don't need to rewrite the same command again. So very quickly after the initial troubles the kids were able to draw a square by repeating the sequence command four times.

Repeating

The natural follow-up question for the kids was that wouldn't they like to do the whole square with a single command instead of four commands? After all, computers are really good at repeating things that human beings find boring. So it was time to introduce the repeat command: r 4 (s [fd 50, rt 90]).

I remember how some kids responded with bigger eyes and smile when they run that command. Now they managed to do the whole square with just one command! And more was coming...

Let's play!

My last advices were that now it's time to play. Change the numbers in the latest command using the arrow keys. Don't repeat just 4 times, repeat for example 40 times. Don't turn 90 degrees, turn e.g. 50 degrees. And for some I also said that they can add more commands to the sequence. Anyway, the most important message I wanted to give them was that try things out, play with the turtle, and have fun! It's actually quite amazing what kinds of beautiful flowers, stars, or gearwheels you can get with that simple command when modified.

I also promised that the pair that draws the best picture gets a reward (lollypops). My tip for that was: those who are willing to try out different things are going to be the best ones.

This was again one of those moments that were full of wows and smiles. It was really rewarding for myself to get all the way here and see how the kids had learned so fast.

What not

I was prepared to teach them how to play sounds (e.g. play [c, d, e]), how to make the turtle speak (say "hello world"), or writing (print "hello world") in case there was any time left. But as I had guessed, the 40 minutes went so quickly that we didn't do these in any of the sessions. So neither had we time to see any "real world" code. Maybe that was just a good thing because I had some Java code open in my laptop at that time...

If there would have been another session with the same kids, we would have probably tried to write some functions as well. It would have been really interesting to see if they get it or not.

Afterwards

Like I said in the beginning, I had really good feeling about the sessions afterwards. I had some fears that mostly did not come true. Instead I saw many moments where kids learned fast, where they "just got it", and where they smiled when they succeeded.

The only thing that I was a bit disappointed was that none of the pairs helped the other pairs. I had hoped that I would see more advanced students giving help for the less advanced without asking it. But that didn't happen. I wonder if it has something to do with our school system or was it just how our setup was in the sessions.

One of the best things was when my assistant teacher, the local IT teacher, said that he is going to start using Turtle Roy in his own IT classes with 4th graders. He was convinced that this is a good method and it will be valuable for them. This teacher is btw going to be ahead of his time since programming will be part of the official curriculum in Finnish schools 2016.

Lastly I want to say my special thanks for all the kids who attended my code school. I had really good time there, thanks to you!

About the definition of #NoEstimates

I’m writing this blog post because I see too much confusion in what #NoEstimates actually means. I believe that if we could get rid of the unnecessary waste around this topic, we as a software development community could get much more out of it.

The definition

Although Woody Zuill defined the #NoEstimates already over a year ago, it hasn't been widely used since. Nevertheless, I like his definition:

"#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. That is, ways to make decisions with 'No Estimates'."

The core of the definition is that #NoEstimates really is just a hashtag. Let me clarify more what this definition means in my opinion.

What it is not

• #NoEstimates is not any method, tool, or process that you can directly apply.
• #NoEstimates is not a “follow these 10 steps and you will be doing it properly”.
• #NoEstimates is not estimates related discussion in every possible context. For example it’s not discussion about estimating who will win the World Cup in Brazil or how long a trip from Helsinki to Brazil would take.

What it is

• #NoEstimates is one approach to the Agile Manifesto first sentence: "We are uncovering better ways of developing software by doing it and helping others do it."
• #NoEstimates is discussion about software development cost estimates, what is wrong or right with them, and especially: what alternatives to estimates there are for making decisions in software development (see Woody's definition).
• #NoEstimates is a wake-up for many developers and hopefully in the future for many more managers and business owners that estimates are not always needed.

Who are the proponents?

#NoEstimates proponents are those who feel that there is a need to seek alternatives to cost estimates in software development decision making.

Who are the opponents?

Since #NoEstimates is about seeking alternatives to estimates, opponents of it are those who either don't believe that better alternatives exist or for some reason are not willing to look for them. If you challenge someone's suggestion for an alternative, that doesn't make you an opponent, you are just taking part of the discussion. Obviously if you decide to stay out of the discussion, that doesn’t make you an opponent.

(I updated the opponents section Jun 4, 2014.)

The essence

The essence of #NoEstimates is in those stories that tell about the alternatives. Like:

• 'No Estimates' in Action: 5 Ways to Rethink Software Projects
• Use #NoEstimates to create options and deliver value reliably
• No Estimate Approach For End-Of-Life Legacy Support
• From schoolbook Scrum to Kanban without estimates
• Some of my blog posts, for example From #estwaste to #NoEstimates and Need to estimate.
• And many many more...

(Please propose a link, I can add it to this list.)

You can breath now

For those who find #NoEstimates frustrating, I’m hoping that you can breath better from now on. This is just a hashtag and it will never give you all the possible answers to your estimates related questions and problems. But if you are open-minded and willing to search for something better, there is a big and smart community available to help you.

It’s all about trust

Do you trust your code? When you start building a new feature, do you feel confident that all the current features still work after your latest changes? When a new developer starts reading your code, do you trust it’s easy for her to understand what you have written? If you don’t trust your code, is it because you don’t have tests for it or is it because you don’t constantly refactor it? Or is it because you never or rarely pair program or ask your colleague to do you a code review? What can you do to increase your trust on your code?

Do you trust your integrations? When you have your application running with the latest changes, do you know that all the integrations between different layers and services still work? If not, is it because you have no end-to-end tests that you can run automatically? What can you do to increase your trust on your integrations?

Do you trust your releases? When you are releasing your software, do you trust that everything will be ok? Do you feel safe for deploying many times a day or does it take weeks to prepare your release. If you don’t feel confident for releasing often, is it because your deployment scripts are a mess or is it because you don’t know if the software works or is it because it’s so difficult to roll back? What can you do to increase your trust on your releases?

Do you trust your team mates? When you agree with your team mates about the work to be done, do you trust that they can do it properly? Can you trust that they spend their time wisely and for the good of the team. If you have hard time to trust them, is it because instead of a shared goal everyone is going to their own direction? Or is it because you don’t actively communicate with each other? Or is it because instead of sharing your code you work in silos? Or is it because you don’t constantly try to find better ways to work? What can you do to increase your trust on your team mates and their trust on you?

Do you trust your manager? When you have a problem in your work that you find difficult to solve, do you trust that your manager will help you for solving the problem? If the manager isn’t able to help you, is it because she cannot see your problem? What can you do to increase your trust on your manager? What can your manager do so that you can trust her more?

Do you trust your employees? Do you believe that they are able to do the best possible work. Is it easy for you to let them do their work or do you feel that you must control them? If you find it difficult to trust your employees, is it because there’s no enough visibility? Or because you are not happy with the results? If you are not happy with the results, are they bad because your employees do not know what is the direction the company wants to go to or because the employees don’t have all the information they need to do their work? What can you do to increase your trust on your employees? What can you do so that they trust more on you?

Do you trust your customer? When you work together with your customer, can you trust that the customer does everything so that your mutual business will work? If not, is it because you are not able to constantly show your progress and the quality of your work? What can you do to increase your trust on your customer? What can you do so that your customer can trust more on you?

Do you trust your supplier? When you work together with your supplier, can you trust that the supplier does everything so that your mutual business will work? If not, is it because you are not willing to share all the information the supplier needs or because you are not willing to give enough your time for your supplier? What can you do to increase your trust on your supplier? What can you do so that your supplier can trust more on you?

Software development is about trust. Well, all business is about trust. Do you increase or decrease trust around you?

And by the way, do you trust yourself?

Need to estimate, part II

In the spirit of Need to estimate, the following discussion happened yesterday.

- I know that you don't like estimating but I'm afraid I have to ask you to do that. We need to know which of these (on the wall) will be done by the end of March.

- I don't have a problem for estimating if that is the valid way to solve the real need. So first I would like to understand what kind of decisions are made based on these estimates.

- Well, it's important to inform certain people if this (pointing to a task on the wall) won't be done because then they have to find another solution for the problem.

- Are you sure asking the estimates is the right question here? Isn't the right question, at least initially, whether we should build this feature at all? I think we talked earlier that it actually doesn't make sense for us to implement it since it kind of doesn't belong to our application?

- Yes, I guess you're right. And there will be so few users that it won't pay back if we build it. Manual work for these cases should be just fine, at least by now.

- Exactly.

- Ok, I will just tell them that this won't be done by the end of March and actually not at all in the foreseen feature. Thanks!

- Sure, no problem.

Need to estimate

Before going any further, I would like to mention that Neil Killick has written an excellent post related to this same topic: People Need Estimates. You might want to read that post before or after my post, which tells one story where estimates were "needed".

We need estimates

Prioritization in our project was initially made by dividing the features into four categories: must, should, could, and won't have. Our team had basically finished all the must haves and since there was time left before the pre-defined launch date, the management wanted to prioritize the should haves.

The should have items had already been prioritized based on business value and the request for the team was very clear: the management needs estimates for all of the should have items so that they can make the final prioritization.

Or perhaps something else?

I already revealed above what the management actually needed. They needed to decide how the development team should spend the scarce time there is left before the launch. They didn't need estimates. Surely estimates is one solution for this problem, a very typical one actually.

So what's wrong with the estimates related solution? One thing is that if you don't estimate the value, estimating the cost is quite debatable. Another thing is that in this case the should have list was very long. If the management wanted the team to estimate the whole list, it would have meant that we spend several days on trying to understand what some of the items mean and how we should implement them. Or we could have just thrown the famous "educated guesses" without even knowing what we were supposed to build.

Input for management

I didn't like either of the approaches so we did something else. We had all the items on our whiteboard vertically placed in the initial priority order. We went through the list and placed each item horizontally in one of the three columns: simple, complicated or external dependencies, and very unclear or lot of uncertainty. This took about an hour of our time.

When we presented the revised list for the management, our message was the following:

• The items in the simple column are such that you could move them up in the priorities if you like since they should be rather straightforward to implement.
• The items in the complicated column contain more risk and you may want to drop their priority if you like.
• If there are some really important items in the very unclear column, we should investigate them more so that we can understand them better. (But we shouldn't investigate all of them because that would really waste our valuable and scarce time.)

Besides that we told them that if they really need some numeric values, we can use our statistics about the development lead times. They weren't interested in the numbers, the table was just fine.

Decisions made

Probably the most interesting thing happened (or did not happen) after we had presented the table: our categories did not really have an effect on priorities. The items that were initially on the top had so clear business value so that they remained on the top although they were mainly complicated ones. The simple items did not get to the top even though there were - well, simple. And the management asked us to spend time on only one very unclear item.

This tells me the message that the estimates were initially asked basically just because that's how it has always been done. On the other hand, it tells me another message too. Our management (intuitively perhaps) understands that it shouldn't focus too much on the short-term development cost but rather on the long-term business value. This is something I really like.

Do we need ROI in prioritisation?

Return on investment (ROI) is a tool used in accounting to measure investment profitability but also in software development to prioritise backlog items. The idea is simple. Let's define the value that a backlog item generates, estimate the investment cost, and then we can calculate its ROI: (value - cost) / cost. When we have these for all items in our backlog, we can sort them by ROI and build the items with highest ROI first.

Where's the value estimate?

Although the idea is simple and compelling, I've never seen it being used in practice. Or to be more precise, I've only seen half of it being used. In other words, I've been in projects where the developers or other people try to estimate the time (cost) it takes to build something. However, I have never been in a project where the value estimates have been made for the backlog items with same accuracy. So, why to bother estimating the cost, if we don't estimate the value?

Probably the reason why the value is rarely estimated, is simply because it is more difficult. It's often quite easy to say that one feature is more important than some other feature and provide convincing arguments. However, saying how much more important in terms of money is much more difficult. I guess this is because features usually are a part of something bigger and it can be really hard to track their effect on revenues even afterwards.

Simplified ROI

So how can we make proper prioritisation if we don't know the exact value that features bring? One solution for this is to simplify the ROI formula. Please consider what happens if the cost is 1, i.e. if all backlog items are approximately equally sized. The formula becomes ROI = (value - 1) / 1, which is basically same as ROI = value. This means that we don't have to know the exact numbers anymore. It's perfectly fine to say that this feature is more important than some other and make the prioritisation decision only based on that.

Obviously this works only if the development team knows how to split the tasks into small enough pieces. If your team has tasks that take 1 day and tasks that take 1 month, you cannot use the simplified formula. But if all of your tasks basically take 1 day, you can just focus on the value the tasks produce.

You may say that the formula cannot be simplified like that if tasks sometimes take half a day and sometimes 1.5 days. The latter is three times compared to the former, right? But I think that in our highly variable software development context it's ok to estimate those tasks as an average of 1 day. Although we might have an idea that something takes half a day instead of one, the experience has shown at least for me that those estimates aren't very reliable. So from the estimating point of view, using the average of one day is just fine.


PS. You may want to read my comment from the comments section. It hopefully clarifies this post somewhat.

Will we be faster if we’ll have an extra developer?

This week I was asked a really difficult question: Are we ready sooner if we'll have a new developer?

Before exploring this any further I would like to mention that the question itself tells something about the asker. Instead of assuming that of course adding a new developer will make the team faster, the asker was aware that especially in software teams this isn’t always so. There’s even a risk of the opposite.

Nevertheless, we had to make the decision because we are in the middle of the project that is running out of time. The cost of the delay is quite big and we already have used many other tools for meeting the deadline, including reducing the scope heavily. Before I tell you what our decision was, let me explore the advice I got from the precious Twitter from my precious friends.

1. Ask first the opposite question

First of all, Torbjörn Gyllebring gave this excellent advice (read the second sentence):

I think this a great starting point. If your team would be actually faster by making it smaller, then it obviously won’t be faster by having an extra developer. I’ve been in a team having 13 developers (incl. a tester) at some stage an losing some of them didn’t make us any slower. And it wasn’t about getting rid of the bad developers. For every team there is an optimal size, which isn't "the bigger, the better".

Anyway, getting back to our current project. This advice didn’t help us because we already had a small team and removing someone would probably slow us down.

2. How well is your problem understood?

Now read the first sentence of the previous tweet. It might be that the structure of the problem is such that scaling is unfeasible. This resonates really well with me since couple of weeks earlier the answer would have been definitely "No". Our biggest challenge in the beginning of the project was to understand what we were actually about to do and especially how we should do it. The domain in a high level is quite easy to understand but the details are not. Besides we are heavily dependent on underlying systems, and the integration flows aren’t really obvious.

However, when the question was asked, we already had solved the biggest problems in this area meaning that we knew what kind of code to write. So neither this comment helped giving the answer.

3. What is your current codebase like?

The next good advice was related to the quality of the codebase:

I think that this too is a valuable advice because the quality of the codebase really affects how fast the new team member can start being productive. A crappy codebase can mean that the developer needs months in order to become productive. In a good codebase that can happen within days.

Luckily our codebase is really young. Or to be precise, we are extending an existing codebase but the features we create are completely new and I would say that at least 95% of our code doesn’t touch the existing one. So neither this prevented us taking an extra developer.

4. How good is the potential developer?

One of the advice I got on Twitter was related to the skills of the new developer. It is actually pretty obvious that the skills matter a lot. If the new developer just started coding last year, she probably won’t be very valuable if the other team members are much more experienced. In such a case the team probably requires certain level of quality and guarding that may take the precious time of the experienced developers.

But even though you’d be offered a senior developer, how could you really know her skills? We can read her fancy CV but due to the critical deadline there’s not too much time to spend on interviewing or testing the developer’s skills. What helps in this case is really simple. If you know the person beforehand, you don’t have to spend your time on that. And now we are very close to our decision…

5. Can you have a developer that’s already familiar with the system?

One of the developers in our team suggested that we could borrow a developer from another team close to our project. I really liked the idea because besides we knew his skills, we knew that we don’t have to spend too much time on teaching him. And that was our solution: we’ll be faster if we can have this particular person. An hour later we were told that he will start the next day.

Formula for selecting the answer

If we collect all the advice together, I think we have a decent formula for defining whether an extra developer would make the team faster:

1. Make the sanity check first - would removing one developer make you faster? If yes, then forget the new one.

2. Is your problem understood well enough? If not, don’t try to solve a wrong problem by getting a new developer.

3. What is your current code base like? If you don’t have too much technical debt, you might be lucky.

4. How good is the potential developer? It also helps if you know the person beforehand.

5. Can you have a developer that’s already familiar with the system? If you can, your chances increase.

I think it’s important to notice that all of these questions are somehow related to time. The questions 3-5 in such a way that you need to have more time in order the new developer to make the team faster. The questions 1-2 so that if you first solve some other problems, maybe later you can have the benefits of an extra developer.

What if I still cannot answer the question?

It’s easy to admit that the formula above isn’t very exact. Maybe I should rather use the word guidelines. Anyway, it might be that your problem domain is probably clear enough but you are not sure. Or that the developer probably is good enough but you are not sure whether she’s good enough taking account the time you have. And so on. In that case assuming that your cost of delay is big enough - meaning that wasting money for an extra developer isn’t issue as long as she won’t make the team slower - you probably just have to do what Vasco Duarte suggested:

There are things that you can only find out by trying. On the other hand, you may want to mitigate your risks. If the lost money isn’t the biggest issue, the biggest risk probably is that your team will get slower. This could be caused that the other (fast) team members need to spend time on helping the new developer. One possible solution for this is to throw the new developer into the cold water. If she can swim alone, she probably will be helpful for the team.

How about your team?

So here are my questions for you. If you were asked the same question, what would you answer and why? Would you have an extra developer? Would you make the decision based on the advice above or use some other ways to decide?

PS. I started this blog couple of months ago. Thanks for all the readers. Next year I will continue with the same goal as this year: one blog post per month. Merry Christmas and Happy New Year!