Proof of Concept your Developers

With the rapid speed at which technology is changing I have found only one way to ensure it works as advertised, Proof of Concepts. The same holds true of your development team when you have no history with them. With the rapidly changing skill sets out there today, there is only one way to ensure your team has what it takes, Proof of Concepts (POC).

This topic starts with a few beliefs that if you don't agree with, just stop reading now.

1. Having the job title does not magically make the skills appear that you need to do the job.

2. Not all people are equally capable of learning.

3. There are people who are classified as non-trainable individuals. You fire them, period. The manager that says "there is no such thing as a bad employee, just bad managers", are in this category by default and should be fired immediately.

4. You can mentor a trainable individual into a certain skillset, but not with knowledge transfer alone. Hands on experience with the ability to learn is a must. Can you imagine a pilot that only read a book on flying a 747 showing up to fly your plane?

The last belief is where Proof of Concepts (POC) plays an important role in not only testing your choice of technology and architecture, but of your development team as well. There is no doubt that people are no where close to being as predictable as software components. Software components are lucky; they don’t have emotions or free will. It is however fairly easy to read a person’s skill levels when what they are making has a predictable outcome.

The last time I ran through this exercise was when I had a team of 3 developers. We were POC’ing a configuration of the Composite UI Application Block (CAB) from Microsoft’s pattern & practices group. I had 3 developers on the team. Each was given an equal workload which included building a complete smart client module from the UI to the DB. The technology proof of concept had already been done at this point, so we knew the technology worked as advertise, well mostly. The first iteration of development was a POC of the development team and of the framework’s architecture. We learned within a week that the team members had different levels of ability.

One of them was able to code all the layers of the application including the DB level, but didn’t like UI work. One was only able to develop the UI forms, and was able to lay them out well. The other was dangerous in a team environment and was locked out of source safe. They worked on the Help documentation, configuring servers, and did a lot of testing.

The initial plan was completely scrapped and the new assignments were made. We hit every estimate. If we had not POC’d the development team, we would have delivered buggy late code with each iteration.

I have been a lot of places that do not make adjustments like this and usually suffer dearly for being so closed minded. Some places I have been are too free spirited and end up suffering as well. They like to pretend everyone is equally talented and capable of every task. That is silly to me. I would rather have 3 experts that are limited to specialized areas, than have 3 generalists that know a little bit about everything, but specialize in nothing.

It is ideal to have a team of well rounded experts, but at the rate technology is changing it is doubtful you will get that very often anymore. Some will be trainable and therefore retainable, but when you get someone who is not and they need to be replaced, you need to learn that as soon as possible in the process. Interviewing is not enough.

The further along in the development process a buggy component is allowed to get, the more it ends up costing your project. The same is true of the defective developer. They ether need to be helped with getting up to speed, or deleted and defragged if you don’t have the time or resources to do so.