Domanda da ignorante... quanti metodi può contenere una classe?

[MySQL]

Significa solo che non hai mai visto un progetto fatto bene...
Una parola: ortogonalità. Prendi symfony, che è un progetto medio/grande. Quanti di quei commit pensi che siano arrivati da persone che abbiano visto e compreso tutto il codice scritto finora? Proprio nessuno, neanche il fondatore.

Guarda, sono tra i maintainer di un progetto più grande (forse il più grande), insieme a molte altre centinaia... ma...
"ortogonalità" significa...

Perché non ha importanza (e non è proprio possibile e basta). Perché anche in quei milioni di righe di codice, se devi modificare qualcosa, sai già cosa devi andare a vedere. Quanto tempo pensi che ci voglia per lavorare o modificare uno di quei componenti senza averlo mai visto? 15 minuti.

15 minuti? Guarda, mi basta così

Che dipende. Il "basta che funzioni"...

Come già spiegato ci sono tanti altri che la pensano in maniera diversa (dagli agili in giù). Se ritieni che chissà quale schemino ti consenta di capire (ed essere autorizzato a) come modificare lo scheduler (gli) Linux in un branch "vero"... in 15 minuti... OK... buona fortuna... cambi una virgola qui, e un server in Cina smette di funzionare (cit rimaneggiata).

Hai mai visto i mitici diagrammi di flusso? Ebbene, sarai d'accordo che non servono praticamente a nulla, se non per frazioni minime di algoritmi minuscoli (immagina il diagramma di flusso di Word...)
Ebbene UML e i superacronimi non fanno molto di più, aumentano forse di un ordine di grandezza il livello di comprensibilità (cioè passi da un foglio A4 a un foglio di plotter pieno di disegnini).
Oltre, purtroppo, non arrivano, perchè quando ti servirebbe uno schema grande come un campo da calcio non puoi farcela, qualsiasi cosa "spaccino" i vari "evangelisti".

Perché, se io cliente, devo scegliere tra due sw entrambi funzionanti e che fanno le stesse cose...

Ahem... direi che di clienti ne hai visti ben pochi, o pressochè nessuno in ambito industriale.
Perchè la risposta è "quello che costa meno".
Senza se e senza ma.
Provare, per credere.

Inoltre, è molto imbarazzante se il cliente, dopo neanche un mese, ti chiede una modifica e gli devi chiedere del tempo perché non hai idea di cosa faccia il tuo stesso codice.
Ancora peggio se una piccola modifica necessita la riscrittura di una buona parte dell'applicazione, lì c'è da piangere. E' esattamente in quel momento i venditori di acronimi scuoteranno tristemente la testa.

Certo, gli "spacciatori" gireranno con la Panda (aspettando di vendere un programma) mentre l'"agile" avrà l'autista o la Ferrari a seconda dei gusti.
Ho messo sopra un'intervistina che riassume molto bene la differenza tra "hobby" e "industria" informatica.

Ribadisco: ho come l'impressione che sei abituato ai progettini del sitarello del panettiere sotto casa o dell'(in)utiliy open source, dove se c'è un problema nessuno ti fa causa per i danni.

Non c'è nulla di male, in questo, intendiamoci.

Ma la minestra è diversa, molto diversa, quando i progetti costano centiania di migliaia di euro, e solo una frazione sono relative alle licenze, e devi fornire garanzie patrimoniali.
Quando poi si passa ai milioni (di euro) subentrano ottiche ancora diverse, ma in Italia essenzialmente non ci sono (se non per un pugno di aziende pubbliche e private, banche e assicurazioni).

Precisato tutto ciò siamo (hai dovuto riconoscere che...) giunti alla conclusione che neppure gli spacciatori di acronimi riescono a far comprendere come funziona un progetto complesso; ritenere di poterne modificare una porzione così... "a casaccio"... sperando che NON abbia ripercussioni più o meno complesse e più o meno sottili e difficili da individuare, significa avere ancora tanti tasti da premere.

Tra l'altro son curioso di sapere PERCHE' ci sono 1000 acronimi (che non significano assolutamente nulla, per chi ha le competenze per capirli) invece di 2. Se fossero così magici, perchè 1000?