, , , , ,

Recently, I had the opportunity to share a very interesting talk with some university colleagues. It’s now more than twelve years since we finished our studies in Computer Engineering. We work in different industries and for companies of different sizes. Some develop products, other provide services to customers in a variety of sectors. In summary, it’s a quite diverse representation in the IT and computing industry.

The four of us shared the vision that IT engineering, no matter if it is software related or infrastructure related, is understood by customers and managed by senior management with quite a different approach. We also agree that for IT to be considered a more mature engineering field it needs to evolve to be more similar in terms of methodologies, tools, compliance and required professional certifications. This, as I have witnessed several times, provides non-IT engineers with arguments to feed a certain superiority complex, quite similar to the one that the elder brother has towards his younger brother.

I will devote another article to the aforementioned aspects and focus on other aspects that when addressed properly, not often, can make the younger brother more capable, flexible and versatile than the elder brother.

The first strong point that IT has is that its main ingredient is non-tangible, even when computers are made of circuits and plenty of other infrastructures are deployed around any IT project. It’s programming that provides the major power to IT. Whether it is by a change on a parameter in a configuration file, a library’s version update or a new firmware release for an appliance, programming will allow to fix a problem or provide new functionality. The time between concept and deployment is much less than for most other engineering fields.

Nevertheless, the real capacity, although leveraged on software, comes from the fact that the range of professional profiles is much narrower. From the software architect or analyst and up to the developer and the tester, all of them work in the same office, come from the same background and share the same university degree,… there is no difference between white and blue collars. In no other industry the person planning the work could also execute the work because in most cases has done the work previously in his career. The progression in the career leads developers to become analysts, architects and program managers. In civil engineering, a worker will not make his way to being an architect or an engineer. In IT and without time limitations, a person can make a project by himself, covering all the roles.

Mmmmhhhhh, well, some of these points may not be exactly like that in many cases but this is where inefficiencies and problems appear, and I am not referring now to work in the same office since there is plenty of technology to help with that.

The problem arises when the team doesn’t have the right foundations, the background to grow from developer to architect. The fact that the building blocks are virtual, makes changes easy to implement, and this is positive. On the other hand, these virtual building blocks are also very complex. The laborer requires a global perspective of the project and a deep understanding of technology so that all the pieces combine perfectly. Even when modular design is used, interfaces are implemented to isolate different blocks and patterns help to give a cohesive structure that is robust and easy to maintain, the developers still need to know about the whole project. The difference between an architect and a developer is experience, not education.

When the value of having properly educated developers is underestimated, the number of hours required to implement the project increases and technology is perceived as unreliable. Fortunately, after some years of rapid evolution, this tendency seems to be changing and the value added by IT laborers ( developers, technicians, etc ) is being recognized on the same level as in other industries with a longer tradition.

Steve Ballmer said it properly: