Archive for the 'programming' Category

slides and source for answer set programming session at spa 2013

Monday, June 24th, 2013

Marina de Vos and I ran a session on answer set programming at the SPA 2013 conference.

Download the code and the slides
Download just the slides

The code contains a git repository. In the answer_sheet directory you can find in small steps the painting by numbers exercises we ran, as well as the solution to the tweety exercise and the graph coloring exercise that we did. We recommend to persist as long as possible before peeking. The final sample also shows how to calculate the minimum number of colors, so once you’re done with coloring the map, have a play with finding the minimal number of colors.

Cleaner code in other languages

Monday, May 17th, 2010

At SPA2010 Rob Westgeest, Marc Evers and yours truly hosted the workshop “Flying horses, Cleaner code in other languages”. This is a quick writeup accompanied by the flipcharts that were created by the groups to summarize what they learned.

We brought one exercise, to be carried out by pair programming. A pair can choose what ever programming language they want to use. We try of course to get an interesting variety of languages to learn from. We ran three 40 minute timeboxes. Each timebox consists of 25 minutes for actual work, and 15 minutes reflecting (about three different solutions presented on the projector accompanied by discussion). Some people switch pairs from one timebox to the next, so they can get hands-on experience of trying to solve the same problem in different languages. The goal of the exercise is not to finish first, or have the cleverest solution, but develop a solution that is idiomatic in the language one is solving it in, so that we could compare notes afterwards.

This time we had three pairs working in smalltalk (cincom smalltalk as well as squeak), two pairs in ruby, two java, and further pairs in Scala and Haskell.

A few pairs wrote examples using Rspec or Scalaspec, most pairs wrote ‘classic’ XUnit style tests. Some worked completely outside-in, other bottom up, and quite a few from the middle outward (me and my pair amongst others).

Some things that struck me:

  • at least one of the smalltalk solutions I saw did not strike me as very idiomatic smalltalk (admittedly, the presenter said it needed refactoring, so they went for make it work/make it right).
  • Nat Pryce noticed that collections were processed easier (and with less code) in the Haskell and Smalltalk solutions than in Java.
  • The smalltalk pairs were the first ones to finish setting up their development environment and getting to work (Rob did a timecheck, the smalltalkers were the only ones working on the problem already). Having an environment that contains almost all the tools and libraries that you need gives a big speed boost at the beginning. What was more striking still was that all smalltalkers used environments they just installed and had not used before; I installed squeak last weekend, the others were using a fresh beta version of their environment.
  • Many people had not seen (much of) haskell/ruby/smalltalk style of iterating over collections using blocks/closures, luckily these idioms seem to be trickling down to Java and C#.

As with the previous instance of Flying Horses, the Haskell pair was moving towards a complete solution the fastest. This may be because the exercise we use seems to find itself in Haskell’s sweet spot (parsing and manipulating data).

On the whole, the level of engagement was pretty intense (about half the participants continued working through the breaks, even though we emphatically tried to get them to stop ;) ), participants said they got to see some very different ways of solving a problem from what they knew, so they came out of the workshop with puzzles to investigate further.

As one participant mentioned, code presentations work up to a point. They show what a pair has done, but it is hard to see what steps they have taken to get to the solution. Seeing the sequence of steps (and experiencing it) when you are part of a pair (especially with someone you don’t know) is very valuable. I’m interested in suggestions for getting more of the sequence of events (rather than the solution) out into the presentations.

We have tried letting people work with task lists and presenting from there (works somewhat, but may cause pairs to loose to much time on their small design up front).

Let a thousand languages bloom ;) Below are the flipcharts summarizing some of the things people learnt from the workshop.

Spa 2010: hand-on and sit-back-and-relax

Friday, April 16th, 2010

I intended to write about other things than just conferences, but SPA 2010 is going to be too much fun to let you miss it, so I’ll break my own rules…

At the GOOS Gaggle I heard David Harvey praise the upcoming SPA conference because of its’ great keynotes (and yes, they are going to be fantastic). But to me SPA is not a sit-back and relax conference. The main reason why I’m going are the hands-on sessions and simulations. This year we’ve got even more hands-on sessions than last year, so much so that we’ve got more than a complete software craftsmanship track. Whether you are just a programmer and like to program with your peers, or you fancy yourself a software martial artist sweating it out in the coding dojo with fellow code-okas, this should be a lot of fun and very effective learning and experimentation. The language track (to introduce and explore various programming languages) also has lots of hands on sessions. This year for instance on Scala and Clojure, and  if you are lazy Haskell is present like at SPA2009, but now from a more day-to-day development angle.

Of course, if you want to rest (or don’t program at all) there’s good discussions to be had in the design track (and even there several hands-on sessions) and simulation games in the People and Process track.

Take a look at the programme , I hope to meet you there.

Mastering Unit Testing Course in Antwerp, Belgium September 24 and 25

Wednesday, September 9th, 2009

We are partnering with local companies to provide our training curriculum in other countries. We started the Mastering Unit Testing course after we found many teams have started writing unit tests, but very few have experienced the benefits of hard-core test-driven development.

“You have some experience writing unit tests, but wonder how you could get more out of unit testing. Register for the Mastering Unit Testing training to experience how test driven development can make development faster and more enjoyable. You’ll learn how working test-first lets you create better designed code, and understand why unit testing techniques that are ‘simple’ in theory can be difficult to practice. Past participants have experienced less defects in production code, as well as higher velocity, which leads to happier clients and more fun in your job!”

See the Mastering Unit Testing page on the iLean site for registration and details. The first course is scheduled for September 24 and 25. After that we’ve also got our Mastering legacy code, November 16 and 17, also in Antwerp.

Televox

Televox by d.billy

photo found through Photo Suggest

Your need for speed, sponsored by TDD and pairing

Tuesday, September 1st, 2009

The causal loop diagrams in this post have been heavily inspired by GeePawHill (also known as American Mike Hill) ‘s  How TDD and Pairing increase production. These diagrams were meant to follow mikes’ story. After they were done, another order presented itself. I recommend you read Mike’s post for some background and an interesting comment thread after you’ve seen the diagrams. I’ll use Mike’s definition of internal quality for this post, and refer to it mostly as ‘quality’.

Zed and Carry are programming an online catalogue for Amazing Widgets.  If they deliver new features for the catalogue faster, their company will make more money, because they can outsmart the competition and draw more paying users to their site. Sure, they have a customer, but he’s on holiday at the moment; he might return for another post ;) . Right now Zed and Carry are chugging through a long list of feature requests the customer left them, so they would not be bored while he was away…

So far they have not made much progress. Carry and Zed are wondering why they are going so slow. Carry read this post by GeePawHill saying “the biggest single determinant in today’s production is the quality of yesterday’s production.”

yesterdays_quality

yesterdays quality is the single biggest determinant of todays' quality

That sounds mysterious. Carry wonders how to write good code today, if everything has already been determined yesterday… It seems kind of hopeless! She was taught in school that the number of lines of code a programmer wrote in a day was a measure of productivity. Now she was wading through file after file, looking for the one line she needed to change. If only the code were smaller, the variable names were not all spelled like I, J and cmd and that whenever she was debugging she would not need to remember over 15 classes at once… All of the decisions they took in a hurry to get the new features in production before the customer went on holiday were now haunting them like the ghost of christmas past…

What determines yesterdays' quality: bad variable names, many dependencies, flawed design decisions and the number of lines of code

What determines yesterdays' quality: bad variable names, many dependencies, flawed design decisions and the number of lines of code

They stare at each other for a moment. Zed says “what if today’s internal quality was better?”. What would our code like, and what would it mean for us? Carry dreams away. ” If today’s code were better,  we would have less dependencies and much less code, and everything was so clearly named that I knew where to start working immediately. But I don’t know where to start refactoring! It’s all tangled together, I don’t understand what half the code is doing, it just sounds like a dream. And I don’t have time to work on that dream, because we have to hurry! The customer will return from holiday soon, we need to show some progress. Hmm, Zed goes. I think if we stared naming the variables better in the bit we’re working on now, we could see some improvements soon, it would make our work for this afternoon and tomorrow already a bit easier. With the refactoring tools we have it’s not dangerous at all, and we can always get the previous revision from version control if necessary. We could spend part of our increased speed tomorrow on some other improvement.

internal_quality_speed

If internal quality goes up, speed will increase. This can free up time to improve (but you have to make a conscious choice, hence the decision square). With time available for improvement, internal quality can improve, given you choose relevant improvements and have agreed what improved internal quality means. The 'condensator' symbol indicates there may be a delay. Try to choose improvements that improve internal quality quickly - that helps motivate further improvements. If this works you will get a snowball effect: you will go faster and faster, while delivering ever better quality software.

“That would be great”, says Carry “I’d really like that. But I’m scared to break features that are already working. With all these dependencies I don’t know what might fall over when I refactor. Remember the trouble we had with the helpdesk after our last release? Hmmm… Would you be willing to help me clean up the design in the part I’m working on?”

“Sure”, says Zed, “Why not, I can’t go any slower than I am now, and maybe together we can come up with a way to add some tests as well. I’ve been aching to write some of these microtests, I’ve done some exercises but I just can’t figure out where to start. I’ve heard that it can help you focus on the design as well, and the refactorings would be a lot safer – Come to think of it, I still don’t fully trust our refactoring tool, it seems a bit wonky at times; some refactoring up front would make it easier to add tests, so having your help to refactor would be great, it would be a lot safer that way”.

Test Driven Development, Pairing and Refactoring improve today's quality, so that we can go faster later today or tomorrow. Pairing supports refactoring, Refactoring supports Test Driven Development and vice versa. This leads, amongst other things, to Better Variable Names, Less Dependencies and code that expresses its intent more clearly

Test Driven Development, Pair Programminging and Refactoring improve today's quality, so that we can go faster later today or tomorrow. Pairing supports refactoring, Refactoring supports Test Driven Development and vice versa. This leads, amongst other things, to Better Variable Names, Less Dependencies and code that expresses its intent more clearly. Pairing and TDD also help prevent and eliminate defects, but that is a subject for another story.

Carry and Zed sat together, changed some names, did a few commits and eventually found a place where they could start writing a test. To their surprise, adding a few more tests was easy, and they were surprised at how little time it took to actually do these things. Carry had some time left at the end of the afternoon to continue reading GeePawHill’s post:

“If you want to increase the productivity of your team, then do these three things:

  1. write a microtest that fails before you change any code;
  2. adopt a “no-pair no-keep” agreement;
  3. establish a shared understanding of internal quality.”

Zed was happy they did this as well. Tomorrow, they could go even faster! He was almost thinking of working alone again tomorrow and skipping the tests, but thought again. He wanted to go at least as fast the day after tomorrow…

Tomorrow, today will be yesterday. Any improvement we can make today, however small, will help us go faster tomorrow.

Tomorrow, today will be yesterday. Any improvement we can make today, however small, will help us go faster tomorrow.

After thought

For a long time I’ve been planning to illustrate the value of test driven development through diagrams of effect here.  We’ve been using this to ‘sell’ the benefits of TDD to course participants and folks we mentor for a few years now, and it’s been remarkably effective. The essence is simple, as Marc Evers put it:

“If we work on the same code as you today, and we write tests and pair when you don’t, We’ll be drinking beer in the bar, while you’re still inside fixing bugs”

Well, that’s the benefit for programmers. I haven’t met product managers or customers who dislike getting better quality software sooner either :)

Undoubtedly, the speed with which this post was written (as well as the lack of pairing and TDD that goes with writing prose in the flow) merit improvements. Your suggestions and comments are most welcome.

You don’t know what you’ve got until you get it

Tuesday, August 25th, 2009

While I was on holiday, Marc started creating a new product from scratch. He’d been walking around with a problem he wanted to solve and couldn’t find anything that he liked. Marc also wanted to try out the Scala programming language, to see if it would be worth using, and thought nothing helps you focus more than building an actual product.

I didn’t get it. But I gave Marc a hand anyway, because we had previously decided that QWAN values:

supporting someone who has a passion over discussing the business case at length

Variazione in scala di grigiVariazione in scala di grigi by Eric Perrone

Why didn’t I get it?

(more…)

Photo Suggest – photos to go with your blog entry or slide

Thursday, June 25th, 2009

We proudly announce Photo Suggest, a web application that helps you find photos with liberal licenses to go with your blog entry or slide Check it out.

Dancing Peacock

Dancing Peacock by Hamed Saber

Here’s why:

(more…)

Haskell dojo at eXtreme Tuesday Club London

Sunday, April 26th, 2009

Mike Hill and me will be co-hosting a haskell coding dojo at the eXtreme Tuesday Club in London this tuesday.  Prior experience of Haskell not required, just bring your intention to have some fun :) A dojo is a great way of learning together, and I see we have at least one participant with quite a bit of haskell experience; so register to join the fun…

Keeping up is not enough

Monday, February 9th, 2009

Johannes Link is starting something that I would like to support and promote:

a “ development project for bored consultants”

contact Johannes if you’d like to spend (at least) one day per month in a project with other agile consultants and you are willing to give this project priority on that day.

(more…)