Vad är det enklaste som behövs?

Det finns ett citat som ofta tillskrivs Albert Einstein som jag gillar (och jag är säker på att de flesta gör det):

Allt ska göras så enkelt som möjligt, men inte enklare.

Det finns en viss utredning om om han sa det eller inte, men poängen kvarstår oavsett vem som sa det.

Det är lätt att ta den här idén och tillämpa den på saker som vi gör i vardagen som vi inte vill göra, eller hur?

• Jag vill inte städa mitt rum, så jag städar det lagom.
• Jag kommer att göra precis tillräckligt mycket arbete för att tillfredsställa kunderna, och det räcker.
• Jag kommer att uppfylla [vilket ansvar som helst] i [lägsta möjliga grad] och eftersom Einstein [påstås] ha sagt det, vem är jag att argumentera.

Även om jag inte håller med om det (och diskussionen för det ligger utanför ramen för det här inlägget), anser jag denna idé inom ramen för webbutveckling.

Och för att vara tydlig, jag pratar inte om webbdesign. Jag är ingen designer. Jag vill inte tala för något som jag inte är en del av. Men när det gäller att tillhandahålla lösningar för människor som använder programvara eller snarare webbutveckling, är jag mycket mer benägen och positionerad att prata om detta.

Jag undrar strängt taget ofta om vi har gjort webbutveckling mer komplicerad (och varför vi har gjort det) och om att använda det enklaste som behövs är allt som verkligen behövs när man bygger lösningar för andra.

Det enklaste som behövs

Jag har nyligen skrivit om de olika aspekterna av front-end-utveckling enbart (inom ramen för att få ut något snabbt) och hur vi nu har byggt verktyg strikt för den aspekten av webbutvecklingsstacken.

När det gäller verktyg som detta, oavsett vilken nivå av stacken vi arbetar på, kommer jag på mig själv att fråga:

Är detta verktyg nödvändigt för att effektivt och positivt göra det lättare att utveckla lösningen för någon annan?

Jag tycker till exempel att Composer är något som är väldigt användbart. Det låter mig enkelt hantera tredjepartsbibliotek, uppdatera dem efter behov och integrera dem i mina projekt.

På samma sätt tycker jag att verktyg som undersöker mina åtaganden innan de skickas till GitHub är användbara eftersom de tillåter mig att fånga problem med kodkvalitet som annars skulle ta längre tid under kodgranskningsprocessen.

Ta till exempel några av front-end-byggverktygen som Grunt, Gulp, Yarn, Node, Mix och så vidare. För att vara tydlig, vissa av dessa gör samma sak som andra medan andra tjänar ett annat syfte.

Punkten jag jobbar mot är denna:

När hindrar verktygen vi använder för utveckling vår förmåga att bygga något och leverera något effektivt?

Det är något med vårt område som tvingar oss att känna behovet av att hålla oss på teknikens blödande kant. Men jag tror att det finns en viktig skillnad att göra: Det är en sak att vara medveten om ett verktyg, men det är en sak att använda det.

Medvetenhet

Det fantastiska med att veta att något är tillgängligt är att vi har förmågan att undersöka det och avgöra om det är till någon nytta för oss.

Det här är inte en banbrytande eller ny idé, men det är en sak som jag tror att vissa av oss går förbi. Istället för att forska och utvärdera hoppar vi ofta över det och ser hur snabbt vi kan använda det.

Att använda den

Fördelen med att använda något nytt är att vi får de fördelar – eller förväntade fördelar – som nämnda verktyg är tänkt att ge.

Faran med detta är att verktyget kanske inte finns på sex månader, ett år eller till och med två år och att tekniken som det syftar till att förbättra kan förändras samtidigt som det inte håller jämna steg.

Det är därför det är viktigt att hålla dig medveten om nämnda verktyg samtidigt som du avgör om det är användbart eller inte.

Om denna enkelhet

För att komma tillbaka till min ursprungliga poäng är dock detta: Om hur lång tid det tar dig att konfigurera, lära dig, utveckla, implementera och använda ett nytt verktyg i ditt arbetsflöde, tycker jag att det är värt att överväga om det verkligen är värt sitt tid i din hög med verktyg.

Kunderna kommer inte att bry sig om du använder vilket verktyg du än använder eller inte. De litar på att du är en god förvaltare av lösningen som de betalar dig för att implementera och en del av ansvaret att vara klok och flitig med din tid.

Om verktyget du använder hindrar detta ansvar på något sätt, kanske det inte är värt att använda för ett givet projekt.

Och det är i slutändan vad det handlar om för mig: om det jag använder hjälper mig att bygga den bästa möjliga lösningen utan att göra det på kundens bekostnad, så är det troligtvis värt att använda. För detta ändamål är den enklaste uppsättningen verktyg ofta allt som behövs och inget mer.

Annars kan det vara värt att undersöka för användning i ett framtida projekt men inte på din kunds tid.