Here’s what my test code looks like (which lives in its own unique test package):

public class MyTest extends PrivateTestCase

{

….

public void testPrivateMethodCall() throws Exception
{
    // where Coffee is a private class within the package
    Object privateClass = newInstance(”com.cognifide.cafe.Coffee”, NOARGS);

 

    // AND drink is a private method on Coffee
    invoke(privateClass, “drink”, NOARGS);
}

}

Unfortunately, it is a bit quirky, and you have to create a boiler plate TestProxy class in the package for all classes that you want to test in this way.  But I’ve taken a look at the source and you can get round this by tinkering with junitx.framwork.TestProxyFactory.createProxyFor().  I just haven’t got round to doing it.  If you do, please drop me a line and send me your patch…

Anyway, I’ve got 60 days left to do some damage…rock on IntelliJ.

Clearly, I have been spending a lot of time walking the walk, and enjoyed these 3 days listening to similar minded people talk the talk.  I had a favourite speaker at the conference, Neal Ford, that I had to actually explain to him at the end that I was not really stalking him.  In all, I attended all but one of his many talks, and his keynote was real thought provoker.

Anyway, I have a lot of things to think over that I will drip feed some of my thoughts in this blog over the next couple of weeks.  The NFJS guys also gave away 10 books, 5 IntelliJ licenses and a Nintendo Wii Games Console, in that order, to those that attended the conference by picking delegate names out of a bag.  Guess whose name came out first, Miro Walker, our (Cognifide’s) CEO.  Unfortunately, because he couldn’t make it that day, he didn’t get the prize which would have been first choice of the 10 available books.  Shame! 

Now, guess whose name came out last and is now the proud owner of a spanking new Nintendo Wii Games Console…:-)  Yours truly!  Thanks NFJS.  Much appreciated.

Damn, I’d forgotten just how much I love conferences….

I was in my hotel room last night and had 30 minutes to spare.  So I googled ‘ruby’ and was not surprised to see that main ruby site http://www.ruby-lang.org is ranked above the actual gemstone itself (It’s like having to google ‘java island’ to get to the island in Idonesia – wierd). 

Anyway, moving on, I read the twenty minute tutorial, which is really 10 minutes if you know another language, and was impressed.  With twenty minutes left before the witching hour (dinner with a beer), I downloaded and installed ruby and wrote my first application, without a main function.  Very nice! 

I want more Ruby.  If reads like prose compared to a lot of other languages.  Let’s see how the rest of the week goes…

The article about a company called Remedy Entertainment from Finland that is the maker of Max Payne (and the forthcoming Alan Wake).  Remedy are embracing the change in the gaming industry.  Remey needed to adapt to remain competitive.  You see Remedy understands that it needs to retain a small, highly experienced team that focuses upon assembling games.  This is what they know how do well.  This is their core knowledge.  Their primary business asset.  The bits around the edge pertaining to games engines and the like are essential, but secondary.  So Remedy decided to partner with companies that can deliver these secondary assets in support of its core business skills.

Now, the interesting part for me is that a company like Remedy, if it is to remain successful needs partners that it views as an extension of itself.  Ones with high quality standards, best practices, evolving skill sets and a no nonsense attitude to software development.  In short, like minded companies.    To quote Remedy, they need partners in which:

• “Every team member is focused on shipping a masterpiece.”
• “No politics, no egos, no empire building, no nonsense.”

I bet that Remedy have to look long and hard to find partners like this.  It is one of the primary reasons that Cognifide came to be and continues to inspect and adapt its internal processes to meet customer requirements such at these.  I’m not saying its easy.  It’s certainly challenging but most definitely a worth while pursuit.  It’s great to see customers are looking for quality and putting in the necessary time to ensure that they get it.

Then I stumbled across this you tube write up on what is faceback.  Let me know what you think?

This is something you should show your new scrum teams…

This got me thinking.  I’ve been fortunate enough to have been a member of a couple of high performing teams over my last two decades of software development.  However, the best performing team I have been a member of is my football team between the ages 11 and 16.  Looking back at this team now, I can see clearly why I have never been able to reach the same level of performance within a software development team.

Friends, not associates.  As a football team we were first and foremost friends.  More than that, we were something of a clique.  We saw each other before school in the playground, at school during lessons, break and lunch, and after school at clubs.  We shared girlfriends.  We loved and hated the same TV programs (Miami Vice, Starsky and Hutch, V).  We loved our clothes (Farahs, Adidas, La Coste).  We were known to each our parents for better and for worse.  We were always together like some kind of extended family.  This was translated onto the pitch, where one referee was quoted as saying, “they never stop talking, shouting, arguing or laughing, they gave me a headache”.  One referee actually told us to shut up and play football!  However, as a comprehensive (read as a deprived) school back then, we lost one game. 

Personal Safety.  Anyone in the team, could say anything to anyone without comeback.  You could speak your mind both on and off the pitch.  The number of software projects that I’ve been on where you just couldn’t do this still scares me.  It is a clear route to failure.

Team Cohesion.  A team needs time to gel.  It needs to find its own rhythm.  A three month project where a team is formed and broken up does not give enough time for you to get to know each others little quirks.  You need a few of these projects to get to know how Bob likes to work?  What offends Bob?  What does Bob like to do?  Is he a morning person?  And so on.  Although I don’t think all team members need to friends, I think that if they are it helps.  My best software achievements to date have been in teams where I have considered the other members to be my friends.

Practice and Feedback.  The players and reserves gave us a total team size of 14 kids.  Every Monday morning we’d number off.  Numbering off is where the team would collectively agree who was the best player, second best, third best, and so on, right down to poor old number 14.  This was quite important because when we picked two teams that would play against each other, the best and second best player were never allowed on the same team.  So two random people would pick and what you’d get were two evenly matched teams everytime we wanted to play a game of football.  We would play (i.e. practice) and criticize (i.e. feedback) each other continually.  The better you played, the more likely next week you’d go up a rank.  Ranking was everything.  It leaked into our social lives as well because we would queue up at clubs, at dinner time, based upon our rank.  Now I’m not saying explicit ranking would be good thing within a commercial software development team setting, but implicitly this does happen.  I’d bet my last dollar that you have a fair idea of how your technical abilities compares with your peers.  You just don’t voice it.  However, back in my youth it was an incredible driving force to climb the football ranking ladder by knowing exactly how your team mates perceived you.

Leadership.  The best team member is not necessarily the leader.  I was captain of the football team for 4  of the 5 years.  My highest ever rank was 3.  But I was nominated captain because my team was typically the winning team.  I don’t like to lose, so I always stepped up the game (or took someone out who was stepping up their game ). 

So what has this got to do with software development teams.  Well, I think honest communication, whether its feedback, advice or criticism, within a team is essential.  Moreover, it’s important that the giver and receiver of understand each other.   However, this is rarely the case.  When you have this I don’t think there are many problems you can’t overcome.  But without it, even the simplest things become difficult.

To date, I think the agile approach is the best tool we have for creating great teams that can deliver better software faster.  However, a lot of the challenges not technical ones, but people-oriented ones. 

Sigh, why don’t you ever realise you’re a part of a dream team until you’ve left it….