Quand est-il OK de sacrifier la «netteté» de la conception pour réaliser un projet?

Lorsque vous travaillez sur un produit qui doit être fait rapidement et qui fonctionne bien, quand est-il acceptable de sacrifier la maintenabilité et la «propreté» du design afin de faire avancer les choses et de sortir rapidement? Et dans quelle mesure est-ce OK, surtout quand les techniques utilisées pour le rendre "soigné" sont nouvelles pour moi?

N'oubliez pas que vous êtes employé pour soutenir une entreprise. D'une certaine manière, votre logiciel affecte le résultat net de l'entreprise. Vous devez trouver un équilibre entre une solution techniquement parfaite, le temps de mise sur le marché de votre produit et les avantages que l'entreprise en retirera.

D'après mon expérience, les développeurs ont souvent tendance à se soucier de la perfection technique. Mais il y a des raisons très valables de sacrifier des attributs de qualité tels que la maintenabilité ou les performances afin de sortir un produit plus rapidement. Cela dépend de l'entreprise et du produit. Mais "toujours rechercher un design parfait" est une approche trop simpliste.

Au bout du compte, la seule chose qui compte, c'est la valeur pour l'entreprise. Découvrez comment l'optimiser à court et à long terme et visez cet objectif.

Le terme «dette technique» est très pratique pour éclairer de telles décisions commerciales. Tout travail que vous ne faites pas maintenant entraînera une certaine quantité de travail plus tard. Tout comme pour les finances, l'endettement est risqué mais peut valoir la peine d'être utilisé si vous allez pouvoir rembourser la dette plus tard.

Cela dit, la dette technique n'est pas un ratio de 1: 1 au moment du remboursement. Les bogues sont plus chers à corriger après la publication, et l'impact sur la productivité future lors du développement à partir d'un système hérité en désordre peut être scandaleux. Vous pourriez envisager de passer le double du temps à corriger vos erreurs, ou peut-être 1 000 fois plus d'heures de travail et de ressources.

Votre travail dans cette décision est de comprendre les ramifications des morceaux particuliers de coupe de coin que vous envisagez, puis de communiquer ces ramifications aux personnes qui prennent la décision commerciale. Cette compétence d'estimation particulière peut nécessiter beaucoup de recherches et de travail de votre part pour bien se développer en ce moment, mais elle sera précieuse au cours de votre carrière.

Quand il est accepté et que les conséquences sont comprises par le propriétaire / client / utilisateur.

Un plombier doit sortir une poubelle pour réparation. Je veux utiliser l'évier dans l'intervalle, mais il devrait me facturer le temps et les matériaux pour installer des tuyaux temporaires avec du ruban adhésif qui pourrait se casser. Cela va également retarder le retour à l'atelier de réparation. Si j'accepte la facturation supplémentaire en sachant que je risque un colmatage. Il faudra un jour de plus pour faire réparer les déchets et un délai encore plus long avant qu'il ne puisse les remettre, c'est acceptable.

Vous pouvez être à l'heure et au budget maintenant, mais sacrifier / risquer une charge encore plus élevée à long terme. Il peut être difficile de faire comprendre aux personnes non techniques, mais c'est à cela que servent les vendeurs.

Beaucoup de gens abandonnent rapidement pour apprendre quelque chose de nouveau et le font comme ils l'ont toujours fait. S'il s'agit d'un modèle, non seulement votre code souffrira, mais vos propres compétences en tant que programmeur resteront limitées.

Pourtant, à la fin de la journée, le seul logiciel réussi est celui qui est livré.

Après le délai doux passé. Et même alors, c'est un très faible degré de "OK". Une fois la dure échéance dépassée, il est bien entendu inutile. Parce que c'est la nature des délais durs.

De plus, cela engendre une dette technique. Pour chaque heure / jour que vous passez dans la mentalité simplifiée, cela vous coûtera environ deux fois plus de temps lorsque vous devrez ensuite toucher à ce projet. Si vous le devez, il est préférable de vous précipiter, d'expédier et de commencer immédiatement à réparer toute votre bande de canard. Revenir à un projet hacked des années plus tard est un cauchemar. Si vous ne le toucherez plus jamais, qu'il en soit ainsi, personne ne s'en souciera. Mais la seule fois où j'ai laissé un projet pour toujours, c'est quand j'ai changé d'emploi.

Rappelez-vous cependant que le timing de ces choses est le travail du chef de projet. Si vous êtes pressé de respecter un délai, c'est la faute du PM. Faites-le bien, faites-le une fois et faites-le calmement et correctement. La vie est trop courte pour autre chose.

Toutes les autres réponses publiées ici sont bonnes. Je voudrais cependant ajouter qu'en tant que développeur du projet, vous êtes l'intendant (protecteur) de la conception.

Si vous ne défendez pas la bonne solution technique, personne d'autre ne vous le promettra. Vous devriez toujours plaider pour faire les choses de la bonne façon auprès de votre patron et le PM devrait toujours plaider en faveur de la date limite.

Si tout va bien si vous êtes dans une organisation raisonnable, un compromis sera atteint qui aidera à respecter les délais et à ne pas trop s'éloigner du design en même temps.

Cela étant dit, ne présumez pas que si la date limite du PM n'est pas atteinte, le monde se terminera et le projet échouera. Ce n'est généralement pas si noir et blanc et la plupart du temps le délai du PM est doux et peut être modifié.

Presque toutes les échéances auxquelles j'étais confronté sur un horaire PM étaient principalement artificielles. Ils vont le défendre bec et ongles et prétendre le contraire cependant parce que si le PM repousse la date limite alors le PM LOOKS BAD!

Ce n'est pas parce que le PM semble mauvais que le projet a échoué. Si vous comprenez cela, vous serez surpris de voir combien vous pouvez faire plier un PM.

Citez le client pour la conception soignée. Si cette citation leur est inacceptable, entrez dans la ventilation de ce que chaque composant coûtera (généralement == temps de développement). Laissez-les retirer les articles "à la carte" s'ils le souhaitent. Beaucoup sauteront au rasage pour des choses "inutiles" comme les tests et la conception. Expliquez les risques de cette approche, mais s'ils acceptent le risque, procédez comme indiqué. Si je n'ai que suffisamment d'argent pour une voiture clunker, alors je vais acheter une voiture clunker, même si je sais qu'elle va probablement tomber en panne dans 8 mois. Votre client a la responsabilité d'évaluer ces risques et d'en accepter les conséquences.

La seule chose que vous ne voulez pas faire est de dire au client de penser qu'il a un logiciel magnifiquement conçu, alors qu'il n'a payé (et reçu) qu'un morceau indésirable non testé. Si quelque chose ne va pas (ce qui arrivera probablement), dans le premier scénario, ils auront l'air mauvais, mais dans le second scénario, vous aurez l'air mauvais.

Ce n'est jamais correct, mais il faut parfois faire des compromis pour terminer un projet. La triste réalité est que la plupart des hommes d'affaires sont complètement ignorants et sont plus que disposés à sacrifier la maintenabilité plus tard pour quelque chose en ce moment. L'astuce consiste à savoir comment trouver un équilibre; peut-être que le projet ne sera pas aussi soigné qu'il pourrait l'être, mais tant qu'il ne s'agit pas d'un porcherie, c'est un compromis valable.

Cela dépend entièrement de la question "Est-ce que vous ou quelqu'un d'autre voudrez éventuellement le modifier plus tard?" Si oui, vous devriez essayer d'avoir un design "soigné", sinon vous risquez de devoir tout jeter et recommencer 6 mois plus tard.

Bien sûr, vous pouvez aller trop loin, mais généralement un peu de netteté vous fera économiser du travail plus tard.