On Management and the Maginot Line

Linjajohtajien Maginot-linja

Byrokraattisesta johtamisesta puhuttaessa käytettän usein termejä linjajohto ja linjajohtajat. - Jopi.

The original Cathedral and Bazaar paper of 1997 ended with the vision above—that of happy networked hordes of programmer/anarchists outcompeting and overwhelming the hierarchical world of conventional closed software.

Alkuperäinen, vuonna 1997 julkaistu Katedraali ja basaari päättyi edellisessä luvussa esitettyyn visioon onnellisina uurastavista, verkottuneista ohjelmoijien/anarkistien massoista, jotka hyökyisivät tavanomaisen suljetun, hierarkkisesti johdetun ohjelmistotyön rinnalle ja ohi.

A good many skeptics weren't convinced, however; and the questions they raise deserve a fair engagement. Most of the objections to the bazaar argument come down to the claim that its proponents have underestimated the productivity-multiplying effect of conventional management.

Kuitenkin jäi vielä koko joukko epäileviä Tuomaita, ja heidän esiin nostamansa kysymykset ansaitsevat tasapuolisen käsittelyn. Suurin osa basaarimallia kohdistuvista epäilyistä voidaan tiivistää väitteeseen, jonka mukaan mallin kannattajat aliarvioivat tavanomaisen työnjohdon tuottavuutta moninkertaistavaa vaikutusta.

Epäilevä tuomas on niin hyvä ilmaisu, että se poistaa tarpeen sivulauseelta 'joita ei saatu vakuuttuneiksi'. Sivulause vain toistaisi sen mitä ET tarkoittaa. - Jopi

"Epäilevä tuomas" gemenalla

Traditionally-minded software-development managers often object that the casualness with which project groups form and change and dissolve in the open-source world negates a significant part of the apparent advantage of numbers that the open-source community has over any single closed-source developer. They would observe that in software development it is really sustained effort over time and the degree to which customers can expect continuing investment in the product that matters, not just how many people have thrown a bone in the pot and left it to simmer.

Tavanomaiseen malliin pitäytyvät ohjelmistokehitystyön johtajat väittävät usein, että satunnaisuus, jolla avoimen lähdekoodin maailmassa työryhmiä muodostuu, muuttuu ja hajoaa, neutralisoi merkittävän osan siitä näennäisestä työryhmän kokoa koskevasta edusta, joka työtavalla on verrattuna yksittäiseen suljetun ohjelmiston kehittäjään. Heidän mukaansa ohjelmistokehityksessä on tärkeää, missä määrin projektiin käytetään aikaa ja vaivaa ja missä määrin asiakkaat voivat luottaa kehitystyön jatkumiseen. Ei ole paljoakaan väliä sillä, kuinka moni kokki on hämmentänyt soppaa.

-"Throw a bone in the pot and leave it to simmer" - rikka rokassa, korsi kekoon, lusikka soppaan -Neutraloi -> neutralisoida (näin omasta ja wiktionaryn mielestä: http://fi.wiktionary.org/wiki/Liite:Verbitaivutus/suomi/neutralisoida) -Eka virke vähän kökkö, mutta enpä keksi selkeämpääkään tapaa... Ehkä jakaminen kahteen virkkeeseen voisi toimia...

There is something to this argument, to be sure; in fact, I have developed the idea that expected future service value is the key to the economics of software production in the essay The Magic Cauldron.

Onhan asiassa jotain perääkin. Kirjoituksessani The Magic Cauldron ('taikapata') kehittelin ajatusta, jonka mukaan ohjelmiston arvo riippuu sen tuottamien palvelujen arvosta.

"The Magic Cauldron" - 'taikapata', ei varmaankaan suomennettu, joten käytetään alkuperäistä nimeä, mutta sulkeissa käännös; "Key to the economics" - avain kassalippaaseen, otin kääntäjän vapauden

But this argument also has a major hidden problem; its implicit assumption that open-source development cannot deliver such sustained effort. In fact, there have been open-source projects that maintained a coherent direction and an effective maintainer community over quite long periods of time without the kinds of incentive structures or institutional controls that conventional management finds essential. The development of the GNU Emacs editor is an extreme and instructive example; it has absorbed the efforts of hundreds of contributors over 15 years into a unified architectural vision, despite high turnover and the fact that only one person (its author) has been continuously active during all that time. No closed-source editor has ever matched this longevity record.

Esitetyssä väitteessä on muuan suuri ongelma. Se nojautuu oletukseen, jonka mukaan avoimeen lähdekoodiin perustuvassa kehitystyössä ei pystytä pitkäjänteisyyteen. Kuitenkin on ollut avoimia hankkeita, joissa on edetty pitkiä aikoja johdonmukaisesti ja säilytetty ylläpitäjäyhteisön tuotteliaisuus ilman sellaisia palkitsemisjärjestelmiä ja valvontamekanismeja, joita pidetään tavanomaisessa johtamistyössä välttämättöminä. Ääriesimerkki on GNU Emacs -editori. Sen kehittämiseen on osallistunut yli 15 vuoden aikana satoja ihmisiä. Yhtenäinen näkemys ohjelman rakenteesta on säilynyt, vaikka kehittäjien vaihtuvuus on ollut suurta, ja vaikka vain yksi henkilö, hankkeen alullepanija, on ollut mukana alusta pitäen. Minkään suljettuun lähdekoodiin perustuvan editorin kehitystyössä ei ole päästy läheskään samanlaiseen pitkäjänteisyyteen.

15 vuotta, vuonna 2000!

This suggests a reason for questioning the advantages of conventionally-managed software development that is independent of the rest of the arguments over cathedral vs. bazaar mode. If it's possible for GNU Emacs to express a consistent architectural vision over 15 years, or for an operating system like Linux to do the same over 8 years of rapidly changing hardware and platform technology; and if (as is indeed the case) there have been many well-architected open-source projects of more than 5 years duration -- then we are entitled to wonder what, if anything, the tremendous overhead of conventionally-managed development is actually buying us.

Syntyykin peruste kyseenalaistaa tavalliseen tapaan johdetun ohjelmistokehityksen etuja. Tämä peruste ei liity aiemmin käsiteltyihin katedraali- ja basaarimallin eroihin. Kysymys kuuluu, mitä vastiketta saadaan suunnattomille yleiskuluille, joita liittyy ohjelmistokehityksen tavanomaiseen johtamistyyliin. Onhan GNU Emacsin kehitystyössä pystytty ylläpitämään johdonmukaista visiota 15 vuoden ajan, ja Linuxin kehittämisessä 8 vuotta huolimatta laitteiden ja alustojen nopeasta muutostilasta. Lisäksi (kirjoitusajankohtaan, vuoteen 2000 mennessä) on toteutettu monia muita yli viisi vuotta kestäneitä, hyvin suunniteltuja avoimen lähdekoodin projekteja.

hardware and platform = laitteet ja alustat, toimiiko?

- Lisäsin sulkuihin muistutuksen siitä, että kirjoittaja elää vuotta 2000. Voiko sulut muuttaa hakasuluiksi? -Jopi

Sanoisin, että hakasulut on varattu viitteitä. Sellainen sivun alareunaan tuleva huomautus olisi hauska, siis Latex-formaatissa sanottuna footnote. -AR

Whatever it is certainly doesn't include reliable execution by deadline, or on budget, or to all features of the specification; it's a rare `managed' project that meets even one of these goals, let alone all three. It also does not appear to be ability to adapt to changes in technology and economic context during the project lifetime, either; the open-source community has proven far more effective on that score (as one can readily verify, for example, by comparing the 30-year history of the Internet with the short half-lives of proprietary networking technologies—or the cost of the 16-bit to 32-bit transition in Microsoft Windows with the nearly effortless upward migration of Linux during the same period, not only along the Intel line of development but to more than a dozen other hardware platforms, including the 64-bit Alpha as well).

Yleiskuluja vastaan saatu vastike ei takuulla koske asetetuissa aikarajoissa tai budjetissa pysymistä eikä kaikkien luvattujen ominaisuuksien toteuttamista. Vain harva 'manageroitu' projekti saavuttaa edes yhden näistä tavoitteista, saati sitten kaikki kolme. Kyseeseen ei tule myöskään mukautuminen projektin aikana tapahtuviin tekniikan ja talouden muutoksiin. Internet on 30-vuotisen historiansa aikana osoittautunut sopeutumiskykyisemmäksi kuin suljetut verkkoratkaisut. Microsoftille Windows-käyttöjärjestelmän siirtäminen 16-bittisestä 32-bittiseen muotoon tuli kalliiksi, kun taas Linuxilta se sujui helposti. Linuxista muokattiin vielä versiot, jotka toimivat Intel-prosessorien lisäksi muilla alustoilla, kuten 64-bittisessä Alpha-prosessorissa.

One thing many people think the traditional mode buys you is somebody to hold legally liable and potentially recover compensation from if the project goes wrong. But this is an illusion; most software licenses are written to disclaim even warranty of merchantability, let alone performance—and cases of successful recovery for software nonperformance are vanishingly rare. Even if they were common, feeling comforted by having somebody to sue would be missing the point. You didn't want to be in a lawsuit; you wanted working software.

Yleiskuluista saa vastiketta sikäli, että tavanomaisessa kehitysmallissa tietää, kenet voi haastaa käräjille korvausten saamiseksi, jos hanke menee metsään. Tämäkin ilo on kuitenkin pelkkää harhaa. Useimmat ohjelmistolisenssit on laadittu niin, että ne torjuvat kaiken vastuun mahdollisista ongelmista tai haitoista. Vielä vaikeampaa on saada korvausta ohjelmiston heikosta toiminnasta. Vaikka korvauksia saisi useamminkin, oikeusjutusta saatu tyydytys ei paljoa lämmittäisi. Tarkoitus on saada toimiva ohjelmisto, ei päästä käräjöimään.

So what is all that management overhead buying?

Mitä liikkeenjohdon menoerillä sitten oikein saa?

Mielestäni managementilla viitataan projektijohtamiseen eikä liikkeenjohtamiseen. Eli parempi käännös voisi olla: "Mitä projektijohtamisen kustannusten vastineeksi saadaan?" -TV -Kulungit -> menoerät ehkä neutraalimpi

In order to understand that, we need to understand what software development managers believe they do. A woman I know who seems to be very good at this job says software project management has five functions:

Tämän ymmärtämiseksi kannattaa muodostaa käsitys siitä, mitä ohjelmistokehitysjohtajat luulevat tekevänsä. Eräs naispuolinen tuttavani, joka tuntuu olevan erittäin pätevä työssään, sanoo että ohjelmistoprojektien johdolla on viisi tehtävää:

Edellisestä käännösversiosta oli jätetty viittaus tuttavan sukupuoleen pois, mutta se kannattaa säilyttää, jotta emme epähuomiossa muodostaisi sellaista mielikuvaa, että ohjelmointi on vain miesten alaa. - Jopi

To define goals and keep everybody pointed in the same direction
To monitor and make sure crucial details don't get skipped
To motivate people to do boring but necessary drudgework
To organize the deployment of people for best productivity
To marshal resources needed to sustain the project

Määritellä tavoitteet ja ohjata jokaista etenemään samaan suuntaan
Valvoa ja varmistaa, että elintärkeitä seikkoja ei sivuuteta
Motivoida työntekijöitä tekemään nekin työt, jotka ovat ikäviä mutta välttämättömiä
Järjestää työt niin, että työn tuottavuus on paras mahdollinen
Hankkia projektissa tarvittavat resurssit

Apparently worthy goals, all of these; but under the open-source model, and in its surrounding social context, they can begin to seem strangely irrelevant. We'll take them in reverse order.

Kaikki vallan hienoja tavoitteita, mutta avoimen lähdekoodin ja sen sosiaalisen ympäristön näkökulmasta ne vaikuttavat oudon asiaankuulumattomilta. Laitetaanpa ne käänteiseen järjestykseen.

"Context" - viitekehys

My friend reports that a lot of resource marshalling is basically defensive; once you have your people and machines and office space, you have to defend them from peer managers competing for the same resources, and from higher-ups trying to allocate the most efficient use of a limited pool.

Ystäväni mukaan suuri osa resursseihin liittyvästä johtamistyöstä onkin niiden puolustamista. Jos projektilla on tarvittavat ihmiset, koneet ja työtilat, niitä joutuu suojelemaan muilta johtajilta jotka kilpailevat samoista voimavaroista ja ylemmältä johdolta, joka voi koettaa saada rajallisesta työvoimasta mahdollisimman suuren tehon.

But open-source developers are volunteers, self-selected for both interest and ability to contribute to the projects they work on (and this remains generally true even when they are being paid a salary to hack open source.) The volunteer ethos tends to take care of the 'attack' side of resource-marshalling automatically; people bring their own resources to the table. And there is little or no need for a manager to 'play defense' in the conventional sense.

Sen sijaan avoimen lähdekoodin kehittäjät ovat vapaaehtoisia. He ovat itse valinneet tehtävän oman kiinnostuksensa nojalla otaksuen, että heillä on jotain annettavaa. Tämä asetelma pätee silloinkin, kun avoimen lähdekoodin ohjelmiston kehittämisestä maksetaan. Vapaaehtoisuuden eetos on omiaan huolehtimaan resurssien riittämisestä automaattisesti: vapaaehtoiset tuovat tarvittavat resurssit mukanaan. Kenenkään eri tarvitse 'puolustaa hankkeen resursseja'.

Anyway, in a world of cheap PCs and fast Internet links, we find pretty consistently that the only really limiting resource is skilled attention. Open-source projects, when they founder, essentially never do so for want of machines or links or office space; they die only when the developers themselves lose interest.

Joka tapauksessa halpojen tietokoneiden ja nopeiden internet-yhteyksien aikakaudella ainoa merkittävä resurssirajoitus on asiantuntijoiden aika. Avoimen lähdekoodin projektit tuskin koskaan kuivuvat kokoon koneiden, yhteyksien tai toimistotilan puuttumisen takia. Projektit kuihtuvat vain, jos kehittäjät menettävät mielenkiintonsa.

That being the case, it's doubly important that open-source hackers organize themselves for maximum productivity by self-selection—and the social milieu selects ruthlessly for competence. My friend, familiar with both the open-source world and large closed projects, believes that open source has been successful partly because its culture only accepts the most talented 5% or so of the programming population. She spends most of her time organizing the deployment of the other 95%, and has thus observed first-hand the well-known variance of a factor of one hundred in productivity between the most able programmers and the merely competent.

Onkin kaksinverroin tärkeää, että avoimen lähdekoodin ympäristössä kehittäjät organisoituvat itsestään mahdollisimman tuottavalla tavalla, koska heidän sosiaalinen ympäristönsä suosii pätevimpiä eikä tunne sääliä muita kohtaan. Tuttavani tuntee sekä avoimen lähdekoodin että suurten suljettujen ohjelmistoprojektien maailman. Hän on sitä mieltä, että avoimen lähdekoodin menestystä selittää osaksi sen kulttuurin vaativuus. Siinä ehkä vain lahjakkain 5 % ohjelmoijista saavuttaa hyväksynnän. Suurin osa tuttavani ajasta kuluu siihen, että hän koettaa ohjata työntekijöitä, jotka kuuluvat jäljelle jääneeseen 95 %:iin. Hän on kokenut omakohtaisesti, miten kaikkein kyvykkäimmät ohjelmoijat voivat tuottaa satakertaisesti sen, mihin sinänsä kelvolliset pystyvät.

"Variance of a factor of one hundred in productivity" - jonkun paremmin tietävän pitäisi kääntää tämä --onkohan tämä varmasti hyvin tunnettu asia? kellään linkkiä tms? vaikka alaviitteeksi selitystä, jos löytyy

Tässä 'variance' ei ole se, mitä tilastotieteessä sanotaan varianssiksi. Tässä 'variance' tarkoittaa yksinkertaisesti vaihteluväliä eli lyhyesti sanottuna erotusta. 'Factor' taas viittaa kertoimeen, joka tuottaa monikertoja. Englannin matematiikka ei ole ihan yksikäsitteistä puhekielessä. Kirjoittaja tulee ehkä liioitelleeksi, mutta meidän tehtävämme ei ole korjata asiaa. - Jopi

The size of that variance has always raised an awkward question: would individual projects, and the field as a whole, be better off without more than 50% of the least able in it? Thoughtful managers have understood for a long time that if conventional software management's only function were to convert the least able from a net loss to a marginal win, the game might not be worth the candle.

Tuottavuuden suuri vaihteluväli nostamaan aina esille kiusallisen kysymyksen. Olisiko yksittäisten projektien ja koko alan kannalta parempi, jos yli puolet heikoimmista jätettäisiin hankkeiden ulkopuolelle? Harkintakykyiset linjajohtajat ovat ymmärtäneet jo pitkään, että tavanomainen ohjelmistotyön johtaminen ei ole kannattavaa, jos sen ainoa tarkoitus on, että tappiota tuottaneet heikoimmat työntekijät saadaan tuottamaan nippa nappa positiivista tulosta.

pitäskö olla subjekti tohon kädettömimmät? ja onko liian karusti sanottu?

The success of the open-source community sharpens this question considerably, by providing hard evidence that it is often cheaper and more effective to recruit self-selected volunteers from the Internet than it is to manage buildings full of people who would rather be doing something else.

Avoimen lähdekoodin yhteisön onnistumiset ovat kärjistänyt kysymyksenasettelua. Ne ovat osoittaneet konkreettisesti, että usein on halvempaa ja tehokkaampaa ottaa työhön siihen omatoimisesti suuntautuneita vapaaehtoisia internetistä kuin hallinnoida rakennuksia, jotka ovat täynnään väkeä joka tekisi mieluummin jotain muuta.

Which brings us neatly to the question of motivation. An equivalent and often-heard way to state my friend's point is that traditional development management is a necessary compensation for poorly motivated programmers who would not otherwise turn out good work.

Tästä pääsemmekin sopivasti kysymykseen motivoinnista. Ystäväni näkökanta on usein esitetty niin, että perinteistä kehitystyön johtamista tarvitaan, koska heikosti motivoituneet ohjelmoijat eivät muuten tekisi hyvää työtä.

This answer usually travels with a claim that the open-source community can only be relied on only to do work that is `sexy' or technically sweet; anything else will be left undone (or done only poorly) unless it's churned out by money-motivated cubicle peons with managers cracking whips over them. I address the psychological and social reasons for being skeptical of this claim in Homesteading the Noosphere. For present purposes, however, I think it's more interesting to point out the implications of accepting it as true.

Tähän käsitykseen liittyy yleensä väite, jonka mukaan avoimen lähdekoodin yhteisöön voi luottaa vain, kun tehdään työtä, joka on 'seksikästä' tai joka tarjoaa mukavia teknisiä haasteita. Muunlaiset työt jäävät tekemättä tai tehdään vasemmalla kädellä. Niiden hoitamiseen on käytettävä työpisteisiinsä rahan voimalla aidattuja musikoita, joiden pään päällä viuhuu työnjohtajan ruoska. Kirjoituksessani Homesteading the Noosphere ('Uudisraivausta ajatuskehällä') olen pohtinut psykologisia ja sosiaalisia syitä, joiden perusteella väitteeseen voi suhtautua epäillen.

Homesteading the Noosphere - onkohan suomennettu?

Ks. http://en.wikipedia.org/wiki/Noosphere. Musikka = karjalainen tai venäläinen maajussi. - Jopi.

--vois ainakin sulkeissa laittaa vapaasti suomennetun nimen

If the conventional, closed-source, heavily-managed style of software development is really defended only by a sort of Maginot Line of problems conducive to boredom, then it's going to remain viable in each individual application area for only so long as nobody finds those problems really interesting and nobody else finds any way to route around them. Because the moment there is open-source competition for a `boring' piece of software, customers are going to know that it was finally tackled by someone who chose that problem to solve because of a fascination with the problem itself—which, in software as in other kinds of creative work, is a far more effective motivator than money alone.

Jos tavanomaista, raskaita hallintokuluja aiheuttavaa ohjelmistokehityksen johtamistapaa voidaan perustella vain sellaisella Maginot-linjalla, jonka mukaan työ on ikävystyttävää, silloin perustelu pätee kussakin tehtävässä vain niin kauan, kunnes joku huomaa tehtävään liittyvien ongelmien olevan todella kiinnostavia tai kunnes ne voidaan kiertää. Kun jollekin 'tylsälle' ohjelmanpätkälle valmistuu avoimeen lähdekoodiin perustuva vaihtoehto, käyttäjät tietävät, että työhön on tarttunut joku joka päätti ratkaista siihen kuuluvat ongelmat pelkästään sen takia, että ne alkoivat kiehtoa häntä. Ohjelmistokehityksessä, kuten missä tahansa muussa luovassa työssä kiinnostus on paljon tehokkaampi motivaattori kuin raha.

Having a conventional management structure solely in order to motivate, then, is probably good tactics but bad strategy; a short-term win, but in the longer term a surer loss.

Tavanomaisen johtamisrakenteen ylläpitäminen vain työntekijöiden motivoimiseksi voi olla hyvää taktiikkaa, mutta se on huono strategia. Se voi tuottaa lyhyellä aikavälillä voittoja, mutta lopulta tuloksena on tappio.

So far, conventional development management looks like a bad bet now against open source on two points (resource marshalling, organization), and like it's living on borrowed time with respect to a third (motivation). And the poor beleaguered conventional manager is not going to get any succour from the monitoring issue; the strongest argument the open-source community has is that decentralized peer review trumps all the conventional methods for trying to ensure that details don't get slipped.

Nyt on siis nähty, että tavanomainen kehitystyön johtaminen on avoimeen malliin verrattuna huono vaihtoehto kahden vertailukohdan osalta (resurssien hankinta ja työn organisointi). Motivaation osalta se näyttää kärsivän vääjäämättömän tappion ajan myötä. Eivätkä työnjohtaja-rukkaa paljoa rohkaise työnvalvonnankaan näköalat. Avoimen lähdekoodin yhteisön vahvin valttikortti on sen suorittama hajautunut vertaisarviointi. Se päihittää kaikki muut keinot, joilla koetetaan varmistaa, että työn jälki on hyvää yksityiskohtia myöten.

Can we save defining goals as a justification for the overhead of conventional software project management? Perhaps; but to do so, we'll need good reason to believe that management committees and corporate roadmaps are more successful at defining worthy and widely shared goals than the project leaders and tribal elders who fill the analogous role in the open-source world.

Voiko yleiskuluja sitten perustella tavoitteiden määrittelyyn liittyvillä näkökohdilla? Ehkäpä, mutta silloin on oltava hyvät perusteet uskoa, että johtoryhmät ja yritysten kehittämissuunnitelmat onnistuvat määrittelemään arvokkaita ja yleisesti hyväksyttyjä tavoitteita paremmin kuin avoimen lähdekoodin yhteisössä toimivat projektinvetäjät ja kokeneet asiantuntijat.

"Tribal elders" - tribaalivanhimmat; tarvitaan jokin "heimoille" luontainen nimike; kylänvanhin? heimonvanhin?

That is on the face of it a pretty hard case to make. And it's not so much the open-source side of the balance (the longevity of Emacs, or Linus Torvalds's ability to mobilize hordes of developers with talk of "world domination") that makes it tough. Rather, it's the demonstrated awfulness of conventional mechanisms for defining the goals of software projects.

Tällaista uskoa on vaikea perustella. Syynä ei ole niinkään avoimen puolen vahvuus (Emacs-kehityksen pitkäjänteisyys tai Linus Torvaldsin kyky mobilisoida joukkoja maailmanvalloitus-puheilla). Syynä on moneen kertaan nähty tavanomaisen johtamismallin kyvyttömyys määritellä ohjelmistohankkeiden tavoitteita.

One of the best-known folk theorems of software engineering is that 60% to 75% of conventional software projects either are never completed or are rejected by their intended users. If that range is anywhere near true (and I've never met a manager of any experience who disputes it) then more projects than not are being aimed at goals that are either (a) not realistically attainable, or (b) just plain wrong.

Ohjelmistokehityksen kansanviisautta on, että 60 % tai 75 % tavanomaisista ohjelmistohankkeista jätetään kesken tai joutuu tarkoitetun käyttäjäkuntansa hylkäämäksi. En ole tavannut ketään kokenutta alan johtajaa, joka kiistäisi tämän. Jos arvio on likimainkin oikea, silloin suurimmassa osassa projekteista tavoitteet määritellään joko epärealistisesti tai suorastaan väärin.

"Plain wrong" - käänsin pelkkää potaskaa

Hoidetaan non-breaking space vasta ladonta vaiheessa, jos nyt selain rivittää luvun ja prosenttimerkin eri riveille, niin ei haittaa. (tarkoitan siis tuota &nbsp)

This, more than any other problem, is the reason that in today's software engineering world the very phrase "management committee" is likely to send chills down the hearer's spine—even (or perhaps especially) if the hearer is a manager. The days when only programmers griped about this pattern are long past; Dilbert cartoons hang over executives' desks now.

Nykyään jo pelkkä sana 'projektin johtoryhmä' saa puistatuksen väreet kulkemaan pitkin kuulijan selkäpiitä, silloinkin jos (tai ehkä eritoten kun) kuulija toimii itse johtotehtävissä. Ne ajat ovat ohi, jolloin vain ohjelmoijat valittivat byrokratiasta; nykyään leikkeitä Dilbert-sarjakuvista löytää ylimmän liikkeenjohdonkin työhuoneiden seiniltä.

Our reply, then, to the traditional software development manager, is simple—if the open-source community has really underestimated the value of conventional management, why do so many of you display contempt for your own process?

Voime siis vastata tavanomaista mallia käyttävälle ohjelmistokehityksen johtajalle yksinkertaisesti, että jos avoimen lähdekoodin yhteisössä on todella aliarvioitu tavanomaisen johtamistyylin arvo, miksi niin monet teistä ovat tyytymättömiä omaa työtapaansa?

Once again the example of the open-source community sharpens this question considerably—because we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.

Avoimen lähdekoodin yhteisön antama esimerkki valaisee aihepiiriä. Meillähän on hauskaa työtä tehdessämme. Luova leikittelymme on tuottanut teknisiä, markkinaosuutena näkyviä ja psykologisia voittoja ällistyttävällä tahdilla. Olemme näyttäneet, että näin syntyy parempia ohjelmia ja että ilo on voimavara.

Two and a half years after the first version of this essay, the most radical thought I can offer to close with is no longer a vision of an open-source–dominated software world; that, after all, looks plausible to a lot of sober people in suits these days.

Nyt (vuonna 2000), kaksi ja puoli vuotta sen jälkeen, kun tämän kirjoituksen ensimmäinen versio valmistui, radikaalein mieleen tuleva päätöskommentti ei ole enää visio avoimen lähdekoodin maailmanherruudesta. Loppujen lopuksihan se vaikuttaa uskottavalta jo monien selväpäisten pukuherrojenkin mielestä.

Lisäsin taas sulkeisiin "vuonna 2000" jotta lukija ymmärtää, missä mennään. Saako sen hakasulkuihin? - Jopi

Rather, I want to suggest what may be a wider lesson about software, (and probably about every kind of creative or professional work). Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency.

Sen sijaan tässä voi piillä laajempi opetus. Ohjelmistokehityksessä ja ehkä kaikessa luovassa tai ammattitaitoa vaativassa työssä ihmisiä viehättävät optimaaliset haasteet. Tehtävät eivät saa olla niin helppoja, että ne tuntuisivat tylsiltä, eivätkä liian vaikeita suorittaa. Ohjelmoija on tyytyväinen silloin, kun hänen kykynsä eivät jää käyttämättä ja kun häntä eivät paina huonosti määritellyt tavoitteet tai työilmapiirin aiheuttama stressi. Nautinto ennakoi tehokkuutta.

Relating to your own work process with fear and loathing (even in the displaced, ironic way suggested by hanging up Dilbert cartoons) should therefore be regarded in itself as a sign that the process has failed. Joy, humor, and playfulness are indeed assets; it was not mainly for the alliteration that I wrote of "happy hordes" above, and it is no mere joke that the Linux mascot is a cuddly, neotenous penguin.

Se että tuntee omassa työssään pelkoa ja inhoa on merkki työprosessin epäonnistumisesta - silloinkin kun kyseessä on vain Dilbert-sarjakuvien ripusteluna ilmenevä, ilmaisuaan hakeva ironia. Ilo, huumori ja leikkisyys ovat toden totta voimavaroja. Edellä en kirjoittanut sattumalta "onnellisina uurastavista massoista". Ei ole myöskään pelkkä vitsi, että Linuxin maskotti on pehmoinen, lapsekas pingviini.

Alkutekstissä puhutaan Dilbert-sarjakuvasta (Pentti Perusinsinööri) - vaihdoin suomalaista lukijaa puhuttelevampaan B. Virtaseen; "happy hordes" - laumat, parvet, joukot, massat

B.Virtanen on mukava! Kuitenkin Dilbert tunnetaan Suomessakin, ja kannattaa kääntää tarkasti, jos kerran aikoo kääntää. - Jopi.

It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work.

Avoin lähdekoodi opettaa, että leikki on taloudellisesti tehokkain tapa tehdä luovaa työtä. Tuo opetus voi osoittautua avoimen lähdekoodin menestyksen tärkeimmäksi vaikutukseksi.