Guild Blogs

Having recently been involved with a team that was being exhorted to "step up" and "go the extra mile" I noticed a range of responses from "lets go" to "why bother" to "I don't think so". After thinking about the response I identified several personal factors:

1) Internal motivation: some people are just go getters, you love to have them on your team, but sometimes they are seen as little puppies by other members of the team because they are perceived as being overly eager to please. Motivating this type of person is trivial.

2) Internal ambivalence: some people just don't have that drive. "Programming as a job" is an attitude that some in our industry have. These people do a good job while they are at work, but when they are not at work - they aren't. Motivating this type of person is more difficult since your have to convince them that the extra hours are worth it to them. The typical example for internal ambivalence is the programmer who don't read technical material, go to conferences or training. They expect to pick up everything they need to know between 9 and 5.

3) External personal distraction: there are those who may have the internal drive, but because of various personal/external reasons choose to place other priorities in front of work. Motivating this person is not likely to succeed without significant effort because they have consciously prioritized their work life at a lower level. An example here is the developer who's wife just had twins and is bed ridden. Attempting to get this person to spend more time at work boarders on malfeasance.

There are also a couple of factors the motivator brings to the table:

1) Trustworthiness: in several jobs I have seen otherwise motivated individuals who don't respond to motivators because the individual has determined that the motivator is not trustworthy. Thus any promise in the world will not help because the individual doesn't believe the messenger.

2) Disagreement: Closely related to trustworthiness is when the individual doesn't agree with the path the motivator is proposing. This one is trickier since this could just be resistance to change.

3) Approach: here the individual is not being motivated correctly, the carrot is offensive, or the individual is just not interested in that particular carrot. Typically money is used as a motivator, but money is not equally important to everyone. A great example here is the "employee of the month" award - I bet you can't find developers who are motivated by this kind of reward.

Which kinds of motivating factors have you seen work for or against the desired outcome?

Brian Marick posted here and here about burnbown chart styles and I thought I'd chime in with my variation.

I use a slight modification of Kelly's burndown. I always put the remaining work on top of the bar and use real dates across the bottom. Additionally you can add a third category called tested/accepted in cases where the organization insists on a separate testing group.

I was talking with Scott Hanselman (gratuitous name drop) about the difference between rpc and document style. It took me a moment since I don't deal with SOAP internals much any more. It occurred to me shortly thereafter that I don't really care other than I have a bias towards document style.

My take is that the angle brackets need to go away from the average developer's day to day experience. I've had a similar argument with cohort Scott Came over how much developers should really know about XML. He says everyone should know and understand the details of infoset and schema, where I just see this stuff as file formats. Angle brackets are already starting to go away as the various tools are coming of age. XML is a great file format and will exist for many years to come, but I don't expect to read it on a day to day basis any more than I expect to pop open my favorite word processor and start typing RTF control words.

Interesting bit of detective work the other day I thought I'd share with everyone. A friend of a friend was having trouble with an ASP 2.0 project that was ported to ASP.NET. Turns out that on some web servers the different clients were getting their data overwritten by others. A little splunking uncovered that the application was maintaining state using a public variable declared in a VB module. I could guess what was happening, but wanted to know the details so I created a tiny test app that looked like this:

Module Module1
    Public moduleinteger As Integer
End Module

I compiled and then decompiled the assembly into C# with the following results:

namespace ModuleTest
{
        internal sealed class Module1
        {
                public static int moduleinteger;
        } 
}

So essentially the vb compiler turns the module keyword into the c# equivalent "internal sealed class" and makes all public variable static. Also any reference to the public module variable gets the "module" name added to it as well. And since static variables are the same across all threads any update to one, updates all.

Ask E.T. had a pointer to Dotplot.

An entire software module of a telecommunications switch about two million lines of C.

Seems to be some interesting visualization here. I'll have to keep this one in the memory banks for future use.

In many organization I've encountered there is this artificial distinction between the new development group and the maintenance programming group. Why on God's green earth would you want to do such a thing?

Every time the topic comes up I point out that there is only "maintenance" since once you have the first line of code checked in you are now maintaining the system. Probably the only difference between "new development" and "maintenance development" is whether the system is being used in production or not!

A better approach in my opinion is to view all your systems as the software ecosystem for your organization. You now have the common problem of limited resources to change/add features to the ecosystem. The features may or may not be added to systems that already exist. Whether the system already exists is irrelevant to the decision to spend money on that feature.

Organizations that have adopted agile practices eventually notice that there is little or no difference between new functionality, enhancements and bug fixes. If there is a difference it is more a difference of granularity in that some bug fixes are very small while everything else tends to be larger.

The advantage of the ecosystem approach is that your development resources are more of a pool that you can draw from, the stigma of being on the maintenance team doesn't exist, and knowledge can be spread among the team.

Think about it, try it. You might like it.

From Project, Process & Business Improvement: Are You Loved?

A.J. found in Executive Leadership this list of the 5 biggest complaints employees have about their bosses:

1. Threats
2. Inconsistency
3. Wasting their time
4. Micromanaging them
5. Hypocrisy

How many of these have to exist before your top talent starts walking out the door? I suspect it somewhat depends on the economy and how interested/vested they are. I suspect, however, that once you hit 3 out of 5 people start walking out the door.

In reflecting on my previous post regarding shared libraries in VSS vs CVS I realized that the end of the post got to the real meat of the matter. Turns out we are using a feature of VSS to help us organize our shared libraries, however, shared libraries really have very little to do with version control (except for released versions of course).

So I did a little more research and found the Team Development articles on MSDN, specifically the one on Managing Dependencies. Here is their main recommendation:

Project references are the main reason you should adopt a single solution or partitioned single solution model wherever possible.

In the Single and Partitioned Solution Systems section:

Use project references wherever possible and aim to minimize the use of file references.

These recommendations are a little simplistic. Surely Microsoft doesn't have a single solution for the entire .NET framework! And they are only building a single product.

Further on they propose an alternative that sounds promising - use a build server and place the shared libraries on a file share. Additionally you can copy the shared libraries locally from time to time to support disconnected development and developer control over when libraries are updated.

This sounds like it will work well as long as you have a build server and all developers map the shared library share to the same drive letter. In fact using a mapped drive letter allows a lot of flexibility in that just by changing the drive letter mapping you can point to the release version, debug version or the local version of the shared libraries since VS.NET stores the absolute path to shared libraries in the project file (in the HintPath attribute).

Other articles:

• William Bartholomew Organising Visual Studio .NET Solutions
• Jeff Gonzalez Solution and Project Organization
• Roy Osherove How to: Creating project groups under a single solution
• Robert W. McLaws Developing Components: Code organization, a technique reexamination and modification

Saw this on StickyMinds today: Bumper Stickers for Testers

My favorites:

• Software Testers: "Depraved minds...Usefully employed."
• Software Testers: We break it because we care.
• A good tester has the heart of a developer...in a jar on the desk.
• Friends don't let friends do capture-replay.
• Trust, But Verify.
• Pertempto ergo sum – I test, therefore I am.

Anyone have any bumper stickers for development, project management, product management, documentation, DBAs, etc?

Via Clarke Ching

In early 2003 Michael Crichton gave a fascinating Caltech Michelin Lecture titled  Aliens Cause Global Warming.

He argued that a lot of today’s science is bad science and that bad science is often used to back up good policies.