En felaktig vy: Prioritera kamrater framför användare
Hur många gånger har du tittat på någons kod och sagt:
Jag använder inte detta eftersom det inte ser välskrivet ut.
Och i det här fallet kan "se välskriven" antingen vara ett substitut för:
- "se ut som jag skulle skriva det"
- "verkar vara vettigt för mig."
Visst – det finns tillfällen då det är riskabelt att använda öppen källkod. Vi vet detta från de olika mjukvaror och tjänster som dyker upp med sårbarheter. Men, åtminstone för det här inlägget, behandla dem som undantag – inte regeln.
Det betyder att vi har kvar att titta på något vi kan använda men väljer att inte använda eftersom det inte verkar vara skrivet på ett sätt som vi tycker att det borde skrivas.
Prioritera kamrater framför användare
Utveckling är knepigt eftersom det finns flera avvägningar som vi – eller en annan utvecklare – måste göra när de bygger något.
Tittar inifrån och ut
Vi måste överväga:
- tids- och budgetbegränsningar,
- vilket paradigm kommer att hjälpa oss att leverera en solid inom nämnda begränsningar,
- löser den slutliga lösningen verkligen kärnproblemet,
- kommer det att finnas underhållskostnader förknippade med hur vi har satt ihop något?
Och listan kan fortsätta.
Att ta hänsyn till de olika aspekterna av utveckling och debattera filosofin kring hur något ska byggas är inte alls ovanligt i vår bransch
Men det är också en tidskrävande och det kan visa sig vara en övning som ger ett nettonollresultat eftersom det inte blir något av det. (Ja, det kan ofta vara en lärorik upplevelse, men inte alltid.)
Foto av José Alejandro Cuffia på Unsplash
Tittar utåt in
Men rent praktiskt sett:
- Påverkar det paradigm som används för att bygga lösningen din användning av programvaran?
- Löser programvaran i fråga problemet?
- Om du inte kunde se hur projektet sattes ihop, vilken slutsats skulle du dra om programvaran?
Och den sista punkten kan vara den mest kritiska när det gäller programvara med öppen källkod.
Jag har arbetat i branschen tillräckligt länge för att veta att folk ofta vill ha en funktionell lösning som löser deras problem och de antar att den är säkert byggd.
Utvecklare, å andra sidan, kommer att granska koden mer än lösningen den ger och problemet den löser.
Om du är en utvecklare finns det absolut en tid och en plats för båda. Men om du låter det senare hindra dig från att skicka det förra, kanske du aldrig får ut något för andra att använda eftersom du är för orolig över vad dina kamrater kan tänka.
Och när du löser ett problem för andra människor, borde de vara den som betyder mer än dina kamrater.