nn Alle store prosjekter ender i et smell. Bare sjelden er det champagnekorken. Rikstrygdeverket fikk føle smellet. Komplekse problemstillinger, regelverk og utviklingshjelpemidler skaper feil i beskrivelsen. Når fagfolk uten intim kjennskap til hjelpemidlene skal bruke disse for å beskrive et komplekst regelverk for en uprøvet arbeidsmåte, skal det mer til enn flaks for at det ikke skal gå galt. Usikkerhetsfaktorene er så mange at kostnadene for å eliminere disse, og tiden det tar for å røke ut alle problemstillingene, overgår det den mest pessimistiske tviler kan forestille seg.
Dynamiske organisasjoner beskrives ved hjelp av uferdige verktøy for en uprøvet arbeidsmåte. Resultatet blir ubeskrivelig.
nn Kravet til standardisering, tilpasningsevne og åpenhet har gitt gjenklang i IT-bransjen. Maskiner, driftsmiljøer og databaser har lært å tilpasse seg. Betjeningsmåte, utviklere og utviklingsverktøy har ikke. For hver ny versjon av MS-Windows får applikasjoner, brukere og utviklere nye problemer å stri med. Fagmannen Tom Gilb uttalte allerede for 20 år siden at det ikke eksisterer noen applikasjon som er feilfri under alle omstendigheter. Hadde Windows 95 vært relativ feilfri, hadde vidusmiljøet vært tilgjengelig høsten 94.
nn Det første som ble standardisert, var programmeringsspråkene. Det første som glemte hensikten med standardisering, var nye programmeringsspråk. Fortran var først. Mye i språket burde vært skrapet, men ble likefullt standardisert. Fortrans utviklere var villig til å foreta forbedringer, ikke radikale, men nødvendige. 30 år etter at Fortran første gang beskrev en applikasjon, er det fortsatt i aktiv bruk. Algol som prøvde å rydde opp i Fortrans svakheter, vil kun bli husket som uropphavet til Simula, som la grunnlaget for objektorientert beskrivelse.
nn Cobol og Fortran tilhører tredje generasjon, 3GL. Språkene er problemorienterte med krav til stor detaljbeskrivelse. Utviklerne ønsker seg resultatorienterte språk. 4GL-språkene prøver å løse dette. Alle skal være best. Ingen er enige om noe. Standarder eksisterer ikke. Komplekse administrative problemstillinger kan ikke beskrives ved å angi resultatet. Dessverre har 4GL-leverandørene valgt å utvikle egne 3GL, scriptspråk. Igjen er ingen like, men alle likner på hverandre.
nn Ingen utviklingshjelpemidler har oppnådd noen markedsandel. Noen små prosentandeler er det meste, promiller er det vanlige. En av grunnene er mangel på sterke markedsføringskrefter. Programvareleverandører har ikke muskler til å markere seg. Maskinleverandørene støtter ikke opp. MS-Windows er blitt en suksess, ikke på grunn av Microsoft, men på grunn av maskinleverandørene. Powerbuilder er uferdig, men appellerer til PC-brukere. Konkurrenter må lære. Det brukerne ser er hva de forstår. Det er spennende med nye programmeringsmiljøer. Det er også farlig. Mye arbeid blir bortkastet om ikke miljøet overlever. Brukere av Norsk Data har en rekke eksempler på programvare som måtte oppgis sammen med maskinen. Det gjelder derfor å få programmeringsmiljøet utbredt. Ikke bare på en maskin, men mange. Ikke bare på en maskinkategori, ikke bare på et driftsmiljø, ikke bare for en type problemstilling, men flere.
nn En applikasjon har minimum tre elementer. Brukermiljø, applikasjonsregler og arkiv skal alle beskrives. De nyeste verktøyene tar utgangspunkt i brukermiljøet. Arkivet ses på som en felles resurs som løser eventuelle konflikter. Forte og Gupta er eksempler. Raske og effektive for mindre problemstillinger. Verktøyene skal håndtere fire brukersituasjoner. Kritiske applikasjoner med mange samtidige brukere. Effektive løsninger for avdelinger i konstant forandring. Beslutningsstøtte for fagfolk, og informasjonssøk for fagfolk og forbrukere. De fire ulike situasjonene beskrives ikke av det samme verktøyet. Ingen av verktøyene er ennå gode. F.eks. nærmer Powerbuilder og Progress seg fra hver sin side. Modenhet, antall miljøer, databaser og utviklingmodell skiller dem.
nn Powerbuilder er sterk på å beskrive et grafisk miljø med programkontroll av registrerte data. Progress er sterk på definering av logikk og kobling mot mange driftsmiljøer og databaser. Logikken bør kunne tredeles. Alt på en databasemaskin, en applikasjonsmaskin eller deler på både bruker- og databasemaskin. Hva som er best, er avhengig av oppgavetype, nettverkskapasitet og antall samtidige brukere. Visual Basic f.eks., er best på informasjonsuthenting for få brukere, Usofts produkter er best på logikkbeskrivelse og evnen til å håndtere mange brukere.
nn Hvilke verktøy som blir brukt, er ikke alltid definert av behovet, men av utvikleren. Det utvikleren selv kan, har lett for å påvirke utviklingsverktøyet. dBase-brukere foretrekker heller Gupta enn Texas Instruments IEF. Det totalintegrerte miljøet IEF, appellerer til utviklere som er opptatt av metodeutvikling. De forskjellige årsklasser vil ha sine favorittverktøy. Utviklere under 35 bruker helst PC-baserte verktøy, fordi de er vokst opp med PCen. 40-åringer eller eldre, liker metodeorienterte hjelpemidler og verktøy som kan fordele oppgaven der den hører hjemme. Med den nettverkssentrerte brukermodellen blir vi mer opptatt av det som foregår i bedriften, enn det som skjer på pulten. All programvare ligger sentralt og lastes ned ved bruk. Gjenbruk er et stikkord. Objekter den foretrukne måten å beskrive applikasjonselementene.