Tempo fa, stufo della lunga sequenza di banalità sul fatto che i tecnologi e gli ingegneri “non capiscono i problemi di business, ma sono solo capaci di parlare di tecnologie” scrissi un post dove spiegavo che un bravo ingegnere, by definition, deve saper partire dalla comprensione ed analisi di un problema. Se non lo fa è un cattivo ingegnere.
Alfonso Fuggetta – Chi è un tecnologo?: “Un tecnologo, un progettista, deve innanzi tutto saper studiare e caratterizzare i problemi e i sistemi (complessi) che li caratterizzano. Nel campo del software, per esempio, qualunque libro di Ingegneria del Software ha come primo capitolo l’analisi di dominio, la caratterizzazione del problema e la specifica dei requisiti utente. Un tecnologo che non sappia studiare i problemi e che non usi queste informazioni nella costruzione della soluzione semplicemente è un cattivo tecnologo.”
Oggi leggo un articolo che riprende concetti simili e li allarga discutendo il modo strumentale usato per squalificare il ruolo dell’ingegnere e del tecnologo da chi non capisce le tecnologie:
Do Software Engineers Get Enough Respect? | TechCrunch: “But there’s yet more going on here. Engineers are treated as less-than-equal because we are often viewed as idiot savants. We may speak the magic language of machines, the thinking goes, but we aren’t business people, so we aren’t qualified to make the most important decisions. That’s for the analysts, the product people, the MBAs. They might throw money our way, but they don’t take our opinions seriously, at least not the ones they understand.
Whereas in fact any engineer worth her salt will tell you that she makes business decisions daily–albeit on the micro not macro level–because she has to in order to get the job done. Exactly how long should this database field be? And of what datatype? How and where should it be validated? How do we handle all of the edge cases? These are in fact business decisions, and we make them, because we’re at the proverbial coal face, and it would take forever to run every single one of them by the product people…and sometimes they wouldn’t even understand the technical factors involved.
Now, granted, good managers have to make good decisions based in perpetually insufficient information while also satisfying their superiors, keeping their subordinates happy and busy, and exceeding their clients’ expectations. This is an extremely difficult job. (I’m a sometime manager too.) You could argue, and in fact if pressed I probably would, that excellent managers are at least as rare as excellent engineers, and should arguably be valued more.
But we’re not talking about comparing relative value here; we’re talking about writing off software engineers, as a group, as lower-tier employees kept apart from the Important Decisions. We’re talking about the tendency to treat engineers as idiot savants, capable in the technical guts of their own world, but naïfs who need guidance in the larger realm of business. This is of course ridiculous in a world where ‘technology’ and ‘business’ are increasingly intertwined–
–but I think it’s an inevitable side effect of companies who boast completely non-technical managers. People who have never written code or soldered diodes, who don’t really understand what and how engineers do what we do, have no alternative but to have blind faith in us. Which, paradoxically, leads to less respect, because it’s the root cause of idiot-savant syndrome.”
Beh, non ho molto da aggiungere.