Une Mission et une aventure : Les différences culturelles entre Micro et programmeurs Mainframe

Original: http://www.stevemcconnell.com/articles/art01.htm

Le nombre de gens qui écrivent des programmes pour micro-ordinateurs a explosé dans les cinq dernières années. Le U.S. Department of Labor rapporte moins de 1,5 millions de personnes travaillant dans divers travaux de programmation dans tous les environnements de programmation (DOL, 1990). Mais les chiffres de l’industrie des micro-ordinateurs suggèrent que beaucoup plus de gens que cela programmez micro-ordinateurs–Borland International pour instance a vendu plus de 2 millions d’exemplaires de Turbo Pascal pour le PC d’IBM (Kahn, 1989), et qui est produit qu’une seule langue d’une compagnie.

En dépit de la quantité d’activité dans les micro-ordinateurs, développement de logiciels de micro-ordinateur a largement été ignoré par la communauté de génie logiciel. Un rapide coup de œil à travers des articles récents dans IEEE Software et des Communications de l’ACM montre articles sur les systèmes embarqués, systèmes en temps réel, traitement parallèle, Ada, LISP et Unix, mais peu d’articles sur C, Basic, Microsoft Windows, Apple Macintosh ou autres sujets d’intérêt particulier pour les programmeurs qui travaillent sur les micros.

Auteurs qui ont été écrit sur le génie logiciel pour 10 ou 20 ans, ont ignoré jusqu’à présent les aspects uniques du développement de micro-ordinateur, diversement croyant que développement de micro-ordinateur n’est pas suffisante pour justifier l’apprentissage de la valeur, est inférieure au développement mainframe ou est simplement immatures et vont progressivement se transformer en un ensemble de pratiques analogues mainframe. Chacun de ces perceptions se trompe au moins partiellement. Micros ne sont pas juste une autre plate-forme plus faible. Ils représentent une programmation différente culture au total, celui qui est plus faible à certains égards et plus forts dans d’autres que celui qu’il remplace peu à peu. Toute personne souhaitant maîtriser les pratiques actuelles de l’informatiques a besoin d’arriver à une compréhension des approches de développement logiciel de micro-ordinateur.

 

Caractéristiques d’un Effort de développement de micro-ordinateur typique

Le processus de développement stéréotypées sur un micro se compose d’un seul développeur piratage à sa table de cuisine jusqu’aux petites heures du matin. Ses seuls compagnons sont quelques canettes de cola riches en caféine et une réserve inépuisable de génoise doré.

Dans le stéréotype, le programmeur a quelques notes de conception griffonnés sur une serviette en papier, mais il supporte le plus de la conception dans sa tête. Il n’a fait aucune étude formelle pour déterminer si son programme seront négociables ; son inspiration pour du programme fonctionnalités et une interface utilisateur provient de muses programmation privés. Lorsque le produit est complet, il ne passe pas par toute activité d’assurance de la qualité formelle, mais il libère immédiatement le logiciel d’achat public. Le résultat est un produit hâtivement conçu, écrit au hasard, sujette aux erreurs.

Ce stéréotype aurait pu être précis il y a 10 ans et quelque peu précis il y a 5 ans, mais des environnements de micro-ordinateur sont devenus suffisamment complexes pour que le produit développé par un programmeur seul piratage code est maintenant pratiquement obsolète. Le projet de développement plus typique comprend une équipe de programmeurs, et qui fait l’objet de cette discussion. Examinons les vraies différences entre les approches de développement micro-ordinateur et mainframe.

 

Différences dans les approches de développement

Les plus grandes différences entre les approches de développement mainframe et micrcomputer sont les suivantes :

Le programmeur de micro-ordinateur a une machine entièrement dédiée à son propre usage.

Le programmeur de micro-ordinateur préfère faire des erreurs et corrigez-les que d’aller à de gros efforts pour éviter les erreurs en premier lieu.
Puissance de prise de décision est poussé vers le bas au niveau du programmateur individuel.
Exactitude n’est pas la plus importante caractéristique de produit ; rapidité d’exécution est.
Le programmeur de micro-ordinateur typique est différent de son homologue de mainframe.

Les sous-sections suivantes discutent chacun de ces différences en détail. Mon point de vue provient de dépenser environ 80 pour cent de mon temps au cours des dix dernières années, travaillant dans des environnements de micro-ordinateur et environ 20 % travaillent dans des environnements mainframe.

 

Machine dédiée

Avoir une machine dédiée à un changement de programmeur unique plusieurs aspects du fonctionne d’un programmeur.

Quand une machine est dédiée à un programmeur individuel, le niveau de soutien du programmateur peut être grandement amélioré. L’environnement peut inclure un compilateur, débogueurs dédiés, des équipements de test automatisé et aide en ligne complet pour le langage de programmation et d’autres outils. Environnements de développement de micro-ordinateur sont hautement interactifs ; par exemple, dans même les pires environnements vous pouvez éditer, compiler, recherchez les erreurs et corriger les erreurs dans un programme sans quitter le programme éditeur. Ce niveau de compatibilité est beaucoup moins fréquente sur les ordinateurs centraux.

Les compilateurs de micro-ordinateur ont tendance à avoir des délais d’exécution plus rapides. Dans un ordinateur central environnement un revirement de 15 minutes est relativement rapide. Il est plus efficace pour un programmeur vérifier les erreurs de syntaxe ou de petites erreurs de logiques qu’il est pour le compilateur de le faire de temps. Sur un micro-ordinateur avec retournement quasi instantanée, il est souvent plus efficace d’avoir le compilateur de vérifier un programme pour les erreurs de syntaxe, des variables non déclarées et ordre des arguments dans les appels de la sous-routine que c’est à vérifier manuellement les mêmes informations de temps.
Outils sur les micros ont tendance à être utilisé de manière différente. Débogueurs sont utilisés pour rechercher des erreurs comme ils le sont dans les environnements mainframe. Mais parce qu’ils sont hautement interactif et hautement symbolique, ils sont aussi communément utilisés comme outils de code-inspection automatisée. Après un développeur compile son code, he parcourt le code ligne par ligne dans le débogueur pour vérifier qu’il fait ce qu’il a conçu, qu’il fasse. Si vous pensez que vos pairs peuvent être objectif sur les erreurs lors d’une inspection de code, essayez votre ordinateur ! À l’extrême droite de l’attitude des mainframes, Harlan Mills affirme que « un débogueur interactif est un exemple exceptionnel de ce qui n’est pas nécessaire » (Mills, 1986). Il ne semble pas connaître l’efficacité des utilisations comme ça. Je ne veux pas faire ressortir ici Mills ; ses sentiments ont été repris par beaucoup de gens éminents en génie logiciel, et je suis généralement l’un de ses plus grands fans. Mais ce n’est pas du tout clair pour moi que les software engineers qui critiquent certains aspects des pratiques de développement pour le devel micro-ordinateur sont pleinement conscients de ce qu’ils critiquent.
Un autre effet de l’augmentation du montant de la prise en charge matérielle donnée un programmeur de micro-ordinateur, c’est que les activités de développement ne sont pas divisées aussi soigneusement car ils sont sur de nombreux projets de mainframe. Par exemple, les projets de développement mainframe créent souvent une distinction entre « codage » et « tests d’unités. » L’étape de codage est considéré comme être complète lorsque le programmeur a fini de taper le code dans l’ordinateur–avant même compilation. Un programmeur mains à ce moment-là le code à un testeur pour la compilation indépendante, tests et intégration. Dans la plupart des magasins micro, l’idée du retournement le code d’intégration sans la première compilation, exercice et de le tester soigneusement obtiendrait un accueil extrêmement froid. Chaque programmeur a un ensemble plus vaste des responsabilités pour le code qu’il crée.
Une différence globale entre les deux environnements est la mesure à laquelle ils soutiennent l’apprentissage sur la programmation. Le simple fait qu’un programmeur peut compiler un programme, exécutez-le et voir les résultats au sein de secondes plutôt qu’en heures fait une grande différence en comment et en combien de temps un programmeur apprend sur la programmation. Les gens apprennent à travers les réactions, et micros améliorent la qualité et la quantité de la rétroaction qui reçoivent des programmeurs sur leurs programmes.
Différence entre éviter et corriger les erreurs
Certaines des différences entre les deux cultures se posent car une culture préconise en évitant les erreurs et les autres partisans y remédier. Années d’expérience ont appris programmeurs mainframe qu’il est préférable d’investir du temps pour éviter les erreurs qu’afin de perdre du temps, leur fixation par la suite. Harlan Mills fait valoir que les approches de développement rigoureux sont nécessaires parce qu’autrement les programmeurs peuvent dépenser 50 pour cent ou plus de leur temps de débogage (Mills 1983). Mills a fait cette déclaration claire de l’objection traditionnelle à l’approche de fix-it-plus tard :
Débogage non seulement preuve d’un manque de concentration et d’intégrité de la conception, mais est également un grand frein à la productivité. Si quelqu’un écrit une centaine de lignes de code en une seule journée et prend ensuite deux semaines pour l’obtenir débogué, ils ont vraiment seulement écrit une dizaine de lignes par jour (Mills, 1983).
Le point de vue de micro-ordinateur typique est différent. Expérience sur les micros a enseigné beaucoup de programmeurs qu’il vaut mieux prendre le temps de corriger les erreurs que c’est de perdre du temps à une surcharge initiaux qui souvent ne paie pas au large à long terme. Le désir d’éviter beaucoup de temps de débogage sur les mainframes découle d’un raisonnement valide dans cet environnement, mais cela dépend de l’existence de bogues qui prendre des jours pour trouver. Avec les débogueurs hautement interactif d’aujourd’hui, c’est un bug rare qui échappe à un programmeur expérimenté pendant plus d’une heure. La notion que la peine de travail pauvre est dépenser 50 % d’un projet débogage rarement s’applique aux micros. Lorsque vous vous rendez compte que la peine est plus proche de 10 %, les échelles astuce de faire les choses la première fois vers se fait avec le minimum fixe de frais généraux et une quantité modeste de débogage.
Cela ne signifie pas que les activités en amont de l’analyse des besoins et de conception architecturale sont moins importantes sur les micros que sur les mainframes. Elle n’implique pas que le pay-off de bas niveau activités d’assurance de la qualité telles que les revues de conception détaillée et les révisions de code n’est pas aussi grand dans le micro-ordinateur comme dans les environnements mainframe.
Autonomisation de l’individu
Micro-ordinateurs sont plus distribués que les mainframes, et magasins de micro-ordinateur sont plus susceptibles de distribuer le pouvoir décisionnel trop. Ils le pousser vers le bas pour les gens qui ont à vivre avec et à appliquer les décisions. (La tradition de comparer l’organisation informatique-système d’organisation de gestion remonte à quelques années–au moins au Design structuré Yourdon et de Constantin (1979). Il est intéressant d’observer que la programmation orientée objet–dans laquelle le contrôle est relativement décentralisé–a atteint sa majorité en même temps qu’informatique décentralisée et les structures décentralisées de gestion humaine.)
Peut-être la meilleure illustration de la différence entre les approches de développement micro et mainframe–dans la perspective de micro-ordinateur–vient de la relation entre Microsoft et IBM. IBM représente l’epitomy de l’approche de l’ordinateur central, Microsoft l’approche micro. Les deux sociétés avaient un choc significatif des personnalités entreprises dans leur développement commun d’OS/2. Après que les compagnies se sont séparés, cette histoire distribué chez Microsoft :
Microsoft et IBM ont été dans une course de bateau avec neuf personnes dans chaque bateau. Microsoft avait huit personnes aviron et une personne de direction. IBM avait une personne aviron et huit personnes de direction. Après avoir perdu la course par une large marge, IBM a commandé une étude de 2 millions de dollars de trois mois, afin de déterminer comment ils pourraient gagner la prochaine course. Après l’extension de l’étude à six mois et de 5 millions de dollars, ils enfin est venu à une conclusion : la personne faisant l’aviron doit ramer plus difficile.
Bien que les programmeurs d’IBM probablement n’accepterait pas de la façon dont ils cette histoire caractérise leur développement efforst, l’histoire donne un aperçu de la façon dont les programmeurs de micro-ordinateur perçoivent mainframe pratiques de développement. Ma conjecture est que beaucoup d’ingénieurs logiciel mainframe gagneraient à se demandent régulièrement si la médecine de procédures et de normes qu’ils utilisent peut être pire que le mal, qu’il est destiné à guérir.
La différence de centralisation s’applique également aux clients du logiciel. De nombreux programmes de l’ordinateur central sont rédigés par un département de MIS pour un client interne. Le ministère MIS essaie de conserver autant de contrôle du système qu’il le peut : services de programmation, le code source, données de l’utilisateur et le matériel lui-même. Le ministère MIS est un fournisseur de source unique pour un auditoire captif unique. Micro-ordinateur programmes tendent à être écrites pour des clients externes. Plutôt que de conserver le contrôle intégral d’un système, la boutique de micro-ordinateur renonce à contrôle de programmation des services, les données de l’utilisateur et le matériel lui-même. Si un client n’aime pas un produit de micro-ordinateur, il achète un produit concurrent à la place. Il en résulte que micro-ordinateur développeurs sont obligés de se rapprocher de leur clientèle que les développeurs mainframe. Le résultat de se rapprocher de la clientèle, c’est que le développement a une autre série de priorités que tient souvent pour acquis dans un environnement mainframe.
Exactitude et l’actualité
De nombreux programmes de PC ne sont pas des critiques de la vie, et beaucoup d’utilisateurs préfère avoir le logiciel avec des bugs–bientôt–que n’ont ne pas le logiciel du tout. Le problème de développement primaire passe donc du “Comment nous développons un logiciel hautement fiable dans un laps de temps raisonnable” à « Comment rapidement développer un logiciel qui est raisonnablement fiable? »
Combien sont bons pratiques mainframe à répondre à la deuxième question ? Nous pouvons faire une évaluation approximative. Une limite inférieure pour un projet de petit logiciel est probablement d’environ 16 000 lignes de code (LOC). Selon le modèle COCOMO de Barry Boehm, un nominal, 16 000 projets de bio-mode LOC pourrait être dressée à LOC environ 350 par mois programmeur (Boehm, 1981). Câpres Jones avait déclaré, en 1977, que pour les projets d’au moins 16 000 lignes de code, la productivité varie vers le haut de 125 LOC par mois programmeur (Jones, 1977). Le meilleur chiffre de productivité mainframe que j’ai vu depuis un projet de salle blanche en moyenne 740 LOC par mois avec 3,3 défauts par KLOC lors de la certification test (Linger et Mills, 1988).
Produit efficace, opportun libère dans la productivité de nécessité du monde micro-ordinateur pas l’ordre de 125 à 740 LOC par mois, cependant, mais l’ordre de 1000 à 2000 LOC par mois. L’approche traditionnelle mainframe n’est aucune réponse à la question du développement rapide sur les micros. Les pratiques de productivité qui produisent 1500 lignes de code par mois sont une nécessité concurrentielle. Si ce niveau de productivité implique également des erreurs de 10 à 20 par KLOC au cours des essais de système, qu’il en soit ainsi. Dans le monde de micro-ordinateur, c’est un petit prix à payer pour atteindre le but le plus important de fournir aux clients les fonctionnalités que dont ils ont besoin au moment où qu’ils en ont besoin.
Programmeurs typiques
Le programmeur de micro-ordinateur typique a un profil différent de celui de son homologue de mainframe. Statistiquement, il est plus jeune, a un statut matrimonial différent et a moins d’années d’expérience. Microsoft Corporation, par exemple, environ la moitié des programmeurs sont entre les âges de 20 et 29, unique et dans un environnement de travail à temps plein pour la première fois. Chacun de ces facteurs fait une différence entre les programmeurs micro et mainframe.
L’écart en âge seul peut avoir d’effet significatif. Frank O’Grady a écrit un un article sensible appelé « A Rude Awakening » dans lequel il a identifié la différence d’âge comme l’un des trois principaux obstacles à l’évolution d’un ordinateur central pour un travail de micro (O’Grady 1990). Il dit :
Cette expérience est assez humiliant quand on a 22, être intimidé par leurs devanciers de hot-shot. “Ce que vous entendez, vous n’obtenez toujours pas elle ? Combien de fois je dois vous l’expliquer?” C’est tout à fait une autre affaire lorsque vous êtes 42, et vous êtes être honteux et humilié par 25-year-olds.
La différence d’âge et l’état matrimonial est liée à l’esprit élevé et entreprenantes de nombreuses boutiques de micro-ordinateur. O ‘ Grady a fait remarquer que la première chose qu’il a remarqué après que le passage à la boutique de micro-ordinateur que personne n’a jamais été rentra chez lui. C’est plus facile à faire si vous êtes 25 et unique que si vous êtes 45 et marié avec des enfants. Développement de logiciels pour beaucoup de programmeurs micro-ordinateur est une mission et une aventure. Pour les programmeurs mainframe c’est rarement plus qu’un métier, même si c’est un bon travail.
Le stéréotype des programmeurs de micro-ordinateur comme pirates contient également plus d’un grain de vérité. Parce que les employés sont plus jeunes et esprit d’entreprise est élevé, les programmeurs sont moins intéressés par des procédures formelles et plus intéressés aux résultats. Qui se traduit par des pratiques de développement plus risquées et plus agressive. Parce que les PDG des sociétés comme Microsoft, Borland, Aldus et (autrefois) Ashton-Tate ont été programmeurs eux-mêmes, qu’ils comprennent mieux le frisson de programmation ponctuelle ; Ce piratage a soutien échelons les plus élevés de l’industrie de micro-ordinateur.
Leçons apprises
Bon nombre des différences entre les styles de développement PC et mainframes sont accessoire pour les deux plates-formes et non fondamentale à un d’eux. Parce que les différences sont accessoires, programmeurs dans chaque environnement ont des chances d’apprendre des programmeurs dans l’autre.
La principale faille de programmeurs travaillant sur les micros, c’est qu’ils répètent toutes les erreurs de leurs prédécesseurs de mainframe. Les programmeurs de micro-ordinateur sont souvent pas au courant des pratiques qui ont été utilisés avec succès dans des environnements mainframe depuis 20 ans. En 1988, j’ai assisté à une discussion informelle qui comprenait des programmeurs travaillant sur la troisième version de Aldus PageMaker. Pour la troisième sortie, ils avaient engagé un consultant programmation-pratiques qui a recommandé une approche qui était nouveau pour eux : essayer de définir leurs besoins avant de codage et de test. Les programmeurs ont été très enthousiasmés par cette nouvelle idée.
Clairement, les programmeurs qui ne connaissent pas la définition des besoins ont quelque chose à apprendre sur le développement de logiciels. Mais un tel manque de connaissance n’est guère rare dans le monde de micro-ordinateur, et beaucoup d’un projet de grande micro-ordinateur a été réalisé sans les avantages du contrôle de code source, un processus de bonne conception, une stratégie d’assurance qualité ou même un calendrier officiel. Mais avant de vous rejeter l’approche plus décontractée de Aldus, se rendre compte qu’il l’a fait amener à la troisième version d’un produit très réussi, et c’est mieux que la plupart des entreprises. Le reste viendra avec le temps, selon les besoins, de la même manière, il l’a fait dans le monde du mainframe.
Programmeurs mainframe peuvent aussi apprendre quelques petites choses sur les pratiques de programmation. Ils peuvent apprendre à être plus critique de surcharge bureaucratiqueprocédures parfois délibérées, formelles ne sont pas le meilleur moyen d’atteindre les objectifs du projet. Ils peuvent apprendre de nouvelles techniques de programmation–à l’aide des débogueurs et autres outils efficacement. Elles peuvent insister pour que leurs fournisseurs de matériel et de logiciels fournissent des environnements de développement qui sont aussi puissants que ceux disponibles sur les micro-ordinateurs.
Surtout, les programmeurs mainframe peuvent réexaminer la croûte lourde d’hypothèses qui est devenu barnacled sur leurs habitudes et pratiques au cours des 20 dernières années. La plupart des hypothèses sont toujours légitimes, mais beaucoup ont été invalidés en changeant les technologies et techniques de l’amélioration du développement. Le succès des pratiques peu orthodoxes de micro-ordinateur-programmming sera peut-être l’épi qui aiguillons un tel réexamen.
En fin de compte, il n’importe pas qui est en avance et qui se cache derrière, à l’heure actuelle. La mesure à laquelle les programmeurs de ces deux environnements apprennent mutuellement déterminera qui se déplace en avant avec l’état de la technique à l’avenir et qui est reléguée au PAP même tas comme diagramme templates, cartes perforées et tampons de codage.
Références

Boehm 1981. Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, New Jersey: Prentice-Hall, Inc., 1981.

DOL 1990. U. S. Department of Labor. “The 1990-91 Job Outlook in Brief,” Occupational Outlook Quarterly, Spring 1990, Washington, D.C.: U.S. Government Printing Office.

Jones, T. Capers, 1977. “Program Quality and Programmer Productivity,” IBM Technical Report TR 02.764, January 1977, pp. 42-78.

Kahn 1989. Kahn, Phillippe. “Software Craftsmanship into the ’90s,” Programmer’s Update, vol. 7, no. 4A (July 1989), pp. 39-44.

Linger and Mills 1988. Linger, Richard W. and Harlan D. Mills. “A Case Study in Cleanroom Software Engineering: The IBM COBOL Structuring Facility,” Proceedings of the 12th Annual Computer Software and Applications Conference, Los Alamitos, Calif: IEEE CS Press, 1988.

Mills 1983. Mills, Harlan D. Software Productivity. Boston, Mass: Little, Brown, 1983.

Mills 1986. Mills, Harlan D. “Structured Programming: Retrospect and Prospect,” IEEE Software, November 1986, pp. 58-66.

O’Grady 1990. O’Grady, Frank. “A Rude Awakening: A Generation of Programmers Wants to Know–Is There Life After COBOL,” American Programmer, vol. 3, nos. 7-8 (July/August 1990), pp. 44-49.

Yourdon and Constantine 1979. Yourdon, Edward and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Englewood Cliffs, New Jersey: Yourdon Press, 1979.

 

A propos de l’auteur

Steve McConnell est un consultant indépendant de développement de logiciels et l’auteur du Code complet: A Practical Handbook of Software Construction, expected from Microsoft Press in early 1993.

Comments are closed.