Ohjelmistomaailman järjettömät lait

Oletko koskaan miettinyt, miksi älykkäät ihmiset, kuten ohjelmistokehittäjät, sekoittavat sen niin usein? On ihmisiä, jotka tekivät. Tässä viestissä tarkastelemme joitain kirjoittamattomia lakeja, jotka kuvaavat ammattilaisten käyttäytymistä laskennasta.

Ensimmäinen tietokoneeni oli Commodore 64. Lähes 30 kt RAM-muistia oli järjestelmää varten, joten 32 kt jäi tekstinkäsittelyyn, pelaamiseen, perheyritysten kirjanpitoon ja melkein kaikkeen mitä teen omistamallani 6 gigatavun tietokoneella. Tämä jättää kysymyksen avoimeksi Vastaavatko nykyiset laitteet ohjelmistojen tarpeita vai käyttääkö ohjelmisto enemmän laitteistoresursseja, koska niitä on saatavilla?

Oikeudenmukaisesti, pelit eivät ole samat, grafiikka ei ole samaa laatua, ja elokuvien katselu ja musiikin kuuntelu olisi ollut mahdotonta. Ei voida kuitenkaan ajatella sitä on ohjelmia, jotka julkaisevat versioita ja kuluttavat yhä enemmän resursseja tuottamatta mitään uutta.

Tässä ovat syyt.

Zawinskyn laki

Netscape-kehittäjä Jamie Zawinsky väitti sen Jokainen ohjelma sisältää ominaisuuksia, kunnes se pystyy lukemaan sähköposteja. Jos hän ei onnistu, hänet korvataan toisella, joka pystyy siihen.

Kun hän sanoi sen, vitsi oli, että hän viittasi ohjelmiin, joita ei alun perin ollut tarkoitettu sähköpostiohjelmiksi. Se ei enää ollut hauska, kun havaittiin, että monet Google Play -sovellukset pyysivät lupaa käyttää puhelimen komponentteja ja käyttäjätietoja, joita heidän ei tarvinnut tehdä työnsä.

Jotkut tulkitsivat tämän osana yrityksiä vakoilla käyttäjiä. Mutta luultavasti ihmisluonto on tehdä jotain yksinkertaisesti siksi, että se voidaan tehdä.

Peterin periaatetta sovellettiin ohjelmistoihin

Lawrence Peter tuli tunnetuksi toteamalla, että hierarkiassa henkilö nousee asemaan, johon hän on erittäin epäpätevä. Mutta hänellä oli myös aikaa sanoa jotain monimutkaisista projekteista:

"Monimutkaisesta projektista tulee liian monimutkainen, jotta edes sen omat kehittäjät eivät ymmärtäisi sitä."

Vähiten hämmästynyt periaate

Tämä periaate, joka julkaistiin IBM Systems Journal -lehdessä vuonna 1984, sanoo:

"Jos vaadittu ominaisuus aiheuttaa suuren yllätyksen, ominaisuus on ehkä uudistettava."

Toisin sanoen jos osa ohjelmistosta tai kokonaan poikkeaa huomattavasti siitä, mihin käyttäjä oli tottunut, paras on uudelleensuunnittelu. Ihannetapauksessa pyrittävä saavuttamaan asteittaiset parannukset, jotka ovat riittävän suuria ollakseen vaikuttavia, mutta riittävän pieniä pysyäkseen tuttuina käyttäjälle.

Harmi, että Shuttleworth ei ottanut sitä huomioon aloittaessaan Unityn.

Kyberneettisen entomologian laki

Ensimmäinen vika tietokonehistoriassa oli todellinen. Koi lensi yhteen MARK II -tietokoneen releistä aiheuttaen toimintahäiriön.

Metaforaa jatkaen kyberneettisen entomologian laki pitää sitä aina tulee vielä yksi vika.

Se on asia, jonka kaikki tietokoneen käyttäjät tietävät. Riippumatta siitä, kuinka paljon käyttöjärjestelmää testataan, vika havaitaan aina, kun on liian myöhäistä.

Kernighanin laki

Linux Adictos on asennettu laajennus varmistaaksemme, että me kirjoittajat kirjoitamme hakukoneystävällisellä tavalla. Vihasin sitä ensimmäisestä päivästä lähtien. Kaikki yritykset kirjoittaa hieman kirjallisella lennolla tuomitaan välittömästi punaisella ympyrällä. Ajan myötä totuin siihen ja joudun harvoin tekemään korjauksia.

Sama tapahtuu ohjelmoijille, monta kertaa he ovat kiinnostuneempia osoittamaan kykynsä koodata kuin kirjoittamalla yksinkertaisempaa koodia, joka on helpompi ymmärtää ja ylläpitää.

Siksi Kernighanin laki toteaa:

Virheenkorjaus on kaksi kertaa niin vaikeaa kuin koodin kirjoittaminen. Joten jos kirjoitat koodin mahdollisimman fiksusti, et ole määritelmän mukaan tarpeeksi fiksu virheenkorjausta varten. '

90/90 sääntö

Jokainen, joka on aloittanut voittoa tavoittavan projektin tosielämässä, tietää, että jokainen projekti kestää kaksi kertaa niin kauan ja maksaa kaksi kertaa niin paljon kuin budjetoitu, jotta saadaan puolet odotetusta voitosta.

Tietokonemaailmassa on tämän lain muunnelmat. Esimerkiksi yksi Tom Cargill sanoi:

"Koodin ensimmäiset 90 prosenttia edustavat ensimmäisiä 90 prosenttia kehitysajasta. Loput 10 prosenttia koodista edustavat 90 muuta kehitysaikaa. "

Eikö se ollut selvää? Ehkä Hofstadterin laki auttaa:

"Se kestää aina kauemmin kuin odotat, jopa Hofstadterin lakia ajatellen."

Luulen, että Ubuntun ja Fedoran kehittäjien on tiedettävä. Tai ainakin muistaa se 6 kuukauden välein.

Brookin laki

Avoimen lähdekoodin ohjelmistoprojekteilla on usein kaksi ongelmaa; rahoitus ja yhteistyökumppaneiden puute. Ellei toinen ole ongelma. Brookin mukaan:

"Työvoiman lisääminen aikataulun jälkeen olevaan ohjelmistoprojektiin viivästyttää sitä edelleen."

Ymmärrettävästi sinun ei tarvitse vain päivittää uusia koodereita. Lisää on dokumentoitava, kaikkien byrokratiaa tarvitaan enemmän pitämään kaikki synkronoituna, ja todennäköisesti tulee olemaan taisteluja.

Ja tietysti emme voi unohtaa ystävä Parkinsonin ja hänen väitettään siitä Ei ole väliä kuinka paljon tyhjää tilaa aloitat. Tarvitset aina enemmän. Hän viittasi toimistotilaan, mutta sama koskee RAM-muistia ja levytilaa.