Mieti vähän
5.2.2016
Nopeat ideat vs. Hyvät ideat
Luulen että olen löytänyt konstin, jolla erinomaiset ohjelmoijat erottaa muista.
Keino on varsin yksinkertainen:
Annetaan kandidaatille haastavahko ohjelmointitehtävä hallitsemallaan ohjelmointikielellä, mutta sellaisesta alueesta, josta hänellä ei ole aikaisempaa tuntemusta. Tehtävän saatuaan jokainen kokelas rupeaa miettimään ongelmaa ja jokainen keksii jonkinlaisen ratkaisun ennemmin tai myöhemmin. Sillä ei ole merkitystä kauanko ratkaisun keksimiseen menee.
Kirjoittaja: Jaakko Pääkkönen, Senior Software Engineer
Vasta sen jälkeen kun jokainen kandidaatti on löytänyt ensimmäisen ratkaisuehdotuksen, joko paperilla tai omassa päässään, alkavat seuloontua varmat jyvät potentiaalisista akanoista.
Ensimmäisen ratkaisun keksittyään loistava softa-alan ammattilainen ei nimittäin menettele kuten amatööri; hän ei ala muuttamaan aivan ensimmäistä keksittyä ideaa ohjelmakoodiksi ja toimivaksi ratkaisuksi. Sen sijaan loistoyksilö istuu rauhassa ja miettii lisää vaihtoehtoisia ratkaisuja. Joko kokonaan uusia, tai sellaisia jotka parantavat ensimmäistä ratkaisua jostain kohtaa. Jokaisen ratkaisun kohdalla pään sisällä syntyy lista ratkaisun hyvistä puolista ja mahdollisista huonoista puolista, varsinkin aikaisemmin keksittyihin ratkaisuihin verrattuna.
Jos ratkaisuja mietitään tarpeeksi pitkään, tullaan vaiheeseen, että uusien parempien vaihtoehtojen keksiminen alkaa olla erittäin vaikeaa. Tässä vaiheessa viimeisinkin syvien syntyjen rauhallinen mietiskelijä on joko piirtämässä ratkaisun rakennetta paperille, tai jo kirjailemassa uusinta keksintöä ohjelmakoodiksi.
Hyvin tehty. Ongelma ratkaistu. Maailma pelastuu ja palkkio on varmasti runsaskätinen.
Tietysti jos tarinamme sankari huomaa esitetystä ongelmasta yhtymäkohtia johonkin jo aikaisemmin harjoiteltuun ongelmaan, edellisessä elämässä pitkään ja hartaasti mietitty optimiratkaisu saattaa tulla suoraan selkäytimestä. Jos näin käy, todennäköisesti ratkaisua on mietitty pitkään silloin edellisellä kerralla.
Ohjelmistoala, kuten monet muutkin modernin teollisuuden alat, on riskialtis siinä mielessä että mahdollisten ohjelmallisten suunnitteluvirheiden löytyminen tai suoranaisten bugien löytyminen kallistuu radikaalisti mitä myöhäisemmässä vaiheessa ongelma löydetään. Toisen tai jopa kolmannen ratkaisuvaihtoehdon miettiminen sen jälkeen kun ensimmäinen raakile on keksitty yleensä kannattaa, jos mietitään koko projektin kokonaiskestoa tai kokonaiskustannuksia.
Jos tavoitteena on saada aikaan hyvin skaalautuva ja muuntautumiskykyinen järjestelmä ja luotettavaa koodia, luulen että tämä on ainoa vaihtoehto lähteä liikenteeseen.
Jos esitetään ongelma, ja siihen keksitään yksi ja ainoa ensimmäinen ratkaisu, mistä tiedetään että ratkaisu on riittävän hyvä?
Kuvitellaan että olet ostamassa autoa. Kuten softa-alalla yleensä, ostokset speksataan tarkkaan. Tällä kertaa haluat (tai todennäköisemmin vaimo haluaa) punaisen ooppelin. Menet autoliikkeeseen ja pihalla seisoo punainen ooppeli. Kysymys kuuluu ostatko ensimmäisen punaisen ooppelin mikä vastaan tulee vai kaiveletko autokauppoja lisää ehkä toisen vaihtoehdon tai jopa kolmannen vaihtoehdon verran?
Stories and Insights
