Correlation between the application design and the human resource recruiters

Correlations are useful because they can indicate a predictive relationship that can be exploited in practice. In this post I will relate my experience in two projects using the same technology, and how the application design choices imparcted the human resource recruiters.

First experience:

In this first experience, I worked in a project developed mainly in C++ and using widely the COM technology.

The COM types were used everywhere in the source code. Therefore, each developer must have a good knowledge of COM programming.

This project was developed in three years and during this period, many changes happened concerning the recruitment of new C++ developers.

In the beginning the managers requested the human resource recruiters to search for developers mastering C++ and COM technology, after few months they discover that’s not an easy task, and it’s difficult to find profiles recommended by the technical managers.

Due to the complexity of the recruitment task, the technical managers asked just for developers mastering C++, few months after the recruitment of new C++ developers, the result was very bad, many bugs concerning the COM technology was introduced, and the product became instable, which force us to review the entire source code and resolve all COM issues.

After that, the technical managers want only C++ developers mastering the COM technology, and the headache of the human resource recruiters was reborn again.

Before my second experience, I had the same idea as my technical managers, we were very confident that our human resource recruiters are not competent.

Second experience:

In my second experience I worked with another software editor using also C++ and COM technology, but their approach was totally different than my first project.

The designers chose to isolate the COM types only in a few classes, which acts as wrappers, and in the whole code only basic C++ is used. With this design only one developer mastering COM is needed, it was me.

After few months working in this project, I discovered the big difference between the two approaches:

- The task of developers is easier than my first project, no need to fight with the registry key and spend days to understand why a COM objet is not instantiated.

- The task of human resource recruiters is also simplified, no need to look for COM gurus.

- The task of testers is simplified, no need to understand how to register or unregister COM objects, and how to resolve the COM deployment issues.

After my second experience I understood that in my first project, the technical managers did big design mistakes which complicate the task to the human resource recruiters.

This example could be applied to many other technologies, like EJB, CORBA and web services, the result will be the same if the project is highly coupled with these technologies.

A high coupling with a technology, will not only complicate the task to the developers and testers, but also will make the task more difficult to the human resource recruiters.

It’s preferable to check the coupling of your application with all frameworks used, and if possibile isolate their uses in only some few classes, by using wrappers and facades. Personally in case of C++ projects I use CppDepend to detect the coupling with all frameworks and libraries used, but doxygen could be also sufficient for such needs.