El desenvolupament de programari, com a disciplina, es fonamenta en paràmetres, variables, biblioteques i molts més elements. En la combinació de tots ells, no hi pot haver errors però, de vegades, succeeixen i projectes que semblaven destinats a l'èxit i que es van dissenyar per fer més fàcils processos i tasques fracassen per falta de pressupost, programadors perfeccionistes en excés i, fins i tot, ingerències administratives. Hi ha, tanmateix, una sèrie d'errors recurrents que, de tan repetits, valen la pena ressenyar-se, ja que un, alguns o, fins i tot, tots alhora solen donar-se, d'una manera o una altra, en els projectes fallits.
Triar la metodologia equivocada
Totes les metodologies de desenvolupament de programari tenen seguidors apassionats per les regles que defineixen la seva manera favorita d'organitzar un equip. El problema sol estar en elegir l'adequat per al seu equip. Imposar regles des de dalt és mala idea, perquè no hi ha res pitjor a posar a un programador a treballar des d'un enfocament que no consideren adequat. Amb tot, permetre als programadors que escullin la metodologia que satisfà els seus interessos i desitjos sempre és també un error. Per tant, és clau el consens, perquè amb una metodologia adequada es reduiran les friccions i tothom sabrà què ha de fer i què s'espera d'ell.
Escalabilitat
Crear un codi eficaç sense colls d'ampolla que sorprengui tots quan l'aplicació finalment s'executi a gran escala requereix molta previsió i lideratge. No és una cosa que pugui solucionar-se més endavant amb una mica de codificació específica i cinta adhesiva virtual. Així, algoritmes i estructures de dades s'han de planificar des d'inici perquè, més aviat o més tard i si l'aplicació funciona, apareixerà, primer, un milió d'usuaris i, després, mil milions.
No s'ha de ser víctima de les tendències
Els desenvolupadors de programari solen sentir-se sempre atrets per les idees més noves i cridaneres i, encara que aquestes idees poden arribar a solucionar problemes, també poden acabar frenant projectes sencers, ja que utilitzar una nova eina només és possible després d'un mínim període d'aprenentatge. Les noves idees, precisament pel seu caràcter nou, poden portar en el seu si|pit defectes ocults. Així, si tenim terminis de lliurament concrets, millor no inventar i utilitzar el que sabem que funciona i tothom sap fer servir a la perfecció. Per què hi ha empreses que encara executen programari escrit en COBOL? Just per això.
Emmagatzemar dades que mai no s'utilitzaran i evitar les proves
Per la seva formació, els programadors tendeixen a emmagatzemar informació per fer front a fallades|decisions|errors de seguretat o violacions de privacitat que mai no s'acaben donant. Cal ser, a més especialment acurat amb les dades sensibles, perquè si els emmagatzemem sense permís, podem tenir problemes. I mai no s'ha d'oblidar que una bona arquitectura del programari implica planificar perquè la quantitat de dades que s'emmagatzema sigui mínima i es redueixin costos mentre la velocitat del sistema és més gran. Tampoc no és bona idea estalviar-se proves que, encara que són un desafiament constant, resulten fonamentals per testar el codi i aconseguir que continuï sent viable durant tot el procés de desenvolupament.
Subcontractar la feina equivocada
El debat sobre la creació o compra de programari és un debat tradicional que no té una conclusió definitiva. Tot i així, els desenvolupadors de programari solen elegir malament. Potser hi ha una solució perfectament bona a bon preu i siguin massa orgullosos per deixar de banda la seva pila personalitzada amb el seu costós equip intern. També succeeix el contrari. Desafortunadament, decidir quines eines externes utilitzar tampoc és senzill.