Er du i lommen på dine udviklere?

Undgå Djævlen!“En Rigtig mand tager ikke Backup –

han græder !”

Måske har de mere end 20 år jeg har arbejdet med enterprise software og IT projekter, gjort mig en smule naiv… Men jeg bliver gang på gang overrasket over, hvor lidt kunder og leverandører har fokus på sikkerhed og driftstabilitet på de løsninger man ønsker udviklet.

Der dukker jævnligt historier op, om små selvstændige erhvervsdrivende, der pludselig ikke kan få adgang til deres hjemmeside.

Jeg har selv oplevet en leverandør, der har været mere end én måned om at overdrage rettigheder til en løsning, fordi de ikke havde “tid” til at holde den i luften.

Jeg har set post’s på nettet med teksten “Findes der ingen ærlige webudviklere på xxxx” osv.

Jeg ved da godt, at der er forskel på et enterprise projekt til mange millioner, og på en hjemmeside i WordPress. Men selv om du ikke driver en million-forretning (endnu), så kan du godt tage ved lære af nogle af de dyder, der hersker i de større virksomheder.

Tag ansvar for din løsning

Her er en liste over nogle af de krav, jeg mener at du bør stille til dine udviklere, uanset om det er et webbureau, et udviklingshus eller en freelancer, der skal løse din opgave. Jeg må indrømme, at jeg har taget mange af dem for givet, men jeg har måtte erkende, at det ikke altid er tilfældet, at man levere den fornødne sikkerhed og driftstabilitet.

Listen er nok ikke udtømmende, så har du nogle ting, du mener der mangler, så tilføj dem endeligt under kommentarerne.

1. Du skal have alle rettigheder

Hvis du betaler for at få udviklet en løsning, så skal du selvfølgelig have alle rettigheder til den løsning. Og det uanset om det er en APP, en Webapplikation, en hjemmeside  eller andet.

Jeg ved, at der findes steder, hvor man kan “leje” f.eks en hjemmeside, eller hvor du måske, mod betaling, kan få lov til at ligge din side på deres servere. Her får du typisk får stillet et design mm til rådighed, som du kan fylde tekst i, mod at betale f.eks kr. 500,- om måneden. Det kan lyde billigt, men det svarer til kr. 6.000,- om året, og hvad sker der så hvis din udvikler går konkurs? Eller hvis dit samarbejde med leverandøren ikke fungere? Du har behov for nogle rettelser, der ikke lige er indeholdt i templaten, og hvor rettighederne er dine.

Ellers må du starte helt forfra igen !

2. Fuld adgang til dine Systemer

Uanset om det er dit Webhotel, dit versionskontrolsystem, din konto hos Amazon, Google, Apple osv, så sørg i videst mulig omfang for, at det er dig selv der opretter de konti, der skal bruges.

Det er selvfølgelig nemt bare at lade dine udviklere, udvikle løsningen på deres servere og under deres “accounts” – og som leverandør er det jo en fordel, da det gør det væsentligt sværere for dig at vælge en anden leverandør, hvis du bliver utilfreds. Men det luner kun kort… Lige så snart løsningen skal flyttes, løber omkostningerne hurtigt op, og interessen i at supporterer din løsning, er aldrig særlig høj hos den samarbejdspartner, du er ved at fyrer. Og hvis firmaet går ned, så “dør” din løsning sammen med firmaet.

Det er nemt at oprette domain med tilhørende webhotel ved f.eks one.com, unueuro osv, og det koster dig typisk ikke mere end et par hundrede kroner, og gør du det selv, så har du kontrollen.

Og det samme gælder for alle andre dele af din løsning.

Har du problemer så bed din samarbejdspartner om at hjælpe dig. Du kan altid dele skærm med ham f.eks gennem Skype eller via Join.me – og så kan han fortælle dig, hvor du skal trykke. Sørg i det mindste altid for, at du har fuld adgang – det er jo dig der betaler gildet!

Sørg også altid for, at få dokumenteret de systemer, der indgår i din løsning med brugernavn/password.

Jeg bruger password manageren SAPpack til dette, (men jeg er også “SAP-nørd” og det er en løsning jeg selv har udviklet) – du vil sikkert have mere glæde af f.eks LastPass.

Det vigtige her er, at du får dokumeteret de systemer du benytter dig af, med brugernavn og password til diverse administrations accounts.

3. Source code

Når du får udviklet en løsning, så sørg altid for at du har adgang til, og kontrol over, source koden.

Er det en simpel WordPress side, så ligger koden ofte direkte på serveren.

Er det derimod en APP, en Webapplikation osv. så sørg for, at leverandøren anvender det, der hedder et “Versionskontrolsystem” til source koden. Enhver udvikler bør vide hvordan man arbejder med sådanne systemer. Hvis din udvikler ikke mener, at det er nødvendigt, eller hvis han ikke kan finde ud af det, eller hvis han insisterer på at benytte deres eget system, som du så ikke kan få adgang, så skal du finde dig en anden udbyder! Du skal aldrig accepterer at få koden sendt til dig på mail i form af f.eks ZIP filer, (eller som jeg faktisk oplevede her i 2014 – på en DVD ?!?).

Jeg bruger selv “bitbucket” til de løsninger, jeg arbejder med. Bitbucket er gratis op til 5 brugere. Med Bitbucket får du:

  • Versionskontrol,
  • Repository til dine programmer,
  • Issue håndtering til styring af de fejl og issues, der altid dukker op undervejs,
  • Wiki til dokumentation af din løsning.

Min holdning er helt klar her. En levering kan aldrig godkendes uden at koden er commited (=uploadet) til mit Bitbucket repository – så ingen kode” = “ingen betaling, så simpelt er det !

3.1 Standard

Og når det så kommer til brug af standard systemer, som f.eks WordPress, så bør du være meget klar og tydelig omkring, at der selvfølgelig ikke rettes i standard koden eller i koden på de plugins og/eller temaer du benytter.

Når man retter i standard koden (f.eks WordPress core), så bliver det pludseligt svært, at få opgraderet til de nyeste versioner, og dermed at få rettet de fejl, der måtte være. Du kommer således hurtigt til at stå med en ustabil løsning, som er svært at vedligeholde.

4. Oprettelse og publicere i dit navn

Når det kommer til udvikling mod Iphone, Android, Chrome Store osv, så sørg også for, at det sker i dit navn.

De, i Apples tilfælde, kr. 200,- om året, det koster at blive oprettet som udvikler, er hurtigt tjent hjem igen, hvis du på et tidspunkt vil skifte leverandør. Og hvad sker der med din APP, hvis leverandøren laver nogle andre APP’s, der får en meget dårlig rating i APP Store? – Er det så sådan nogle APP’s, du vil “Brandes” sammen med ?

Når du først er oprettet som udvikler, kan du altid tilføje medlemmer til dit team. På den måde er du sikker på, at du altid kan sende udviklingen og driften af din løsning, videre til en anden leverandør, hvis du ikke er tilfreds med den første.

5. Dokumentation

En løsning bør altid indeholde et vist niveau af dokumentation. Det betyder, at der selvfølgelig skal være kommentarer i koden – men det er måske ikke et område, hvor du nødvendigvis er særlig stærk.

Men det er ikke nok.

Der bør også være en beskrivelse af sammenhængene mellem de enkelte komponenter, build instructions (dvs hvordan genererer man programmet ud fra koden) osv.

Niveauet for dokumentation er helt op til dig, og her bør du finde en fornuftig mellemvej. Dokumentation ned i alle detaljer, bliver hurtigt for omstændeligt, og den bliver hurtigt forældet.

Jeg plejer at ligge snittet der, hvor en trænet udvikler hurtigt ville kunne tage over, med udgangspunkt i den dokumentation, der ligger. Hvad der ligger i selve koden, kan han ofte se i koden. Det, der er interessant er, hvilke hovedmoduler løsningen er bygget op omkring, samt hvordan strukturen i løsningen er.

6. Sørg altid for, at der er en backup, som du har adgang til

Sørg altid for at have en backup, der virker!!

Hos mange leverandører og web hoteller, indgår backup som en del af den service, de har solgt dig, og det er jo fint. Men jeg ville aldrig forlade mig på denne backup udelukkende. Jeg mener… hvad nu hvis udbyderen går konkurs – eller hvad nu hvis du vil ligge din løsning op på en anden server? Du skal sikre dig at du selv har en backup, der virker!

Din backup er din sikkerhed for, at du kan få din løsning op at køre igen, hvis du af en eller anden grund, skulle få behov for det.

Og nøjes ikke med at tage backup’en med jævne mellemrum. Test også, at du rent faktisk kan lave en restore, på baggrund af den backup. Måske har du ikke fået det hele med ? Måske er der noget teknisk, der gør du ikke kan lave en restore?

Og kan du ikke lave en restore, har du ingen backup – og det er uanset hvad diverse andre tjek måtte fortælle dig.

KONTAKT OS

Kontakt os for en uforpligtende snak om hvordan vi kan hjælpe jer

Proof of concept

Formålet med et Proof-of-concept er ofte at undersøge om jeres løsning, kan løftes men en række simple værktøjer. Kan de det, og kan I leve med de begrænsninger det giver, er der ofte mange penge at sparer

læs mere

Hvad er forskellen på Native, HTLM5 og Hybrid?

En af de første ting, du skal beslutte dig for, når du vil have en App udviklet, er hvilke telefoner eller styresystemer din app skal passe sammen med – altså hvilke typer af telefoner og tablets din app skal kunne virke på.

Det næste du skal beslutte dig for, er hvilke type af app du vil have udviklet. Her har du som udgangspunkt 3 muligheder

læs mere

Hvad er din ide værd?

For at DIN ide skal blive noget værd, skal der gøres en masse – tænkes en masse – ændres en masse.. Det er en lang process fra ide til indtjening…

læs mere

Få succes med udviklere fra hele verden!

Er verdens bedste udvikler dansk ? det er ikke sandsynligt !
Er verdens dyreste udviklere danske ?
Det er meget mere sandsynligt. Der findes rigtigt mange rigtigt dygtige udviklere i verden, og er man lidt opmærksom på hvad man skal kigge efter, og hvordan man skal arbejde sammen, er der rig mulighed for at nå langt for forholdsvist små midler.

læs mere