Kundecase 1: Projektet nærmer sig afslutningen. Der er noget overskridelse på tiden. Man har haft noget billig russisk outsourcing ind over. Man har haft problemer med at softwaren ikke kunne køre helt stabilt i 5-6 måneder. Software har hjulpet den eneste FPGA udvikler med at finde fejl i VHDL koden gennem lang tid. Men det vil bare ikke lykkes – og den hårde deadline nærmer sig.
Træls situation. Langt fra optimalt. Men det bliver værre…
Vi kommer ind som “brandslukning” – og det er okay. Vi finder hurtigt et par fejl så systemet kan køre og den virkelig dyre deadline kan nås. Succes?
Nej, for det står nu lysende klart at FPGA koden slet ikke har en kvalitet der bør releases. Der er kendte fejl. Der mangler testbench. Der mangler den “release-procedure”, der gør at koden kan pakkes ud igen og de næste fejl kan findes og rettes.
Og der må vi så modvilligt forlade projektet – kassen bliver smækket i. Måske fordi vi ikke magter at forklare vigtigheden – måske fordi finanskrisen har presset virksomhedens økonomi så meget, at der reelt ikke er råd til at tænke 3-6 måneder frem.
Kundecase 2: Et projekt vi kender godt fra en tidligere version. Kunden har fået ansat sin første FPGA og alt-mulig-andet udvikler. Så denne gang kan man selv… Der bliver lavet print med avancerede RF sager, FPGA osv. Og der mangler “bare lige” det sidste i FPGA koden for at få det til at virke. Tidsplanen begynder at skride.
Vi kommer ind i projektet der – igen som “brandslukning” – finder hurtigt et par fejl. Får dem rettet og tingene ser ud til at køre. Succes?
Nej, for det står igen klart at FPGA kodebasen, ikke har den kvalitet og niveau, der er nødvendig for fremadrettet vedligehold og videre udvikling. Der mangler testbench. Der mangler dokumentation. Osv.
Igen må vi modvilligt forlade projektet. Kassen smækkes i. Man “kan selv”. Og det respekterer vi selvfølgelig 100%.
Forklaringen er logisk nok
Som udviklere er vi alle lidt ærekære. Det er normalt. Og det er måske også sundt der hvor det giver lidt konkurrence om at øge niveauet og kvaliteten. Det giver jo også anledning til at lære noget nyt, hvilket mange af os jo brænder for.
Men det bliver usundt når der ikke diskuteres åbent om kvaliteten for projektet pga. ærekærhed eller fornægtelse hos projektstyregruppen.
Så derfor kære udviklingschefer og projektledere! I spiller hasard med projekterne på den måde. Og udviklerne skal have mulighed for at blive bedre. Det bliver de hurtigst og nemmest ved at arbejde sammen med nogen, som de kan udveksle erfaringer med – og lære noget af.
Og sidder du nu og tænker: “hvad snakker han om?”, så er det nok fordi du sidder i en af de virksomheder – som der heldigvis også er mange af – hvor FPGA udvikling foregår struktureret og på et højt professionelt niveau. Godt – fortsæt! Og bliv bedre til det!
Risikoen ved at tage for let på det, er at fejl sniger sig ind i apparatet. Fejl som opdages ude hos kunderne. Fejl som er meget svære at finde på det tidspunkt. Samtidig betyder det, at en ny udvikler på et senere tidspunkt vil have meget svært ved at tage projektet op og udføre rettelser på det uden et unødigt stort tidsforbrug.
Er der styr på FPGA flowet?
Vi tager udgangspunkt i flow, som alle nok kender, men måske ikke helt følger. Det er simpelt, men effektivt. Du kan se det herunder, hvor en kundes projekt er markeret op med simple checkmarks. De checkmarks er sat ud fra en objektiv faglig vurdering. Hvordan ser jeres FPGA projekter ud?
Som et minimum må der kunne sættes flueben for alle trin, før man kan betegne kodebasen som værende i fornuftig stand. Som det fremgår af eksemplet, er det ikke altid tilfældet!
Sidder du med FPGA projekter, som nærmer sig release. Så brug det til at sikre, at det som releases er i orden. Brug det også til de projekter som skal pakkes ned efter endt udvikling. Uanset om det bare skal pakkes ned i 3 måneder – du ved jo reelt ikke, hvem der skal pakke det op igen! Og brug det ved milestones – en milestone kan ikke passeres uden hak i alle kasser.
Check udpakningen
Når der er lavet release og projektet går videre i en ny fase, så få som minimum en anden udvikler til at pakke projektet op på en frisk maskine. Check at den “binære” produktionsfil kan genskabes uden fejl – og check at testbænke kan køre igennem.
Kvalitet betaler sig. Specielt i længden!