Month: August 2006

1. Make Sure the Promotion System is Unassailable: In companies where promotions are not available, merit pay systems tend to become contentious, because merit increases are the only way to earn more money. When promotions are available, employees tend to focus on promotions rather than the merit pay system. A promotion system should be founded upon a series of job grades, each with a salary range in line with industry standards and regional averages.
2. De-emphasise the Merit Pay System: Studies have shown that, when information sharing and coordination are essential, organisations that reduce pay differences between the highest and lowest paid employees tend to perform better over time.
3. Tie Profit Sharing to Economic Divers: Identifying a key economic driver and tying team profit sharing to it avoids suboptimisation by ensuring rewards are linked to improvements as a whole.
4. Reward based on Span of Influence, Not Span of Control: Evaluating individual results rather than group results, creates competition rather than collaboration amongst team members. Profit sharing should reward large teams rather than individuals or small groups. This reward system fits well within an Agile environment, which takes the broad approach of involving everyone in the development process.
5. Find Better Motivators than Money: Do not use money as a primary motivator. Invest in people by developing their skills, share information widely, emphasise Leadership rather than Management. Emphasise the intrinsic rewards of fun, growth, teamwork, challenge and accomplishment. Monetary rewards should be treated like explosives! Use them lightly and with caution.

(Taken from ‘Team Compensation’ by Mary Poppendieck, Aug 2004, reprinted in ‘The Best Software Writing I’, selected and introduced by Joel Spolsky)

Noticed this String Formatting in c# compendium via Mitch Denny‘s blog. A nice reference to bookmark. Most of this information can be found in MSDN, it’s just that I have trouble finding it every time!

If you have already subscribed to this feed in an aggregator, could you redirect it to the new feedburner feed at the link on the left hand side. Thanks!

…So I’m having this nightmare about a marauding robotic giant Squid controlled over the internet by masterminds unknown…Bruce Schneier continues his squid themed Friday blog posts!

Microsoft have recently released Performance Console (PerfConsole) 1.0 a tool that can be used to simplify and analyse Visual Studio profiler output:

“PerfConsole is a simple performance investigation tool which tries to adopt a
debugger like experience to drilling into Visual Studio Performance Profiler
generated data.”

This is for those managers who believe they can promote team work by giving raises to just a few members of a team! If you are a manager that has recently experienced high staff turnover, I suggest you read this carefully:

1. When team members are in competition with one another for their livelihood, team work quickly evaporates.
2. There is no greater demotivator than a reward system that is perceived to be unfair. It does not matter whether the system is fair or not, only that there is a perception of unfairness.
3. When management exhort team members to do what is clearly impossible through the offer of rewards rather than helping to make the task possible, people are likely to be insulted and give up without even trying.
4. Optimising a part of chain invariably suboptimises overall performance. One example is separating software development from support and maintenance. If developers are rewarded for meeting a schedule even if they consequently deliver error-prone code without automated test suites, then support and maintenance will cost far more than was saved during development.
5. Once team members get used to receiving financial rewards for meeting goals, they begin to work solely for the rewards, not the intrinsic motivation that derives from doing a good job and making their company successful.

(Taken from ‘Team Compensation’ by Mary Poppendieck, Aug 2004, reprinted in ‘The Best Software Writing I’, selected and introduced by Joel Spolsky)

I’ve been hearing a lot of good things about this book Beyond Bullet Points by Cliff Atkinson. I haven’t actually got my hands on a copy yet (one topic sure to get me on a rant, is how it is quicker to get a shipment of books from Amazon in the US to my doorstep, faster and cheaper than going to a technical bookseller in Perth), but I will presently.

I noticed that a recent talk by Brad Wilson on the topic of agile pair programming was written using these techniques, and several other high profile presenters seem to be taking Cliff’s advice on board. Definitely one to add to the reading list.

Want to hear something really scary? On average, a programmer reads just one technical book a year (Code Complete: Steve McConnell). It got me thinking; let’s be optimistic and say that the average every programmer reads 2 technical books related to their work each year. Now assuming you have a productive working career from the age of 20 to 60. That means you will read just 80 technical books in your entire working life! As a consequence, it means you should be very discerning about which ones you read. You may not have realised it but you just don’t have time to read any poor or out of date technical books!

OK. Now you have decided to only read useful books, how will you pick which ones you should read? Jeff Atwood put up a list of recommended reading for developers, and I’ve previously posted a list of recommended computing books. One that is on Jeff’s list that I really should add to mine is The Pragmatic Programmer: From Journeyman to Master. You could probably read this book together with Code Complete and be well on the road to enlightenment!

Brad Abrams has posted these useful answers to common .NET Framework deployment questions.

Microsoft profits fell to a paltry $2.8 billion this quarter, due largely to huge legal expenses.

Microsoft executives have known for some time that sales in the Operating System market will inevitiably fall off and that Microsoft’s period of explosive growth is at an end. Once that happens, if you want to continue to grow then you need to take market share away from others. Which means leveraging your dominant position into other areas, such as business document management, document workflow and CRM, to name a few.

Just under 3 years ago, I was working alongside a team producing document management software for fairly large companies. I tried to warn the manager of this team that there was a strong likelihood that Microsoft would be moving into the area of document management and workflow (i.e. in addition to the existing SharePoint software) and that they should draw up a 3 – 5 year business risk/strategy plan in order to decide what could be done to mitigate this risk, and indeed how long a market would exist if Microsoft entered the arena. Instead, he choose to put on the blinkers and completely ignore this advice…

Whilst I don’t have a crystal ball, it seemed inevitable that the outcome would be that in 1 – 2 years, Microsoft will have a product (something like ‘WorkPlace 2007’ or OfficeFlow or OfficeAdvance, you get the idea!) that it will compete with existing content management systems like Documentum, DocsOpen, HummingBird or OpenText. EMC, the owners of Documentum, already seem to be moving away from this area.