Invisible Audience

in Knetlik I presented over Skype, without seeing the audience.

It was weird. But it didn’t start there. The preparation of the presentation took that into account as well.

If you’re my audience, and you don’t see me, and all you’ve got to look at is a screen (and of course listen to my captivating voice). if that’s you I need to work hard to keep you engaged.

First of all, I put a picture of myself at the beginning, so people can at least know how their voodoo doll should look like.

That meant in my presentation I should make more full, readable text. Also, I had to flip slides more quickly. And I talked quickly (which apart from my natural tendency, there was also the time limit that loomed over).

Of course, without looking at the audience, I could not tell if they are interested, angry, or throwing things at the big screen.

Weird. But I’ve learned a couple of things. Like for example, this thing is not going away. Webinars, webcasts, broadcasts – all these need to be interesting, engaging, funny, aggravating. Otherwise, you’ll lose the audience.

And then you’re back in square one, looking at an empty room.

Refactoring for the People

I try not to miss them, but the last .Net user group was about refactoring. I’ve been refactoring before I wrote unit tests, which was very courageous (and stupid). 

This post is a response to Gadi Meir’s post (in Hebrew) in which he states that refactoring policy should be defined by the CTO or equivalent. It’s  not  a do or don’t policy – rather the style, which should be derived from the organization’s coding guidelines.

Having been in charge of imagewriting and checking these guidelines in the past I can tell you that in my case, they weren’t effective. I know organizations that live by it, entering tools like FxCop into their build system, and automate the guidelines check.

Take it one step further, and you get refactoring guidelines. It can work out, or it can crash and burn.

The most effective tool in development is peer code review. This is where one developer explains, persuades and communicates his work to another person. Refactoring is part of that translation, where you sometimes negotiate with your peer about what the code should look like.

And this is where I go against the guidelines. Having been there, the guidelines were there to keep things simple and readable (at least I hope). But that should never trump the ability of two or more developers to agree about what the code should look like. Because at that point both developers agree that the code reflects the intent, it reads well, and when a new developer comes, she’ll be able to go into the code with no problem. And they use refactoring to get there.

Individuals and interactions over processes and tools. (from the Agile Manifesto). Refactoring for everyone!

Effective Replication

Replication. It’s not just an Stargate SG1 term.

A few weeks ago, I posted on the Typemock blog about introduction to isolation. It has been a while since I’ve written a technical blog. I’m exploring other media (the “Typemock TV” webcast, for one) these days.

The thing is, I didn’t even plan on writing this post. It just so happened, that I was offered to do a guest post on Eric Nelson’s blog about an introduction to mocking.

Apart from fighting with discrepancies between Blogger and Live Writer about how to interpret spaces in code (which, by the way was a fight I lost) it took me about a minute to make the post the second time – since I’ve already had everything written.

The result is that this post appeared in two blogs, for different audiences, helping me spread the message of unit testing with little extra effort.

Replication is not about copy-pasting content. Sure, it can be. But what I’m going to replicate next is getting the next guest post. The effectiveness comes from replicating actions, not content. 

What’s it like on the other side?

If this Dilbert strip causes me to move uncomfortably in my chair, instead of making me laugh, I’ve really crossed the border to marketingland…

Webcast Story – The Story Continues…

After my webcast story post, a professional webcasting coach contacted me and asked if he can talk about the experience. We had a insightful talk yesterday.

What I described, and what we do in the webcast, and it’s also true for the early webinars -  was like agile development. Now in reflection, that’s what we did, although I did not notice that at the time.

We experimented, assessed what we did, and then tried to improve, usually on a weekly basis. It’s not that we’ve always succeeded (I can count a few disasters on the way) but we kept doing the thinking. In fact, the decision to cancel the webinars and explore a new path, was part of that cycle. (The original intent of the webinars was to increase our audience, and engage them. What happened is that we got a small dedicated team of people who got in every week. That was cool, but not what we wanted, so we canned them).

It’s funny that I needed someone to tell me that, but sometimes you need someone to show you the way.

During the talk I've gone back and revisited what we did, what we measured, what was interesting. It was interesting to do a postmortem for the entire experience (both webinars and webcasts) – I could actually see similarities between the processes that I didn’t before. For example, seeing that technical stuff works and attracts, but to a limit.

The key idea here is that: Our audience gives us his time. If we want them to stay, we need to make it worth it. Information they can get anywhere. We need to give them something special.

And once I figure what this something is, I’ll tell you.

What are unit tests like?

Recently, I’ve had a twitter conversation with Kent Beck. He mentioned that he noticed tests running slower – jumping from 1 to 6 seconds. I asked if he noticed an impact, and he said he definitely started running tests less.

First of all, I take off my hat – I’m not sure I would notice a jump like that. But then I usually use MSTest, which its startup time already consumes this period.

The immediate impact is interesting – if that’s what caused Kent to run the tests less, imagine what happens when you have a big suite that runs for minutes.

At that point, Kent modified the code in order to reduce the length of the tests. He decoupled a dependency to make the tests run quicker.

Now I’m in the business of unit testing, which makes tests run much faster – isolated, in memory, etc. But this was, in a long while since I thought about changing code for test performance.

The accumulating savings in time are big. All the seconds you collect to add up, plus you pay less in context switch and flow breakage. The cost is the modifications of the production code for the tests to run faster. It’s a cost you pay now.

Much like unit tests, there’s no immediate visible ROI – you don’t measure the gain in velocity due to tests running quicker. Yet you feel certain that this is a worthy investment.

So optimization for unit test performance is like unit tests.


Is Design for Testability Language Dependent?

As part of my design for testability talk, I talked about how tools and languages impact testability. Then I came about Brett Schuchert’s post about TDD and if it’s language neutral.

The post concentrates on how different TDD looks like in different languages. Moreover, how it is interpreted, based on the language of choice. And Brett gives example of where solutions would look similar. Or not.

One of the points in my talk is that testability is also tool and language-dependent. Tool-side? Isolator, of course. No matter how you design your code, it’s still testable. On the language side, dynamic languages are more test-ready. Just replace the behavior of one method with another, like in Ruby, for example. No need for fake objects, you get testability as part of the core language.

When you write your application, choose carefully. Examine both languages and tools, as part of your research. Then remember: testability is not a goal, good readable design is. Make that the crux of your decision.

Design For Testability Presentation Slides

I think I put more effort to this presentation because I had only 10 minutes. And I needed to relay the message in that time.

Apparently I did. But my point was not that DFT sucks. The intended result is good design, and that’s also possible without DFT. Testability is not a goal. It’s a solved problem – by tools (like Isolator) or languages (like Ruby). Readability trumps everything – it’s the one thing that will get your app sailing through the next 10 years (in average).

If you select tools that  make your code in a way you’re not happy with – it’s your fault. Change tools. If you succumb to your tools you’re wasting your boss/customer’s money.

Knetlik – Presenting on Design for Testability

If you’re in Prague tomorrow, Feb-13-2010, a conference called Knetlik takes place. The cool and interesting thing about it – it’s a series of short presentations. All of them are about 10 minutes long + 5 minutes for Q&A. Then it’s on to the next one.

Andrew Kazyrevich, asked me if I would like to present. And so tomorrow, at 13:20 CET, I’m going live (on Skype). I’ll be talking about the good, bad and ugly of designing for testability.

I’ll post my slides afterwards, and if there’s going to be a recording, I’ll post that too, of course. But if you’re there, join in. There’s a lot of cool topics there.

Social media works. Now what?

File under the “can’t believe it works” section.

Social media was something I knew about and used for a while. I’ve got my twitter, which is active and I use as a tool for my work.

I’ve got a Facebook account which is not too active (but it’s connected to Twitter, so you might say it is).

I’ve got this blog, and the Typemock blog, which is a 1-to-N publishing mechanism.

And finally I’ve got LinkedIn which I usually use to search for people, by getting more people into my network.

My views about social media have changed drastically in the last few weeks, thanks to working with Tal, our new marketing director at Typemock. I now see social media as a very effective tool, not just a nice-to-have one.

And I know, I’m late to the party, I sound so 2005ish. But as skeptic, it’s results that impact my belief.

And the results are there (and Tal gets all the credit for that): Hundreds of people joined in less than two weeks our Facebook and Twitter campaigns, that got us connected to people who are in our target market.

So now I do believe it works. And I’ll need to find something new to be skeptic about. Don’t worry, won’t be long.

Webcast Story

Let’s see – how did we get here?

It was in October 2009. We were planning to go the SharePoint conference, and got a video camera. On the spur of the moment, Roy said: why don’t we do a webcast? And that’s how “This week in testing” came out to be. One shot recording, upload, voila.

And we did a couple more. Then more people joined. And I took a couple steps back, and done some editing (new toys, learned a lot, got tired). Some videos were short (about 10 mins), some longer -  30 or more.

And we looked at the numbers, people were not watching more than 3-4 minutes. We played with the format, content, setting and alcohol and we’re still continuing to do that.

It has now become a marketing project – recording, editing, preparing, throwing mics around. And with more people, we get more opinions on how this should be done.

Yesterday’s shooting left me with the thought of: “So when bands break over creative differences, that’s what it looks like”. We want it to be the coolest, most informative, entertaining, professional, subversive, addictive webcast ever. The thing is – we can’t have it all.

We’re going to continue doing this. it’s just that Alice in wonderland theme again: Which way to choose? It depends on where we want to get to .

Famous for Throwing Rocks at Famous People

Roy recently posted about “celebrities” in the development community.

Who are those celebrities? We consider many of them experts in their field – that’s why we read their blogs, follow them on twitter. Go to conferences to watch them talk. Take them to dinner :)

Scott Bellware is one of them. A loud one. And he spoke against celebrity-ism. By the way he’s not the first one. Many celebrities (even in Hollywood, believe it or not) call paparazzi to shoot them, then complain about their invasion of privacy. It’s mostly about noise. Buzz. And if you don’t get any, you make some.

I think that Roy’s point about celebrities being a driving force is a bit off the mark. Celebrities are a “force of nature” of an open community. They are the famous, the noisy, the “cool kids”. We change the definition depending on the environment, but, it’s the same thing. It’s not good or bad. It simply is. (Insert any Zen cliché here).

The existence of celebrities is not a driving force by itself. Do you want to be one of the cool kids? Do whatever it takes – work hard to become one, hang around with them, create a stronger opposing gang, or talk loudly about what our society is coming too.

And maybe someday, you’ll become one. The question is: what do you want to be famous for?

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