The things I knew then…

In the discussions we had in alt.net last week, specifically the one on teaching and learning, Ohad talked about having the need to consult with other architects. (He went on to found the IASA Israeli chapter). And then he asked – if you’re one of the guys who want to learn, yet you don’t have people around you to pass along ideas, or even rubber ducks – what do you do?

Obviously, alt.net is not the place to ask this – because people come there to learn, consult, kick around ideas and challenge others. I said, that in the past (pre Typemock days) I used to be in that position as well. And what did I do?

For one, for some ideas I had Gadi, who was consulting for my company at the time. And in his words (loosely translated): “I showed Gil all the bumps in the road, and let him pick the ones he wants to run to head first.” (and yes, I did).

But I had to also admit…

In those days, being the smartest, expert, and yes, even the prettiest – I didn’t feel I needed to consult. Sure there were problems I encountered, but hey –there was Google, and books, and I KNEW there was nothing that I couldn’t do. So consulting (which involved dealing with those pesky humans) was something completely optional.

So what can I tell you today, with the mountain of experience I’ve collected? If you’re reading this, and you’re the top smartest techiest guy in your company and you feel you don’t need anybody else, here’s a newsflash – you do. Find a group, or just beer buddies you can talk about everyday stuff. This is the real power that makes  problems go away.

Alt.Net Israel 2010

Yesterday was Alt.Net Israel 3rd meeting. I missed the pre-meeting on Thursday, and came in only for the discussions on Friday.

There were a couple of differences from earlier Alt.Net conferences. The first, is that topics were grouped together to mini-“tracks”. So the time allocated was for a couple of topics (and sometimes we even stuck to the plan…). Another thing is that this time (at least in the sessions I attended) it was more of a roundtable discussions, rather than presentations (the kind I did on mocking, the last two times). From Typemock there were Dror, Doron and myself. Oh and the food, since we were sponsoring.

What didn’t change is what this conference begins to emerge as: a group of very smart people, wanting to learn and share their experiences. I think I enjoyed it better than last year, because of the discussions. I’m mentioning people who gave me better insight during the talks, but obviously they were not the only one.

First session I went to was called Learning and Teaching. It centered about the responsibility of training. Should the developer train himself, or is it the organization's job? What happens when you want to push someone towards new areas, but she wants to stay where she is? How come people don’t go to user groups, even if they are at the same offices, on office time? Very good discussions, which left some questions still unanswered (Gadi and Ohad).

The second was about ‘Agile’, where we gave examples on how we perceive and practice agile practices. It was also about how to build teams (Oren), and grow developers. Questions about how to sell agile – more to developers than managers. And we concluded on what’s happening between Ken Schwaber and Microsoft, the great Scrum divide and certifications, and what’s the meaning to developers (Lior).

Final session was on Design patterns, but again it was less on the GOF patterns, rather on when to use, why do you use them, other patterns in code and what you need in order to refactor to patterns. Finally, a brief overviews on SOLID principles (Vlad).

I’m glad I picked these sessions, as they were more on the communication and management side, which I relate more to this days. It was great opportunity to learn and connect. I can also see how I’ve grown over the years.

I hope next time’s going to be amazing as this one was. I think I’ll have some more on the topics soon.

Laziness can get you so far

Is man destined to choose the quick and dirty road, throwing away long term benefits?

While the answer is probably yes (we’re all lazy like that), two dissimilar events in the last week made me think – maybe that’s not the right question. Maybe we need to check how long term are we talking about.

I was in an army practice last week for my unit. Because it’s top secret (not really, but just in case someone reads this) the task was to report on 50 occurrences of X. When they were at 46, the commander in the practice decided, without permission, to complete the task by reporting 4 Ys. Without going into what are X and Y, and what the cost was of reporting them (high), the point is – the commander went after the number, rather than following the correct parts of the task.

It was fully acceptable to leave it at 46, saying “we can’t do 4 more X in the time we got left”. Hitting the number 50 was more important to the commander than doing the task correctly, because sadly that’s the historic way of looking at results in the unit (thank god, we’re improving).

Then I read Lessons from the Classroom. In his description, students resorted back to not doing unit testing, because they felt it wasn’t worth it – investing in unit testing for something that ends in 6 months, when there’s no real ROI.

In both cases, people get directed (either by other people or their  own understanding) that the shortest route is more beneficial.

And since I know a bit on both areas I can tell you this. We must communicate what’s important. We can’t rely on the perception of success when we’re motivating change. And we need to be persistent. In the final result of the practice, the commander didn’t get his 4 Ys counted. We needed to send the clear message of what’s important.

And with unit testing, it’s the same. As we’re introducing changes into the way our organization works, we need to be persistent on where we’re going. The ROI of unit tests is not so visible, but it is big long term, and we need to over communicate that. And then we improve.

As for the opening question. I’m not that pessimistic. But yeah, we’re mostly lazy.

What Valve did

A week ago, Valve announced Portal 2. If you didn’t play the first Portal, well, I’m really sorry. Go play it, I’ll wait. It’s not a long game.Portal 2 is the sequel to 2007's Portal, which won 70 industry awards including numerous Game of the Year awards.

Done? Good.

The announcement came after a short marketing ploy. Valve owns Steam, a software delivery system (it also does licenses and lifetime management. I wonder if we can register Isolator as a game for better licensing management. But I digress). So they used Steam to deploy an update – it changed the ending of the first game, plus adding an achievement. And it “installed” clues. To what? To what’s coming.

Now, why is that cool?

1. Almost never done before.

2. It comes from Valve only to people who have Portal installed. As Seinfeld asks: “who are these people?”. These are hardcore fans, who have a 3 year old game installed on their machine. Or people who just purchased Portal recently. Two audiences that will probably benefit the most from the news.

3. Short campaign. 2 days after the download, the announcement came. In the age of the Internets, with the Valve community (and specifically gamer community online) people already tried and guess what the clues mean in less than 24 hours.

4. Everything Valve does is cool.

Valve has not blew its marketing budget on this. It’s still going to use all the regular channels to advertize the upcoming game. But in less than a week (and I guess some weeks of preparation) they created the buzz in the right place, for the right audience. And kept, nay increased, their coolness.

Let’s turn that into the “real” world. In the real world, us developers stay away from “market-speak”. We’re cynics (I know I am), we don’t believe what companies tell us. When we do, it’s only after we tried products or services ourselves.

But Valve did a few things differently, and as a casual observer, I’m writing a post about it, increasing the buzz. I’m now part of the Valve marketing effort, just because I care. We do this for things we really like. We tell other people and spread the word. Social media works.

And I can’t wait for Portal 2.

One Job, Two Companies

In my interview with Uncle Bob, he mentioned a special model of apprenticeship. If people are to grow within a company in skills and experience, they need time. But if people change jobs every 2 years in average, how does that going to happen?

What if you could switch jobs, on the job? Two companies have an agreement to switch workers. So after you’ve grown in one company, you’d go work in the other.

Think about it. You go to work in one company, work there for a year and then go back to work at another. Obviously, you get paid, all your terms still apply, but you get to switch environments, peers, mentors.

It’s pretty easy to understand what you can gain here. I can also understand why you wouldn’t want to do that, if given the chance. People like their comfort zone. People don’t like changes. Why should they switch, for the sake of growing?

And there’s the rub. If you want to grow, you need to jump over steps, which may be uncomfortable, but necessary. If you’ve got a chance like that with a company that stands behinds such a process, wouldn’t you jump on this opportunity?

It may not be for everyone. But if you want to invest in yourself, this could be the place for you.

The Inefficiency of TDD

.. and why I’m willing to live with it.

Brian Harry has started a series of posts on how he writes code. By the way, he is responsible to manufacture a small software package called Microsoft TFS, so I usually listen to what he has to say,

The first posts refer to both his iterative process of writing and TDD. One if the points he raises regarding TDD, is that although it is a good way to focus, and define APIs for example, the nature of new code being less robust than the final code, and that makes it less effective.

He has a point: TDD helps you focus, write the correct code you think at the time. But because TDD starts at the unit level, you run the risk that the code will change when you know better, and then you’ll need to modify the tests as well.

We developers haven’t figured a way (yet) to compensate for tests getting broken for lack of understanding, not seeing the big picture and other changes in software. Some of the tests are destined to be changed. This is one of the objections we hear sometimes – the extra extra work. Not only do we need to add work by writing tests, we also add work rewriting them.

But such is the nature of the beast. You can tweak the process as Brian does, but only to some effect. I’m willing to pay that price of added work in order to gain readability and quality. Not to mention the fact that I need to think before I write.

The accumulated benefits outweigh the re-work.

What’s your story?

Kent Beck is running an interesting experiment. He’s asking start ups to step up and take a chance, put their creation stories on their site, and to test it against their usual homepage.

The idea behind this is that a compelling story makes visitors into customers. People make the tie between the product or service, and the story behind it, and once they do, they are more likely to buy.

Stories do that to us. For centuries we had storytellers to convey ideas, religion, persuade and sell. Us developers, we like the data, and lots of it. But that’s not what we remember over time. That’s why I’m the T Shirt guy.

I like to tell my tank story (and I’m going to do it here one day) at the beginning of a presentation.  A story helps relate to the presenter, become more susceptible to listen to him. He becomes less remote, approachable. And that helps him to pass his message (which is what he’s there to do).

What is your favorite story to tell? Has it helped you convey a message?

Sometimes it is better to shut up

Last week we got (again) sensitive about things that were said in Twitterland. I’m not going to relive this, but there were two camps in the office: the one that said we need to respond, and the other said let it slide.

Since I was on the second party, you’ll understand why I’m not putting links or details here for future generations.

The thing with social media is that you can catch waves and ride them. It’s a risk since you can fall of the wave as well. But the question you need to ask yourself – is this a conversation I want to have? What do I gain, and what do I stand to lose? Remember there will be other conversations – is this the one you want to have?

In our case, (with reflection glasses on) we should have just shut up. When things fly through Twitter today, they are so transitional, and have a very short half-life. This kind of micro-storm has already gone, and by saying nothing, it would have disappeared even sooner, and we wouldn’t have paid the price.

What price? we spent discussions and re-discussing possible answers, and answers to our responses. It was a waste of time. And I’m not counting the heartache – because we were actually felt attacked and felt we couldn’t carry our point across. In hindsight, we could have saved ourselves time by not saying anything.

Of course there’s a chance you’re putting yourself outside the conversation. And you may discover that you should have entered before, and may have calmed things… but at the end – you really don’t know. It’s a gamble.

So to finish this off, in the immortal words of Kenny Rogers:

“You got to know when to hold ‘em, know when to fold ‘em,
Know when to walk away, and when to run.”

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