Quanto è importante la conoscenza del dominio e la conoscenza tecnica?

Il lavoro di un programmatore sta traducendo i requisiti del linguaggio naturale nelle implementazioni del linguaggio macchina. Non puoi farlo efficacemente se sei fluente da una parte o dall'altra. A meno che tu non stia scrivendo compilatori o software di controllo della versione, praticamente ogni lavoro di programmazione richiederà una quantità significativa di conoscenze non di programmazione.

Benjol e il tuo manager hanno ragione, ma lasciatemi elaborare:

l'apprendimento del dominio aziendale è il modo in cui aggiungi valore al processo e aumenta il valore per l'azienda

questa è la differenza tra un programmatore code monkey e uno sviluppatore

C'è un detto che viene dal Dipartimento di Informatica della mia Università:

If you want to build software for Geologists, you must first understand Geology. If you want to build software for Physicists, you must first dabble in Physics. If you want to understand business, then you first must learn to talk business.

Ho sempre sentito gente qui dire che lo sviluppo del software è un campo creativo. Credo che questo sia vero in una certa misura. Coinvolge la creatività in quanto deve essere in grado di vedere fuori dagli schemi per risolvere una serie di problemi.

Ciò che non significa è che puoi semplicemente sederti e creare così creativamente tutto ciò che vuoi. Questa non è una lezione d'arte, è di ingegneria, e i tuoi clienti e le parti interessate si aspettano che tu crei qualcosa che risolva i loro problemi, non qualcosa che sia semplicemente "bello".

Per risolvere un problema, devi prima capire il problema. Devi entrare nella testa dei tuoi utenti e capire come pensano.

Sia che tu stia sviluppando software per la finanza, il marketing, le vendite, la geologia, la fisica o qualsiasi campo supportato dal software, devi diventare parte di quel campo.

È proprio per questo motivo che, oltre alla mia laurea in Informatica, ho conseguito anche la laurea in economia; ha avuto un enorme impatto sulla mia capacità di comunicare potenziali soluzioni e fornire prodotti di successo.

Se vuoi saperne di più su ciò che cercherò quando assumo un ingegnere del software aziendale, dai un'occhiata a Esempio di annuncio di lavoro in Business Engineer che ho scritto come risposta a un'altra domanda.

Potresti sopravvivere senza la conoscenza del dominio o il contatto con i clienti come programmatore di basso livello, ma un architetto software è qualcuno che ha molta familiarità con il dominio e comunica attivamente con tutte le parti interessate.

Secondo me, sei sbagliato e troppo ingenuo.

Come ha detto il tuo manager (un po 'frivola), chiunque può imparare una tecnologia in una settimana. L'unica cosa che ti segnerà e ti renderà utile alla tua azienda è la tua conoscenza del business. E più è difficile, più ne varrà la pena.

Ovviamente, se si scopre che questa particolare attività è opprimente, si può cercare qualcosa di diverso. Ma se la tua idea di paradiso è hackerare insieme piccoli siti web php, fai attenzione: ci saranno migliaia di script kiddies che stanno facendo anche questo.

Seriamente, "Sono solo un programmatore, non mi confondere con i fatti", semplicemente non lo taglierò.

Se stai sviluppando per un'azienda, finirai per avere un'idea più chiara e più dettagliata delle regole aziendali di chiunque altro all'interno dell'azienda. Questo non è necessariamente perché sei più intelligente di tutti, perché è l'unico modo in cui puoi fare il lavoro.

La tua reazione potrebbe essere "Ma cosa fanno gli analisti di business?"

Gli analisti di business siedono in lunghe riunioni con i clienti che cercano di ricavarne dei requisiti sufficientemente chiari da consentire a uno sviluppatore di lavorare. Guardo il modo in cui hanno a che fare con i clienti e mi sento grato di non doverlo fare.

Mi piace disegnare analogie tra lo sviluppo del software e l'architettura. Entrambe sono arti applicate. Entrambi richiedono elaborati modelli nella propria mente. L'aspetto che si applica a questa domanda è che scrivere software senza conoscenze aziendali è come progettare un edificio senza comprendere lo stile di vita e le esigenze degli abitanti. Penso che molti di noi abbiano visto (o addirittura vissuto / lavorato in) edifici che possono sembrare belli e moderni e che non provengono dall'esterno, ma non sono usabili dall'interno. (Nel peggiore dei casi, non sono nemmeno belli: - ((()

Aggiornamento

Il commento di Gaurav:

what I am curious about is to what extent should a developer make effort in understanding the business domain. Should he go all the way, or there is some line to be drawn.

Non penso che tu possa tracciare una linea ovunque in generale. A meno che non ci siano parti dell'app / dominio non è necessario toccare (quindi capire) mai. Quale è IMHO molto raro nella vita reale, a lungo termine. Qualsiasi parte di un'app che è in uso riceverà segnalazioni di bug e richieste di funzionalità. Anche i domini cambiano, poiché la legislazione, le norme fiscali, le politiche, le abitudini corrispondenti - in breve, il mondo reale - cambiano. Questo deve essere seguito anche nel software.

Ma anche senza richieste esterne di modifiche, test unitari e codice di refactoring legacy è necessario comprendere anche le aree di dominio pertinenti. Altrimenti basta "congelare" il comportamento corrente dell'app, senza sapere se sia effettivamente corretto o meno.

Update2

what if [...] developer frequently changes the business domain he is working on?

Ovviamente significa che gran parte dell'investimento (del tuo tempo e del tuo datore di lavoro) per guadagnare la tua conoscenza del business va persa :-( Se sai che succederà, ovviamente non varrebbe la pena scavare troppo in profondità in un dominio specifico.Nota però che i domini non sono totalmente diversi, ci sono dei fondamentali che possono essere riutilizzati tra domini diversi e, soprattutto, il dominio approccio guadagni è riutilizzabile.

Ho lavorato nel settore bancario per oltre dieci anni sviluppando applicazioni di trading e concordando sul fatto che è importante che gli sviluppatori comprendano bene l'attività. Ma più e più volte, durante i processi di intervista, se la persona non ha una buona conoscenza del business, non passa per la porta.

Ciò ha portato a un numero considerevole di applicazioni e sistemi critici sviluppati da queste persone con solide conoscenze aziendali ma con competenze tecniche di livello medio-basso. Questi sistemi finiscono sempre per essere progettati male, costantemente in crash, crivellati di bug, non scalati, quasi impossibile da aggiustare senza rompere qualcosa, e questo è se il progetto non finisce per essere cancellato a causa di un'insufficiente capacità tecnica per ottenerlo in produzione.