Strappable Rollerblades

Adaptability to the context



I often wonder how a programmer should enter and study the subject in the context of the application domain of his project and how much they should stay out enough not to let condition in future projects. Let me explain.

I wonder how many of us will ever be in a meeting with domain experts, who discussed at length on an issue without reaching a. And how often, on those occasions, it appeared necessary to clarify some terms (eg why. Perceive the bad feeling that some terms were being misused by some and misunderstood by others, or synonyms that appeared semantically different, and so on)? And maybe we would have liked to ask questions trivial, even trivial, so simple ... and then we have been tempted to give up do not look for a perfect " incompetent"?

But ... you have done! Reckless, heedless of danger and thirsty for understanding. A veterinary instead of simple questions. You have helped the clarity of those present and permits that they should agree in the terms and meanings, bringing more and more towards the solution to their problem. But you risked big! About

program knows how deeply we must investigate matter to produce a quality software and above all know how fast you need to be able to extract from the experts' essential, you need the program to be implemented and how quickly we must finally know how to ask the questions right, those that lead to the elimination of contradictions or uncertainty (which presents each application domain). Who also knows that the program must be able to forget quickly to avoid portas preconceptions behind and incorrect interpretations that devierebbero the ideal solution to the next person and then bring him harm.

The knowledge that we reach during this phase of learning I would call it: horizontal knowledge. That we appropriate the fundamental concepts that allow us in an analytical way to organize information and provide what little autonomy they need. Next door to the identification quest'autonomia of all those tiny details of the program has vital need. This study is no longer self-sufficient , but occurs through a process of investigation and interrogation continued pointing towards our expert-party domain (say, on-site customer ?).

I was lucky enough to work in adult development (programs and equipment) in different sectors or application domains: building automation, medical equipment, hospital, banking, insurance, pharmaceutical and e-learning. What I learned is that the faster I learn, the more I forget. Quite the contrary: the more quickly forget the old, the more I learn quickly again.

L ' critical and vigilant against the knowledge of a specific business is a fundamental aspect of our profession. If we become experts ourselves, taking possession of what I would call the vertical knowledge, to the point of being able to do without the expert (a condition all too common for those who work for a long time as a programmer in the same type of organization), would lead roles of osmosis, ie the total autonomy of programmer. (Although in some contexts there may also be).

The consequences of this "transformation" are different.

• First, the expert in business starts to delegate anche la definizione delle nuove funzionalità da svolgere.

E in seguito si avrà:

• un eccessivo carico di lavoro intellettuale sul personale tecnico.
• errori di interpretazione nel programma.
• la perdita di interesse da parte del programmatore degli aspetti di design, leggibilità del codice, e semplicità della soluzione;
  
• degrado del livello di sostenibilità del prodotto e che noi sappiamo essere, come il punto precedente, linfa vitale del software, nel genuino interesse economico del committente.
• un inesorabile ridimensionamento dell'importanza della formazione tecnica e della sperimentazione di nuove idee, nuove tecnologie e nuove indagini e tecniche di sviluppo del software;
  
• la compromissione dell' innovazione nell'azienda o della capacità evolutiva del prodotto in un contesto di mercato fortemente concorrenziale .
• l'implicita promessa di carriera , nei confronti del programmatore, che si basa maggiormente sulla conoscenza verticale del dominio e non, come dovrebbe, sulla sua capacità di comunicazione, risposta al cambiamento, programmazione, disciplina e innovazione.
  
• la perdita di assunzione delle responsabilità in maniera distinta tra coloro che definiscono cosa bisogna fare e con quale priorità, rispetto a coloro che devono definire come e in quanto tempo (si pensi al planning game).
• il potere persuasivo esercitato dal personale tecnico che dimostrano di possedere conoscenza verticale, ossia padronanza profonda del dominio applicativo, sulla reputazione del programmatore all'interno dell'organizzazione. Fattore controproducente sulle performance nello sviluppo del software, perché svilisce la nostra difficile professione e degrada nel tempo le prestazioni di sviluppo e la qualità del prodotto del cliente.
  
• infine dall'invito implicito al programmatore ad imparare a new job, if he cared to earn more . (What a waste of know-how!)
  

How often is job for specialists in which the company is looking for personnel who have expertise in the application domain of the company that publishes it?

This pushes more and more the programmer to specialize in a particular business .

I believe in our work are those who are seduced by the horizontal domain knowledge, they risk losing flexibility of not being able to change color as the chameleon where the context so requires, or capacità di penetrare la materia rapidamente , facendo l'interesse del proprio cliente e dell' utente che si troverà confrontato 9 ore al giorno e per anni con il prodotto del suo lavoro di Programmatore.

Buon arcobaleno a tutti.