Monday, February 28, 2011


One of the sessions at ADC2011 that I understood (even though it was in German), was Bjorn Rochel’s talk on test organization. Bjorn told a story of the evolution of his experience writing tests, and how to organize them. For example, he started out with a test class, called CalculatorTests, and every method name ended with Test. Not so different than how I wrote tests initially.

As his story moved forward in time, he moved from per-class tests to BDD (behavior driven development) style tests. He compared the AAA (Arrange-Act-Assert) structure to the GWT (Given-When-Then) structure, that are similar in essence but still different. For example, as you add more tests, you’ll arrange them differently than the regular per-class tests.

I’ve tried to like BDD in the past, but could not see the main benefit over TDD. It still seems to me a more technical difference, rather than a new way to write code. Bjorn suggested something that has helped me accept the BDD style. Slightly.

In the GWT world, G,W, and T are separate methods. That means that “all you need” is to fill in the blanks. I agree that this kind of structure can help newbies with their first tests. In the AAA version of the same tests, all three parts basically resides inside the same method. Since I put more emphasis on test readability than anything else, my feeling is still I rather put everything under one method, rather than scroll up and down to see what the test does.

I’m still thinking about the how many tests are organized in a solution in BDD – they are centered around a feature, not per class. I’m inclined to put stuff (not just tests) where I think I’ll look for it in the future. For tests, using from the class code as a starting point, is the natural thing to do. Am I going back to my AAA comfort zone?

Time will tell. I’m planning to revisit BDD more and try to see where it can help more.

What about you? Which do you prefer and why?

Monday, February 21, 2011

A Magical Experience at the Munich Coding Dojo

ADC 2011 incidentally happened on a day when a meeting was scheduled for the Munich coding dojo meeting. Luckily, we were invited to the meeting by Ilker Cetinkaya.

The first thing you’ll notice in the picture, is that I may seem shorter than the other people there. I’m still suspecting Adi used a fish-eye camera. Regardless of what Germans eat and how much they grow, this was a very fun session. My expectations were not high coming in, but this is because I’ve imagined not being so active there, as I thought it was going to be a German discussion.

But once the exercise started, I realized that it’s not going to be like that. Ilker has selected the Paginator kata by Brett Schuchert. This is an object that manages the presentation of the page navigation like in your favorite Google page.

We divided to groups of 7-8 people, and coded it test-first. The original direction was to have a driver and a co-pilot and then every 7 minutes to change. But  very soon it became a driver with a bunch of co-pilots. We discussed where we wanted to go next, what the design is currently, what we’re keeping and what we’re changing.

For example, half way through the implementation, Thomas (in the middle of the picture) asked: Is this a browser Paginator or a desktop Paginator? If it is a browser one, that means we don’t need state carried between pages. So the concept of a “current page” we devised and kept in the object, was irrelevant, since a new Paginator will be created in every page. There’s a great lesson to be learned here: You don’t know everything as you start the design. You can aspire to, but you’ll find things later on, that will require to change the design. This is not bad news, this is just a fact. Accept it.

At the end, all teams presented what they came up with. As I presented, I saw that as we’ve replaced drivers and co-pilots, our naming convention changed, and also the way we wrote different tests changed. To keep those in line, we need to remember to review the tests by different people all the time. But the naming convention is just a tool. Regardless of using underscores as separator for every word or not, as long as it’s readable it’s ok.

I’ve also learned that night, that the German keyboard is not that fit for coding C#. Apart from the fact that the German guys who were using my computer couldn’t find the semicolons and braces, when I tried to use their keyboard, I found out that distances between keys require using Shift combinations, making it hard for programming to flow. I think I sense a connection between where languages were invented, and the keyboard setup used there.

Overall it was great fun with great people. And followed by Pizza and beer, we finished the evening going out and talked about the developer community, in Germany and in general.

PS, throughout the evening, I was trying to remember what Kata I led in the Israeli software craftsmanship group 2 months ago (beer effects probably). Thanks to the internets, which logs our life without us even knowing, I now know it was the code line counting kata.

Wednesday, February 16, 2011

Straight Out of ADC 2011

ADC2011 is over, and I had a mighty fun time.

Like I open my talks, I’d like to speak first on my favorite subject: me. I had two talks, one on unit testing SharePoint applications, and the other about tools for identifying issues in multithreaded apps (slides below). I can tell you that all those hours rehearsing in traffic (that’s a great way to spend your time on the road) worked out exceptionally well.

I was one of three speakers that gave their presentations in English. One was David Evans, who, unfortunately was scheduled head-to-head against my talk, so I missed it. Two more sessions by Gojko Adzic and David de Floronier I loved, especially the specification game. I’ll write more about this, but if you get a chance to see this presentation, which is part of a whole course, I really recommend it.

But my lack of knowledge in German didn’t make me miss other talks. There were brilliant talks by Björn Rochel and Thorsten Hans that I understood (most of the material). I can see that there’s a vibrant community interested in testing, TDD, BDD and agile and we had fun discussing different point of views. I can say though, that as a witness for a German-Developish panel discussion, I can now understand how Hebrew-Developish discussions sound to “normal” people.

Speaking of normal people, I want to thank Adi Beker, who came with me (and was the only girl in the room). She organized meetings with Typemock prospects and clients (where I tagged along) and managed to live through my sarcasm (not many people do).

The final piece of the puzzle was attending the Munich coding dojo – we were invited there by Ilker Centikaya, which ran the meeting expertly, and funnily. I managed to convince my German peers to speak English (at least while speaking to me) and that was indeed a great time, and once more a learning experience. More on this coming soon too.

I’ve met some more cool people – it felt like Alt.Net meetings sometimes (translation: good discussions). Germany has some great community leaders, like Ralf Westphal , Stefan Lieser and Albert Weinert,  that push developers forward, to know more, to improve and think about the craft. I’m really glad I’ve had a chance to meet everyone.

Of course, what we all really came here for: Beer. Plenty of it. Many types. In fact I’ve condensed into 3 days the amount of beer I’ve assimilated into my body in 2 weeks in Ireland. And pretzels.

Great fun all around.

Monday, February 7, 2011

5 Hints for the New Product Owner

demotivational-posters-tell-tale-hintsIt’s been a few weeks now, for my tenure as product manager at Typemock. Time for a review. What did I learn of becoming the product owner in an agile company?

  • Get yourself a good coach. That may be true for every profession, but especially for the newly initiated, it’s a blessing if you can get a good one. It made a world of a difference for me. A good coach not just teaches you. With the right questions, and actually making you answer them, you have to confront reality. And that’s a good position to be in.
  • Don’t miss out on the stand-ups. No brainer, right? That’s an agile to-do. But you may get sidetracked by work. It’s easy to think: “I can miss one meeting, nothing dangerous will happen.” And it’s true – nothing major happens, since when the developers need you, they’ll find you. However, the real value for me (and I’ve been known to miss a few meetings) these are the little things – what people are working on, what problems they have solved, and what’s bugging them. Apart from the fact that these tidbits of data are interesting, I get reminded that the dev team problems are our customers’ problems  - since they are developers as well!
  • Being agile is not just for developers. There are many facets in product management. One of the things I focused on initially is building roadmaps for the different products. This encompassed a year long vision of the different products. However, I’ve frequently changed my view – short term for specifying current feature, near term features, and long term vision. Sometimes, on the same day. And much like any agile practitioner, you need to modify your path as you go along – the business around you changes, the needs change, new requirement are re-prioritized from different clients (and I have different clients within the company). You need to have the agile mindset.
  • Work closely with the developers. Sure, you can do just the stand-ups and planning. Sometimes it even makes sense. But I found great value with working directly with the developers on estimation, throwing ideas around on different ways to solve a problem, and how to deal with support cases. The final decision is yours, but you get a better solution working together.
  • Connect the dots. This is the one I’m still feeling my way with. It may not be a regular part of the job for the product manager, but it is for me. It’s about connecting parts of the business together – development and product, obviously, but also sales and marketing. As a regular translator, I make sure that the support cases once completed, go back to sales for further treatment (great support leads to happy customers), and in general, that the communictaiton lines between the two departments are open. And of course, product and marketing need to talk the same language (sort of).

So far it’s been an awesome experience. Which, of course, I’ll write more about.

Is this you’re idea of a product owner? How is it different to what you know or imagined?

Thursday, February 3, 2011

Things That Work: Download to Paper

PaperManTime for another thing that works. I’ve written about my amazing ability to juggle things, and how I can mostly manage it. And whenever pressure rises, and tasks are in abundance, I begin thinking about stuff.

What else do I have to do? What am I missing? What do I need to do first when I get into the office? How do I make sure that once I do X I should follow Y with Z? What if I run out of letters?

If you (or I) are really stressed, it starts to impact your life. In my case it usually happens during the weekends, or early mornings. I start thinking about what I have to remember when I get into the office. What to prepare for whom, and how to manage that time. I fall into this trap all too often.

And all this thinking does wonders to my confidence. The more thinking I do, the less I’m sure about completing so many things. And then I follow my own advice: write everything down.

When I write what I have to do, things become clearer.The immediate benefit is to see the whole picture, and take decisions based on what’s in front of me. But the amazing thing is what happens mentally. I feel relieved of the mental overload.

I’m not sure how to convey this feeling in writing, but it is an actual relief. Once the tasks are on paper, real or virtual,  I don’t think about stuff as I follow my task list, I can focus on my current task, rather then do the mental juggling I usually do.

And having focus, I’m getting productive. And I get the satisfaction I’m working on the right thing, because I’ve put a wee bit of thought about what I need to do first.

The secret of my success. Mostly. One of them. When it works.

What’s yours?

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More