Tick-the-Code - julkaisut
Happy Are The Software Engineers.. (artikkeli)
Ensimmäinen koskaan kirjoittamani julkaisu on nimeltään "Happy Are The Software Engineers.." ("Onnellisia ovat ohjelmistosuunnittelijat..") ja se ilmestyi Better Software-lehdessä joulukuussa 2006. Artikkeli kuvaa kaikessa lyhykäisyydessään, kuinka täydellinen keskittyminen voi luoda onnellisuuden tunteen, erityisesti jos tehtävä on mielekäs. Halusin osoittaa, että ohjelmistolaatutyö on mielekästä ja että Tick-the-Code -menetelmällä on mahdollista uppoutua täydelliseen keskittymisen tilaan.
Tiivistettynä: onnea on Tick-the-Code.
Tick-the-Code Inspection: Theory and Practice
Ensimmäinen tieteellinen artikkelini on nimeltään "Tick-the-Code Inspection: Theory and Practice" (Tick-the-Code -katselmointi: teoria ja käytäntö) ja se ilmestyi vertaistarkistetussa ASQ (American Society for Quality, Amerikan Laatuliitto) lehdessä nimeltä Software Quality Professional.
Kuten nimi kertoo, artikkelini paljastaa kaikki Tick-the-Code -menetelmän yksityiskohdat aina 24 koodaussääntöön asti. Artikkeli on kattavin kirjoitettu lähde Tick-the-Code -menetelmästä.
Tick-the-Code Inspection: Empirical Evidence (on Effectiveness)
Toinen tieteellinen artikkeli on nimeltään Tick-the-Code Inspection: Empirical Evidence (on Effectiveness) (Tick-the-Code -katselmointi: empiirisiä todisteita (tehokkuudesta)). Kirjoitettuani artikkelin esitin sen ensimmäisen kerran Pacific Northwest Software Quality Conference (PNSQC)-konferenssissa lokakuussa 2007, Portlandissa, Oregonin osavaltiossa, USA:ssa. Artikkeli esittelee Tick-the-Code-koulutuksista kerättyjä mittauksia (noin 50 koulutuksen yhteensä yli 300 osallistujaa osallistuivat tutkimukseen.) Tulokset ovat paljastavia. Artikkelin päähuomio on, että ohjelmistosuunnittelijat voisivat pitää koodinsa paljon yksinkertaisempana ja välttää tekemästä monia niistä virheistä, joista ohjelmistoprojektit ovat tulleet niin pahamaineisiksi.
Artikkelin lisäosassa on lista Tick-the-Code -menetelmän säännöistä artikkelin kirjoitushetkellä (kesä 2007).
Tick-the-Code - uusvanha tekniikka taistelussa bugeja vastaan
Pirkanmaan Tietojenkäsittely-yhdistys (Pitky ry) julkaisi artikkelini jäsenlehdessään Pitkyn Piiri 1/2008. Se on nimeltään "Tick-the-Code - uusvanha tekniikka taistelussa bugeja vastaan".
Tulossa
Tick-the-Code -katselmointi: kirja
Vuodesta 2006 olen kirjoittanut kirjaa Tick-the-Code -menetelmästä. Siitä tulee yksityiskohtaisin ja täydellisin lähde menetelmään. Olen jo luonnostellut lähes kaikki luvut. Joihinkin niistä olen jo saanut asiantuntijoilta palautetta, jonka olen ottanut huomioon. Olen lähestynyt muutamaa kustantajaa ja saanut lisää palautetta (en vielä hyväksyntää). O'Reilly-toimittaja Andy Oram mainitsi menetelmän Beautiful Code-kirjan blogissa, mikä aiheutti melkoisen ryntäyksen näillekin sivuille. Seuraavaksi täytyy saada syntymään asiasta kiinnostunut yhteisö ja lähestyä kustantajia uudestaan.
Ote kirjasta
Ote vaihtuu viikottain. Kukin ote on vielä luonnos ja voi muuttua ennen päätymistään kirjaan. Otteet ovat englanniksi.
Moving higher to a level, where lifeless, overly busy teams are managed as an organization, the effects of busyness appear differently. For quite awhile, the teams produce bad code before anybody on the organizational level notices. Because nobody is proud of their doings, the teams are trying to hide as best they can and nobody on the organizational level can react. At some point, however, possibly months down the line, somebody does notice. The backlog of errors has grown beyond reason. There is no way this can go on. "We probably should do a complete organizational makeover, but we shouldn't jeopardize the upcoming product releases. Let's just have the teams quickly fix more errors, so the products can get to market. After this critical phase we can do it right."
The high management decrees that the next incremental release is not allowed to have any new functionality in it, all changes need to be bug fixes. The teams get to work on this "quality release" and the high management is happy with the quickly decreasing number of errors in the error database. In effect, the productivity - addition of new functionality over time - goes to zero for the release for the complete organization. Nobody is producing anything new. Everybody is just catching-up on tasks that should have been finished already and were reported as done. Unfortunately, you cannot just "inject quality" into the system. Fixing most open errors temporarily clears the error database, but it doesn't solve the root cause behind the symptom. As the root cause remains unsolved, the teams and the individuals in the teams will go back to their old ways of working after this temporary focus on bug fixing. Sooner or later the cycle repeats.
The Vicious Circle of Busyness is an important concept in Chapter 3. "Root Causes". In this excerpt, we look at it from the highest possible point-of-view. Individuals and teams get caught up in the circle. When the contaminationn is widespread enough, organizations get caught up too. The situation isn't as hopeless as it sounds. If your organization is held hostage by the Vicious Circle of Busyness, i.e. the high management is pressing the panic button every now and then before reorganizing you, Tick-the-Code can help you. With it you don't need to skimp on quality to save time, with Tick-the-Code you'll be saving time while improving quality.
Olet nyt tässä:
Klikkaamalla sivustokarttaan.
Osanottajien sanomaa:
Klikkaamalla kurssitietoihin.
