Een goede programmeur??

[michels85]

Hallo allemaal,

 

Eerste keer dat ik hier een vraag stel maar ik hoop dat jullie hem kunnen beantwoorden.

 

Ik heb een concept bedacht wat geprogrammeerd moet worden, nu heb ik bij 2 patijen een offerte aangevraagd maar qua prijs zijn ze ten eerste al verschillend.

 

De eerste waar ik ben geweest is dubbel zo duur als de tweede en zeggen ook dat het langer duurt om te bouwen 2 maanden fulltime programmeren en dan nog eens 3 maanden testen en bijwerken.

Terwijl de tweede partij zegt dat hij 2 maanden nodig heeft om het te bouwen en te testen en dan is het klaar met hooguit nog een halve maand erbij.

 

Nu is mijn vraag hoe kan ik controleren door bijv. vragen te stellen welke programmeur nu goed en wat zijn kwaliteiten zijn

 

Zijn daar standaard vragen lijsten voor of kunnen jullie mij daarmee helpen.

Ik heb wel enige ervaring met internet programmeurs maar niet in dit soort projecten.

 

Alvast bedankt voor jullie hulp.

 

Michel

[BE WANNE]

Michel,

 

Wanneer je nu nog een offerte aanvraagt bij een derde partij zal je zien dat deze er weer anders uitziet.

 

Het is moeilijk om vanaf een "papieren opdracht" te gaan programmeren, gaande weg het proces zal er toch van alles anders moeten etc. Ik denk in dit geval dat je eerst een concept moet laten maken.(een soort basis) en daar vanuit verder moet gaan werken. Het is nooit met zekerheid te zeggen hoelang een programmeur er over doet, vandaar ook de grote verschillen. Het je het idee al helemaal uitgewerkt op papier?

 

Jef

[Christine]

De eerste waar ik ben geweest is dubbel zo duur als de tweede en zeggen ook dat het langer duurt om te bouwen

 

Als je het aan een freelancer vraagt zal het aanzienlijk goedkoper zijn dan wanneer je het aan een groot softwarehuis vraagt. Die laatsten zetten er een heel team op en dan ben je gauw drie keer zoveel kwijt vanwege overhead en hogere tarieven. De kwaliteit van een freelancer kan veel beter zijn dan van een groot bureau, maar ook slechter. Ik zou referenties vragen van beide partijen, of bij voorkeur zaken doen met partijen die je via via al kent.

 

Twee antwoorden kruisen elkaar.

Ik ben het met Jef eens dat je beter in stapjes kunt ontwikkelen dan een opdracht geven en dan wachten tot het klaar is. Wij ontwikkelen hier ook in zo klein mogelijke stapjes zodat je altijd feeling hebt met het eindresultaat en niet voor verrassingen komt te staan.

 

dagdag

Christine

[michels85]

Michel,

 

Wanneer je nu nog een offerte aanvraagt bij een derde partij zal je zien dat deze er weer anders uitziet.

 

Het is moeilijk om vanaf een "papieren opdracht" te gaan programmeren, gaande weg het proces zal er toch van alles anders moeten etc. Ik denk in dit geval dat je eerst een concept moet laten maken.(een soort basis) en daar vanuit verder moet gaan werken. Het is nooit met zekerheid te zeggen hoelang een programmeur er over doet, vandaar ook de grote verschillen. Het je het idee al helemaal uitgewerkt op papier?

 

Jef

 

Ja ik heb alles op papier uit gefilterd wat ik wil hebben.

Dus dat is helder.

Alleen hoe weet je nou dat je met een goede programmeur te maken hebt want het kost niet niks en qua tijd wordt je ook niet vrolijk als achteraf blijkt dat hij/zij niet capabel genoeg was of is.

[perry]

Probeer je idee zo veel als het maar kan helemaal uit te werken.

Ik weet, dat is niet eenvoudig!

 

Maar beter nu wat meer nadenken, kan je heel veel tijd en geld besparen.

 

Maak screenshots en simuleer de gegevens die je denkt dat het gaat creeëren. Ik zelf ben er ook nog niet wat je daar nou het nou beste voor kunt gebruiken, maar ik ben vrij ver gekomen door gewoon powerpoint te gebruiken.

 

Print als die screenshots uit, hang ze op de muur of leg ze op de grond en loop er zo stap voor stap heen wat er in diverse situaties allemaal zou moeten en kunnen gebeuren. Levert overigens leuk behang en of vloerbedekking op:-)

 

Ik heb ook veel profijt gehad van zo'n flow chart teken programma (die symbolen staan overigens ook in Powerpoint.

 

Als je dat eenmaal hebt en een beetje programmeer ervaring hebt, weet je wat voor modules er gemaakt moeten worden.

 

Als je de modules hebt kun je prijzen gaan aanvragen en ook je project voor jezelf goed monitoren door de software ontwikkeling stap voor stap te volgen.

 

Soms is het handig om bepaalde modules bij andere experts neer te leggen. Bijvoorbeeld de interface design.

 

Probeer het bouwen van het programma te volgen, nu meer nadenk tijd nemen, voorkomt dat je straks in de weg loopt met weer allerleii andere ideeën die meestal ontstaan.

 

My lessons:-)

 

Perry

 

 

 

 

 

 

 

[Henk]

Over wat voor applicatie hebben we het hier, welke programmeer omgeving enz. Natuurlijk hou je het concept voor jezelf maar in welke richting en omvang moeten we denken? gr henk.

[michels85]

Probeer je idee zo veel als het maar kan helemaal uit te werken.

Ik weet, dat is niet eenvoudig!

 

Maar beter nu wat meer nadenken, kan je heel veel tijd en geld besparen.

 

Maak screenshots en simuleer de gegevens die je denkt dat het gaat creeëren. Ik zelf ben er ook nog niet wat je daar nou het nou beste voor kunt gebruiken, maar ik ben vrij ver gekomen door gewoon powerpoint te gebruiken.

 

Print als die screenshots uit, hang ze op de muur of leg ze op de grond en loop er zo stap voor stap heen wat er in diverse situaties allemaal zou moeten en kunnen gebeuren. Levert overigens leuk behang en of vloerbedekking op:-)

 

Ik heb ook veel profijt gehad van zo'n flow chart teken programma (die symbolen staan overigens ook in Powerpoint.

 

Als je dat eenmaal hebt en een beetje programmeer ervaring hebt, weet je wat voor modules er gemaakt moeten worden.

 

Als je de modules hebt kun je prijzen gaan aanvragen en ook je project voor jezelf goed monitoren door de software ontwikkeling stap voor stap te volgen.

 

Soms is het handig om bepaalde modules bij andere experts neer te leggen. Bijvoorbeeld de interface design.

 

Probeer het bouwen van het programma te volgen, nu meer nadenk tijd nemen, voorkomt dat je straks in de weg loopt met weer allerleii andere ideeën die meestal ontstaan.

 

My lessons:-)

 

Perry

 

 

 

 

 

 

 

 

Ik heb al een aantal afbeeldingen van hoe ik het wil hebben gemaakt in photoshop en flash dus dat is het probleem niet.

Het gaat mij meer om de kwaliteit van een programmeur en hoe je die kan bepalen.

[michels85]

Over wat voor applicatie hebben we het hier, welke programmeer omgeving enz. Natuurlijk hou je het concept voor jezelf maar in welke richting en omvang moeten we denken? gr henk.

 

Het wordt in php met sql en het is een soort shop maar dan groter en complexer met tracking en tracing en meer beveiligings opties zoals thumb scan.

[perry]

Het gaat mij meer om de kwaliteit van een programmeur en hoe je die kan bepalen.

 

Dat weet je over het algemeen pas na uitproberen en wellicht raadplegen portfollio.

 

Perry

[Henk]

Over wat voor applicatie hebben we het hier, welke programmeer omgeving enz. Natuurlijk hou je het concept voor jezelf maar in welke richting en omvang moeten we denken? gr henk.

 

Het wordt in php met sql en het is een soort shop maar dan groter en complexer met tracking en tracing en meer beveiligings opties zoals thumb scan.

 

Moeilijk om aan te geven hoelang zoiets mag duren en mag kosten. Maar let wel vooral op de veiligheid, regelmatig worder er weer nieuwe PHP hacks richting de MySql database gevonden. Dus vraag zeker of zij veilge code kunnen schrijven. Goedkoop kan duurkoop zijn doordat er vaak oude niet veilige of geupgrade templates worden gebruikt, succes.

[NathanW]

Inderdaad, functionaliteit is prima te controleren door jou, maar de veiligheid is een ander verhaal. Daar zal blijken of je met een goede of minder ervaren programmeur te maken hebt. Daarnaast is de mate van herbruikbaarheid van code ook een aspect die iets over de kwaliteiten van de programmeur zou kunnen zeggen.

 

Ik zou vragen of ze globaal concreet willen beschrijven wat ze aan beveiliging doen. Hoe gaat men om met userinput bijvoorbeeld. Die twee verkregen plaatjes geven je meteen wat inzicht in de mogelijke gevaren en je kunt ze vergelijken.

 

Wat betreft de kosten heb ik misschien een tip: laat het in Polen maken: http://www.nearshoring.nl/tarieven.html. Uiteraard kleven hier ook weer de nodige nadelen aan.

 

Wat de duur betreft, uit ervaring weet ik dat ontwikkelaars vaak te optimischtisch zijn over de duur van een project met als gevolg dat het bijna altijd uitloopt. Een ontwikkelaar die zegt het heel erg snel te kunnen realiseren klinkt erg aantrekkelijk, maar kon wel eens niet reeel zijn.

 

Secces! Gr., Nathan.

[Robert M]

Een kleine aanvullig op de al eerder genoemde tips:

 

Een programmeur die overzichtelijke code schrijft (denk aan inspringen, lege regels) en goed documenteert kan zichzelf en u veel tijd/geld besparen.

 

Mocht je in de toekomst ooit eens willen uitbreiden, dan kan het afhankelijk van de omvang van de uitbreiding leiden tot een urenbesparing van enkele tot mogelijk enkele tientallen uren. Uit eigen ervaring weet ik dat het voor een programmeur vaak lastiger is om andermans code te bewerken/uit te breiden, maar dat goede documentatie en overzichtelijke code heel wat frustratie en tijd kunnen besparen.

 

Verder wil ik descartes' reactie ook benadrukken. Zeker bij een website waar geld een belangrijke rol speelt (webshop) dient er voldoende aandacht aan de veiligheid te worden besteed.

[willemj]

Nu is mijn vraag hoe kan ik controleren door bijv. vragen te stellen welke programmeur nu goed en wat zijn kwaliteiten zijn

 

Eén vraag die een indicatie geeft is: "Wat gebeurt er als er een fout optreedt?" Krijg je het antwoord "Het gaat altijd goed" dan heb je geen goede te pakken ;)

[tndmedia.nl]

Wat je ook zou kunnen doen (indien mogelijk en als het om een echt grote klus gaat zou ik dat zeker doen) is een ervaren programmeur/webdeveloper (collega/kennis of extern iemand) benaderen.

 

Deze vervolgens bij de besprekingen met beide partijen laten zijn om enkele belangrijke vragen te stellen (veiligheid, aanpak, hoe de prijs is opgemaakt etc).

 

Wat ik in ieder geval zou doen is echt een middag om tafel gaan en het gehele plan doornemen en kijken hoe ze het willen aanpakken etc.

[Christine]

Het wordt in php met sql

 

wow. php voor een grote interactieve site. als je iemand inhuurt en die begint niet enorm te waarschuwen tegen de veiligheidslekken in php dan heb je niet de goede. PHP is erg snel en handig en makkelijk maar wil je geen veiligheidslekken dan moet je echt een goede programmeur hebben. Ik denk dat de helft van de php sites lek is.

 

dagdag

Christine

[Robert M]

Het wordt in php met sql

 

wow. php voor een grote interactieve site. als je iemand inhuurt en die begint niet enorm te waarschuwen tegen de veiligheidslekken in php dan heb je niet de goede. PHP is erg snel en handig en makkelijk maar wil je geen veiligheidslekken dan moet je echt een goede programmeur hebben. Ik denk dat de helft van de php sites lek is.

 

dagdag

Christine

 

Voor een groot deel moet ik Christine gelijk geven.

 

Het probleem is m.i. de toegankelijkheid van PHP. De basics heb je al snel onder de knie. Daarnaast zijn er talloze fora die je ondersteuning kunnen bieden en hosting voor PHP is erg makkelijk te verkrijgen. En last but not least: er is in de PHP wereld erg veel verkrijgbaar aan opensource (waaronder diverse wijdverspreide fora). Wanneer men daar een fout in ontdekt en de webmasters zijn te lui om de boel regelmatig te patchen, dan krijg je lekken.

 

"als je iemand inhuurt en die begint niet enorm te waarschuwen tegen de veiligheidslekken in php dan heb je niet de goede."

In php zelf zitten niet echt veel veiligheidslekken, het gaat erom hoe de programmeur omgaat met input. Hier heb je in elke programmeertaal mee te maken, maar omdat PHP op internet één van de meest gebruikte talen is vallen de PHP lekken het meest op.

 

Ik vind dat een goede programmeur die maatwerk levert daarom niet expliciet hoeft te waarschuwen voor veiligheidslekken, omdat hij daar zelf voldoende bescherming moet kunnen bieden in zijn software. Met goede controle op input vanuit formulieren en url's voorkom je denk ik al gauw 80-90% van de meest voorkomende lekken.

 

Implementeert de programmeur echter open source software, dan vind ik wel dat hij/zij ervoor zorg moet dragen dat er regelmatig wordt geupdate, of in ieder geval duidelijk aangeeft dat de opdrachtgever iemand aanstelt die daarvoor verantwoordelijk is.

 

Mits goed geprogrammeerd, is PHP zeer geschikt voor grote websites (grote partijen als Deutsche Telekom en Yahoo! kiezen niet voor niets voor het gebruik van PHP voor hun portals/websites).

[djluc]

Vraag eens op basis van welk framework ze programmeren of dat ze geheel vanaf de grond beginnen. Je kan dan in elk geval een inschatting maken van de hoeveelheid ervaring en het type product wat de programmeur aanspreekt. Om je een idee te geven: http://phpnuke.org/ is een veelgebruikt framework, maar Typo3 ook: http://www.typo3.com

 

Als je alleen al kijkt naar de verschillende sites dan zie je al een duidelijk verschil. De programmeurs die rondom zo'n product hangen verschillen ook erg, zo zie je bij Typo3 wat meer zakelijke mensen terwijl je de allernieuwste/allergekste ontwikkelingen vaak als eerste bij een phpnuke zult tegenkomen.

 

Ook de leercurve van een dergelijk product zegt iets over de kwaliteit van de programmeur. Een product met een stijle en lange leercurve wordt niet gedragen door programmeurs die gaan voor de snelle oplossing. Die leercurve is lang omdat er meer eisen aan de programmeur gesteld worden wat resulteert in een niveau.

 

Om mijn verhaal maar meteen weer af te zwakken: Er zitten altijd rotte appels tussen, de beste er uit pikken is en blijft de taak van de ondernemer.

 

[MarkScholten]

Allereerst PHP sites zijn zo lek als het nivo van de programmeur. Daarnaast voor grote/drukke sites is PHP een aanrader, het is de meest efficiente scripttaal die momenteel op de markt is. Alles hangt wel weer geheel af van de scripter, vraag bijvoorbeeld hoe hij "user input" controleert, zegt hij dat hij de user vertrouwd dan kun je beter een andere kiezen. Vraag daarnaast aan de bedrijven of ze 1 site kunnen geven die ze al hebben gemaakt en waar je als bezoeker kunt registreren en inloggen. Probeer bij het registreren een verkeerd e-mail adres op te geven (geen @ of . erin), indien dit mogelijk is dan is het script als niet goed beveiligd. Probeer daarnaast op de account die je hebt gemaakt in te loggen waarbij je de goede gebruikersnaam op geeft maar het volgende bij wachtwoord invult:

x OR '1' = '1'

(let op de x vervang je door een foutief wachtwoord met dezelfde lengte als het origineel).

 

Kun je hiermee inloggen dan is het ook niet goed beveiligd, dit zijn de twee simpelste methodes om te controleren of het script enigszins beveiligd is. Om een script goed te testen zou je bijvoorbeeld eens foutieve gegevens in moeten vullen (als iets in de adresbalk staat achter een vraagteken en achter een = teken dan moet je dat eens wijzigen kijken of dat kan ja of nee en wat je dan krijgt, dit is mogelijk ook een groot risico!).

 

Dit zijn een paar basis methodes, uitgebreide vragen kan ik hier zo niet geven aangezien ik dan weer klachten krijg dat ik te veel op details in ga.

[Erik Duindam]

Bij de keuze van programmeur moet je naast de referenties ook kijken naar de persoon. Iemand die elk beveiligingslek kan dichten en alles perfect overzichtelijk kan programmeren, hoeft nog niet goed te zijn in zijn vak: het omzetten van concept naar werkende programmatuur. Een complex en werkend stuk programmatuur kan in theorie compleet waardeloos zijn. Je moet sowieso een technisch goede programmeur hebben, maar staar je niet alleen dáár blind op, want dan struikel je vroeg of laat.

 

Hoe beoordeel je of een programmeur goed is (technisch gezien)? Dat is erg lastig. Referenties zeggen in dat opzicht ook erg weinig. Wat mij een intressante manier lijkt om er achter te komen is door het de programmeur gewoon face to face te vragen: "Waarom ben jij een goede programmeur?". Kijk maar hoe hij antwoordt; een programmeur hoort behoorlijk wat creativiteit in zijn donder te hebben. Programmeren is weliswaar erg droog, maar zonder creativiteit kun je geen problemen oplossen en functionele programmatuur ontwikkelen.

 

Laat in ieder geval duidelijk zijn dat er geen enkele aanleiding is om te veronderstellen dat iemand die 5 maanden aan een applicatie/programma werkt een beter (technisch en functioneel) systeem kan neerzetten dan iemand die er 2 maanden over doet. Wat je ook moet bedenken is dat de ene programmeur ongeveer 300 uur rustig bezig is in 2 maanden, en dat de andere programmeur misschien ultra-geconcentreerd 500 uur bezig is. Als je het zo bekijkt, dan maken uren, en zeker maanden, erg weinig uit.

 

Let in ieder geval goed op de wijze van documentatie van het product (vraag hiernaar). Het blijft een feit dat er in de wereld van PHP/SQL erg veel bedrijfjes en freelancers zijn, en dat veel van die bedrijfjes graag moeite doen voor potentiële klanten om zichzelf te bewijzen. Dus stel ze gerust gerichte vragen, dat vinden ze nog leuk ook (als ze passie hebben voor hun vak).

 

Kijk verder ook of de referenties je aanspreken, of dat ze je alleen 'goed' of 'in orde' lijken. Hierin draait het dan niet alleen om technische hoogstandjes (dat is voor een leek niet eens goed te beoordelen), maar ook de structuur die een programmeur gebruikt in zijn pagina's, in zijn navigatie en in al zijn ontwikkelingen. Programmeren blijft een omzetting van een gedachte naar een "wiskundig correcte tekst". Persoonlijkheid spreekt hierbij naar mijn mening een grote rol. Wees vooral niet bang wat bedenktijd te nemen of een aantal vrijblijvende afspraken te maken. Desnoods benader je één van de referenties om eens te vragen over de werkwijze en levertermijnen. Dit is misschien brutaal, maar een programmeur snapt heus wel dat jij ook geen oneindige bankaccount hebt en dat je op zoek bent naar (bijna-)garanties.

 

Ik wens je veel succes met de keuze!

[willemj]

Mits goed geprogrammeerd, is PHP zeer geschikt voor grote websites (grote partijen als Deutsche Telekom en Yahoo! kiezen niet voor niets voor het gebruik van PHP voor hun portals/websites).

 

Even nuanceren deze opmerking: PHP is uitstekend geschikt voor de presentatie laag voor grote toepassingen/websites. Als je achter het schilletje van HTML gaat kijken dan zit er hoogst waarschijnlijk een andere taal achter.

[Christine]

Allereerst PHP sites zijn zo lek als het nivo van de programmeur.

 

Dat is heel kort wat ik ongeveer bedoelde :-)

 

dagdag

Christine

[R.I.P. | Peter Bonjernoor]

Een programmeur die overzichtelijke code schrijft (denk aan inspringen, lege regels) en goed documenteert kan zichzelf en u veel tijd/geld besparen.

 

Dit kan ik van harte onderschrijven. Ik heb nu een paar keer te maken gehad met websites waar dit niet in orde was, met als gevolg dat je inderdaad 2 dagen bezig bent iets op te lossen wat in 2 uur had geregeld had moeten zijn.

[Christine]

Even nuanceren deze opmerking: PHP is uitstekend geschikt voor de presentatie laag voor grote toepassingen/websites. Als je achter het schilletje van HTML gaat kijken dan zit er hoogst waarschijnlijk een andere taal achter.

 

Ik helpt het je hopen. Wij testen nog wel's websites die php en/of mysql gebruiken, en dan blijkt in bijna de helft van de gevallen dat je op de site kunt inbreken. Geldt soms ook voor webmail systemen van gerenommeerde providers. Ook de site van "Nederland ICT" was/is lek, je kon zo de hele database uitlezen.

 

De meest gemaakte fout is dat ze met een scriptje de user invoer rechtstreeks in een php of sql script stoppen. Voer je dan sql-achtige dingen in, dan worden jouw instructies gewoon uitgevoerd. (het ligt iets ingewillelder, maar dan wordt het zo'n lang verhaal)

 

dagdag

Christine

[willemj]

Openingen laten voor 'SQL injection' is inderdaad een veel gemaakte fout. Maar die maak je net zo makkelijk in andere talen. Dat is geen gebrek van de taal maar een gebrek aan kennis van de programmeur (of luiheid)

 

Maar ik denk niet dat de originele poster toegang heeft tot source code van de aanbieders of voldoende kennis om dit soort zaken uit die code te halen.

[MarkScholten]

Openingen laten voor 'SQL injection' is inderdaad een veel gemaakte fout. Maar die maak je net zo makkelijk in andere talen. Dat is geen gebrek van de taal maar een gebrek aan kennis van de programmeur (of luiheid)

 

Maar ik denk niet dat de originele poster toegang heeft tot source code van de aanbieders of voldoende kennis om dit soort zaken uit die code te halen.

 

Hiervoor zou de topic starter misschien iemand anders moeten vragen, er zijn genoeg programmeurs die een script van een ander op zulk soort dingen willen controleren en eventueel vragen stellen over een script voor een vast bedrag. De gene die je hiervoor vraagt kun je dan het beste wel uitsluiten om het uiteindelijke product te ontwikkelen.

[Christine]

Openingen laten voor 'SQL injection' is inderdaad een veel gemaakte fout.

 

SQL injection en cross site scripting zijn veelgemaakte fouten. Het ligt aan de kwaliteit van de programmeur. Mijn stelling is dat je hogere eisen moet stellen aan de programmeur dan veel mensen in de praktijk doen. Wij kunnen dat makkelijk doen, maar ik kan me voorstellen dat het voor de klant heel lastig zo niet onmogelijk is. Is het een idee om de selectie te laten begeleiden door een software engineer waarvan je weet dat zij of hij heel goed is? Die hoeft er maar twee uur in te steken.

 

[toevoeging] Hmm, dat laatste had dus al iemand gezegd. Volgende keer zal ik dus eerst replies lezen voordat ik een antwoord post.

 

dagdag

Tientje Ongeduldje.