Do programmers dream in Byte Code?

This is Boss's blog , by day I am the Managing Director of Black Marble , by night I am an MVP for BizTalk and spend my life evangalising development to all.

Enterprise Library now with added Silverlight goodness

A series of updates are available for Enterprise Library and Unity and a few other bits of general interest

There is an update for the Enterprise Library 5.0 which is only required if you are using the Silverlight Integration Pack and need WCF RIA Services Integration or configuration tool support. get it here

However the most interesting development is a version of the Enterprise Library for Silverlight developers get it here it contains Caching Application Block, Exception Handling Application Block, Logging Application Block, Policy Injection Application Block, Validation Application Block, and Unity Application Block allowing you to develop best practice effectively.

Just in case you don't have the Enterprise library you can get it here

Microsoft Unity 2.1 is a dependency injection container. this is a minor update on Unity get it here , I also recommend you visit the Patterns and Practices page for Unity here

There is also a port of Unity 2.1 for Silverlight here

if you need to learn how to use these great libraries there is of course a Hands On Labs (HOL) for Enterprise Library 5.0 here

b

July update

I looked back and realised I had missed a few updates to post ( I blame Microsoft for bringing out lots of great things all at once Winking smile)

Light switch Beta 2 is out get it here, the site now suggests that a July 26th launch date is on the cards

StyleCop 4.5 has now been released get it here , if you haven’t tried StyleCop, its main aim is to help deliver standards of code style and standards across an organisation, but it is in fact a perfect pair to FxCop (see the Windows 7.1 .net 4.0 SDK) as FxCop analyses binaries , StyleCop analyses source code.

if you haven't already scoot over to Richards blog for updates from the ALM Rangers on some cool TFS work

b.

SDL Verification Tool

Everybody knows I like a verification tool as I think they are a solid way to enable a solid basis for quality, the argument against is that they do not get every case and so the argument goes we should settle for 20% MK1 human eyeball standards. I am a firm believer in both and so I was made up when Microsoft released the BinScope Binary Analyzer which analyzes binaries to check that they are in compliance with Microsoft’s Security Development Lifecycle (SDL) requirements and recommendations.

get it here

b.

Top Architects , Top Conference , Top Speakers

The 4th annual Architect Insight Conference has just been announced and this year I am happy that Black Marble is helping make it happen.

I will be presenting on Microsoft's Vision of modelling using “M” , I think M has a huge future in architecture and while it is only available in it base level , it is important to understand the potential.

I look forward to seeing everyone down in London.

b.

Microsoft Architect Conference
May 8th, Microsoft Offices Cardinal Place, London

www.microsoft.com/uk/aic2009

More Bad Apples

Over the last week I have received many comments on my recent post about bad apples, it seems to have resonated with a lot of people in the industry ( many of whom already read the great coding horror blog ). The two common questions have been, i) how do you spot it? , ii) what do you do?

The first is easier than the last, in general people will go dark and that becomes noticeable in communication skills, lack of documentation and general mood of self-despair. the less common variant is the supreme antagonist where the person will constantly pick fights which ironically they loose as their arguments are borne out of frustration with themselves not reality.

The second ( what to do ) is the hard one, I would hope that in most cases a sit down with the individual will sort out most problems. In fact most problems between people occur due to lack of communication, obviously there are politics and ego’s to content with

b.

Bad Apples

One of the interesting pieces of work we get involved in are rescue projects. Rescue projects can be thought of projects that aren’t delivering or won’t deliver either to timescales, feature requirements or quality.

In a rescue project there are many areas that normally need addressing: Project Management, Documentation, Process and Quality. The one common theme in rescue projects is people; when we are brought in to help on a project people start to worry about losing their jobs, but more often than not are un-accepting of the situation they are in.

The reasons for projects failing are numerous but people are the main cause, Jim McCarthy in his 1995 book Dynamics of Software Development (ISBN 1-55615-823-8) discussed flipping the bozo bit where people fundamentally just lose the plot and need to be refocused.

A recent post on the problems of negative focused staff (Rotten Apples) by Jeff Atwood (Coding Horror) has sparked some thoughts, rather than copy sections out I urge you to read the posts and I have added some of my experiences on the same matters.

Dealing with Bad Apples (read this post)

Looking at projects where we have seen individual issues, the ones that strike home are refusal to have code reviewed, increasing amounts of secrecy (keeping lists on paper not electronic, discussions with third parties outside of the project or company), consistent grumbling but supplication when confronted. But I think the most common sign is complaints about others to divert attention away from the real problem. I can’t say how much is conscious, and malicious or not, it must be dealt with.

The striking mark is people on the high horses who stand absolute in their correctness, my advice, shoot the horse and then deal with the problem.

The Bad Apple the Group Poison (read this post)

I have run though nearly all the projects that have had problems and this post contains the key -

The worst team member is the best predictor of how any team performs

and for worst, it is more attitude than technical ability.  We have seen projects with what should have been a dream team fail but this fits the pattern, not technology but attitude.

It is strange that the people who are the problem are normally the ones who should have the most potential, but have flipped the bozo bit and refuse help. It is rare that the people I encounter don't have the ability (they may need training and advice) but they are missing the point and sometimes languishing in politics seems an easier ride, but they always fail. Only once do I think someone was out of their depth and in that case I feel they were making the best of a bad situation.

In any project, people do need to stand up if there is a problem, and fight their corner, rather than just sit and whinge.  They then need to work through getting it resolved in a short space of time, in a reasonable manner, and accept the outcome.

In summary whilst it is generally best to maintain all project staff, there is a point when management must make a hard decision for the good of the group rather than the individual.

I’m interested in others’ experiences on this topic.

b.