Jim Lives Here

I'm a big fan of Thinktecture, in particular their WSCF tool. It’s a wonderful tool for contract first development, allowing you to define your messaging or data structure, and generate classes in VB or C#. The bonus is that it will generate code for you that uses generics, and data binding, if you so wish. It’s a great tool.  On the whole it does a far better job than the XSD tool ever did.

   On install of WSCF version 0.7 on Vista with VS 2005 SP1, the installation halts and gives up a rather nondescript error message. The installation rolls back after yielding a mysterious number: 2869. Nicht so gut, ja? The forums at thinktecture have hints of a solution, but the links are broken and there is nothing about it in the 'known issues'. Hmmm...

  The issue is with installer packages that use custom actions that require administrator privileges to run and fail to set the No Impersonate bit on. So in short the answer in my case was to simply run msiexec with the WSCF installer from a command prompt with elevated privileges.

  However, if you want a more permanent solution to a similar deployment issue in your installer (and I suggest the guys at ThinkTecture consider this) then a slightly less hackish approach is to either ship a separate manifest file or embed it in your executable so that it demands administrator permissions. Heath Stewart explains this much better than I ever could:

  "You could also put a manifest file in the same location as the executable, with the same name as the executable with .manifest appended to the filename. For example, a manifest for setup.exe would be setup.exe.manifest. If you are an ISV that wants to pre-elevate your installation, you could embed the same manifest in your executable as an RT_MANIFEST resource with an ID of 1. Either way, example content of that manifest follows:

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">

    <assemblyIdentity

        type="win32"

        name="nwrapdrvr"

        version="3.12.0.0"

        processorArchitecture="x86"/>

    <description>Patch Wrapper</description>

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

        <security>

            <requestedPrivileges>

                <requestedExecutionLevel

                    level="requireAdministrator"

                    uiAccess="false"/>

            </requestedPrivileges>

        </security>

    </trustInfo>

</assembly>

Why are there so many programmers out there that can't program? That seems to be this weeks blogversation (thanks Scott H). Perhaps this is equivalent to asking why are there so many people who can't spell? I think it's because we dont teach people properly.

Jeff Attwood contends there is a 'vast divide between those who can program and those that cannot program'. And he'd be right. The evidence available suggests that people have either got the knack or they don't. Scott Hanselman writes that you 'cannot teach height'. True, you cannot learn what only genetics can give you. However, I'm a little concerned that we aren't looking at this issue through a wide enough lens. My instinct tells me that these facts are all the more reason to sort the sheep from the goats a whole lot earlier than we are at the moment.

I think the source of this problem is twofold:

• We arent sorting good programmers from bad early enough.
• We arent providing the necessary breeding ground to ensure that good programmers rise to the surface.

The interview process is too late. This is why any and all comers are knocking down Jeff's door for a job. They think they can do it, and nobody has told them otherwise. We should be spotting programmers before they reach the age of 18. The university degree is obviously not as important as universities would like us to think any more. What is forming is a classic catch 22. To get a job in IT you need experience, and to get experience you need to have had a job in IT. Nothing is more valuable than experience is it?

Perhaps our biggest mistake is that we look at training programmers like we do our other science or arts graduates. Give them a wide range of subjects and make them pass difficult, if not irrelevant examinations. They end up with a very general knowledge of computing. Specialized programming courses come a lot closer, however they too share the same weakness: lack of peer review. Herein lies the issue with certification, it doesn't adequately test ones ability to perform the job. It doesn't put you through your paces and make you solve real problems, in the real world, in real time. This is why the FizzBuzz concept strangely works, however its too little too late.

Incidentally, IT isn't the only industry to have this problem. The trades have been struggling with this issue for a lot longer than computing has been around. Im not saying that the tradeskills training programs in Australia are the posterchild for best practices in this area, however there is one concept that the trades have that works, that we overlook in IT. The apprenticeship.

For those of you who know me, you would know I have a unique perspective on this matter, as a mechanic by trade, I have seen the benefits and the downsides to apprenticeships.

Pros

• Combines training with usable experience.
• Wage subsidies for employers.
• "Teaching is the best teacher." Ensures senior staff get to revisit the basics once in a while.
• Abstracts the selection process away from the employer. Employers dont have to choose apprentices, the apprentice board will do that for them if they so wish.
• Gives the employer the oppurtunity to retain good employees, and discard the bad.

Cons

• Apprentices may not end up in the exact job they were after.
• Apprentices are inherently younger, and oft need 'coaching' in life skills. I.e. turning up on time, truancy etc.
• Apprentices rely on the workplace for over 50% of their training.
• Employers may have to drop their expectations for an 'entry level coder'.
• Some apprentice/employer relationships may end up resulting in the apprentice 'riding the broom' for four years.

Whilst its clearly no silver bullet, its got to be better than 99.5% ineptitude amongst applicants for senior roles.

We should be hiring kids out of senior high school and putting them alongside veteran coders whilst giving them solid, programming specific training for at least 4 years before they even get to call themselves a code monkey. Only the really interested apply, because the disinterested much prefer a McJob at that age. Combine the formal training with real world experience. Provide a base level of skills. Lets not get all wrapped up in how elitist the programming club can get. Let us remember that good quality training is the key to creating good quality professionals. We aren't that different. Lets concentrate on eliminating the catch 22 of experience.

If you are having trouble seeing the sheep for the goats, then breed more sheep.