Outside of the box denken

[Verwijderd]

Het leek me leuk om hier een discussie te starten.We programmeren allemaal om leuke dingen te bouwen. En om soms de dingen wat gemakkelijker te maken in ons leven door software te ontwerpen en schrijven. Maar wat ik meestal mis is het out of the box denken. Daarmee bedoel ik creatief denken om problemen op te lossen en dit dan om te zetten in software. Ik ben wel benieuwd hoe jullie dat zien en of jullie daarbij een speciale aanpak of visie erover hebben. Zelf vind ik het bijvoorbeeld lastig om problemen om te zetten in software en dan in de meest brede zin.

Dus kort gezegd: Hoe denken jullie out of the box met het bedenken van software.

Ik kon niet echt een juist forum vinden om het te vragen. Dus stelde ik hem hier ik hoor het graag of mijn topic verplaatst is.

[Puch-Maxi]

Ben bang dat ik je niet zo goed kan helpen, maar ik herken het probleem maar al te goed. Toen ik begon met programmeren moest ik het programma eerst op papier zetten, in pseudocode en dan zette ik dat om naar code. Tegenwoordig programmeer ik grotendeels uit mijn hoofd. Als ik er even niet uitkom dan zet ik het voor mezelf toch weer even op papier. Het is vooral een kwestie van ervaring en inzicht denk ik. Soms loop ik me ook te verbazen hoe sommige programmeurs de meest ingewikkelde code zo even uit hun losse pols schudden .

[Alain]

Één woord: Ervaring.

Als je het proces goed kent, weet je waar je kunt verbeteren en hoe ver je kunt gaan. Doen, leren, luisteren naar anderen en vervolgens je eigen mening vormen. Daarna is de uitvoering relatief simpel.

[The Eagle]

Wat ik wel eens ooit gedaan heb: Ik had obv functionele specs een flink aantal mogelijke combinaties van mogelijk voorkomende stuur waarden, Standaard geknipt voor een geneste if then else icm een while loop dus
Daar heb op papier eerst een tabel voor gemaakt. Daar zette ik kruisjes in welke combinaties uberhaupt voor konden komen, en welke niet.

Dat reduceerde die potentieel hele lastige lap code tot een paar simpele if statements. Kostte even een uurtje werk, maar dat is uiteindelijk bij de onderhoudbaarheid van de code dubbel en dwars terugverdiend. En zeker als er veel rijen data door geevalueerd moeten worde is het nog sneller ook

[NMe]

Verwijderd schreef op donderdag 19 juni 2014 @ 22:35:
Dus kort gezegd: Hoe denken jullie out of the box met het bedenken van software.

Stapje weg doen van het probleem en iets anders gaan doen. Na een tijdje weer met een frisse blik opnieuw naar het probleem kijken. Of het probleem tegen anderen aan stuiteren, want soms bedenken zij wel een oplossing die jij gemist hebt.

Ik sluit me er verder bij aan dat het voor een groot deel neerkomt op ervaring. Problemen kunnen uitsplitsen naar deelproblemen en elk van die kleinere probleempjes voor zich oplossen om tot één grote oplossing te komen is iets wat je pas na een paar jaar programmeren goed onder de knie hebt. En dat is toch wel essentieel voor het bedenken van oplossingen die "buiten de doos" bedacht zijn.

Overigens moet outside of the box denken geen doel op zich zijn. Je moet gewoon je probleem oplossen en pas als je oplossing niet voldoet moet je kijken of je niet iets anders dat minder voor de hand ligt kan toepassen.

[Kettrick]

NMe schreef op donderdag 19 juni 2014 @ 23:28:
[...]

Stapje weg doen van het probleem en iets anders gaan doen. Na een tijdje weer met een frisse blik opnieuw naar het probleem kijken. Of het probleem tegen anderen aan stuiteren, want soms bedenken zij wel een oplossing die jij gemist hebt.

Ik sluit me er verder bij aan dat het voor een groot deel neerkomt op ervaring. Problemen kunnen uitsplitsen naar deelproblemen en elk van die kleinere probleempjes voor zich oplossen om tot één grote oplossing te komen is iets wat je pas na een paar jaar programmeren goed onder de knie hebt. En dat is toch wel essentieel voor het bedenken van oplossingen die "buiten de doos" bedacht zijn.

Overigens moet outside of the box denken geen doel op zich zijn. Je moet gewoon je probleem oplossen en pas als je oplossing niet voldoet moet je kijken of je niet iets anders dat minder voor de hand ligt kan toepassen.

Naast jaren ervaring is het vooral een kwestie van een brede ervaring opdoen wil je echt out-of-the-box dingen oplossen.

Goed voorbeeld is een ( oud ) collega die in scala en volledig actor gebaseerd systeem in elkaar heeft gekleid om wat files te syncen via FTP. Voor hij aan dat project begon ( wat drie weken geduurd heeft.. ) heb ik hem al eens op lftp gewezen maar hij zat zo vastgeroest binnen de JVM dat een simpele unix oplossing "geen optie" was.

Wil je goed out-of-the-box kunnen denken moet je voor buiten je ( huidige ) comfort zone kijken en durven toegeven dat een simple oplossing ( misschien in een taal die je helemaal niet aanstaat ) de beste is.

[Zoijar]

Trieste waarheid is dat je dat wel of niet kan, en als je het niet kan het ook niet ineens gaat leren door wat tips... het kan komen met jaren ervaring, of nog steeds gewoon niet.

Verder is het natuurlijk een buzzword die het goed doet op de bullshit bingo. Veel geweldige oplossingen zijn gewoon lekker knus in de doos volgens tijdgeteste ontwerpen. Maar misschien dat iets simpel doen tegenwoordig dan ook weer out-of-the-box is... Want in een tijd waar alles buiten de doos moet zijn, is iets binnen de doos houden misschien wel echt erbuiten.

[ Voor 53% gewijzigd door Zoijar op 20-06-2014 00:12 ]

[Puch-Maxi]

Dat klopt wel, het is voornamelijk een manier van denken die je moet hebben. Er bestaat helaas geen gouden tip voor, tot op zekere hoogte kun je het zeker wel oefenen. De tip van NMe is wel een hele nuttige, soms is het probleem zo groot dat je het niet kunt overzien. Het helpt om het probleem in zo'n geval op te delen in kleinere deelproblemen, die je wel kunt oplossen. Wat ook werkt is om eerst de basisfunctie te maken en deze vervolgens verder uit te breiden, niet gelijk het ei van Columbus proberen te vinden. Iedereen is begonnen met spaghetticode!

[Tim Schuhmacher]

Vind het wel grappig dat ervaring hier veel genoemd wordt, juist ervaring krijg je door iets vaak te doen. Maar dat is, lijkt me, juist killing voor out-of-the-box denken.

[Verwijderd]

Van steeds dezelfde handeling doe je geen ervaring op. Ervaring krijg je door veel verschillende situaties tegen te komen. Daarmee wordt de gereedschapskist gevuld.

Mensen die steeds hetzelfde trucje doen zijn een gevaar voor de ICT. If all you have is a hammer, everything looks like a nail.

Waarom denk je dat de die-hard developers hier liever mensen laat nadenken over een probleem dan direct oplossingen aan te dragen?

Maar ik geloof niet dat het echt creatieve denkwerk is aan te leren. Sommige mensen hebben het, sommige mensen niet. Brede kennis is daarnaast ook erg belangrijk om eerder genoemde redenen. Ik ken zat mensen met op papier veel ervaring, maar dat er in praktijk niet uitkomt omdat ze niet naar het probleem kijken maar zich blindstaren op de eerste ingeving die ze kregen.

[Camulos]

Het eerste wat in me op kwam:
Overleg eens met een ander, en kom dan tot een voorschrijdend inzicht; waarbij alles kan veranderen zoals: initiele aannames, proces-stappen, gebruikte technologie, totaal plaatje, etc. Bij voorkeur is die "ander" niet een programmeur in hetzelfde straatje als jij (voorbeeld back-end en front-end dev; developer en inter-action designer; developer en business) .

Je zult toch alleen "ingevingen" krijgen indien je gaat sparren over mogelijke (conceptuele) oplossingen.

Indien je juist meer ervaring nodig hebt over hoe je iets kan oplossen, dan is het interessant om te zien hoe anderen het oplossen (wederom). Voorbeeld is bijvoorbeeld los eens problemen in Project Euler/Facebook Hacker Cup/ Google Code.. en lees hoe anderen dezelfde problemen (anders) hebben opgelost.

Persoonlijke ervaring met Project Euler was dat het concept/probleem simpel is, maar voor grote inputs moest je het "slim" oplossen omdat het anders niet snel genoeg uitvoerde. En dat is nu net out-of-the-box denken (alternatieven/optimalisaties bedenken) terwijl je je kennis en ervaring vergroot.

[Russel88]

Out of the box denken is een term waarbij ik toch de nodige vraagtekens zet. Kom af en toe exotische code tegen, is dat out of the box denken?
Ik probeer gewoon logische code te schrijven, eentje die een ander ook meteen begrijpt. In dit wereldje zijn er iets teveel cowboys die slim denken te zijn en gaan dan de meest onzinnige constructies bedenken.
Ik zou ook opteren om vooral binnen te box te denken

[adis]

Goede code schrijven en out of the box denken voor een oplossing vind ik twee verschillende dingen.
Out of the Box (proberen) te denken doe ik (persoonlijk) alleen als ik een oplossing moet vinden voor een probleem, ook som voor een terugkerend probleem.

Hoe doe ik dat, gewoon met potlood :-) en mijn notebookje van de AH. Stappen die ik probeer te volgen:

- Duidelijk hebben wat het probleem is.
- Oplossing eerder bedacht, opschrijven, kort en krachtig, mag pseudo code, maar mag ook functioneel.
- Dan even laten rusten, varieert van paar minuten tot paar dagen. Als je maar compleet met je gedachten weg bent van het probleem of de oplossing..
- Dan komt de moeilijke stap;
Lees het probleem en probeer de eerste stap(pen) van je oplossing op een compleet andere manier uit te denken en op te schrijven zodat je er met een 'bird-view' naar kan kijken en beoordelen. Ik doe dit meestal op mijn whiteboard thuis.

Soms probeer ik ook door te denken om te zien of er niet een achterliggende probleem vast te stellen. Pff moeilijke discussie TS! ;-(

[ZaZ]

Als de voor de hand liggende 'oplossingen' voor nieuwe moeilijke situaties zorgen ga ik altijd een sigaret roken en terwijl ik naar de voegen van het gebouw staar, komt meestal de 'klik'
Maar of ik dat nou aan moet raden?

[EvilItSelf]

Out of the box denken kan niet iedereen. De een is er beter in dan de anderen een beetje hetzelfde dat de een makkelijker in sociaal contact is dan de ander. Als je een out of the box idee nodig hebt zoek iemand op die in jou ogen goed is in het out of the box denken en vraag die persoon om hulp.
Daarnaast speelt ervaring een rol in het geven van een efficiënte methode om je vraagstuk te benaderen of om het efficiënt op te lossen. Zo heb je voor ieder soort vraagstuk wat je hebt diverse soorten mensen die je kan vragen.

[Pathogen]

De makkelijkste manier om tot OOTB oplossingen komen is meerdere, verschillende mensen inschakelen.
Niet alleen IT-ers, niet alleen mensen die de context van het probleem kennen.

Laat de context eens in zijn geheel weg! Soms is een generieke oplossing héél anders, maar werkt die juist weer wel heel goed.
Probeer het probleem te destilleren tot echt alleen het probleem. Hoe meer context, hoe meer je de box erbij pakt.

[Lethalis]

Ik merk dat het mij helpt om vooral met andere tools en platformen te gaan werken.

Soms kom ik iets tegen in Java op een Linux OS waarvan ik denk "hey dat is handig" en dat spoort mij dan aan om op mijn werk met .NET op Windows een soortgelijke oplossing te zoeken.

[Neverwinterx]

Ik denk soms zo ver out of the box dat ik terug in de box zit

Out of the box oplossingen komen bij mij meestal nadat ik er even niet meer mee bezig ben geweest, dan schiet er soms ineens wat te binnen.

[alaintje]

Als ingenieur (in opleiding *kuch*). Leer ik om te divergeren en vervolgens alle opties te beoordelen en zo weer te convergeren (zoals pathogen zegt, destileren, boil down to).
Dit kun je doen door de meest (in het eerste opzicht) volstrekt onlogische en onpraktische oplossingen gewoon allemaal uit te schetsen (gaat een beetje moeilijk met software wellicht, ik kan gewoon dingen schetsen). Dit wordt vaak aan de hand van 10 schetsen voor 10 concepten gedaan, zo kom je op ongeveer 100 ideeën. Deze ga je beoordelen en nog eens allemaal doornemen en vervolgens van alles een beetje bij elkaar rapen en tot een creatieve oplossing komen, vervolgens zou je de stap weer kunnen doen. Maar goed, je begrijpt denk ik waar ik heen wil: alles opschrijven wat in je op komt.
In het eerste opzicht lijkt het dodend en saai, en dat wordt het ook. Maar neem dan een stapje weg en kom er even later op terug (van minuten tot dagen en jaren ). Meestal vind je na een hele lang tijd (door ervaringen in andere gebieden) ineens hier een nog betere oplossing voor.

Zoals hierboven staat in andere reacties, even weg gaan van het probleem (na je eerste brainstorm, anders heet het uitstel haha). Ga op een andere plaats zitten dan waar je normaal je bevindingen doet (bos/park/kade i.t.t kantoor o.i.d.). Doe een wandeling en denk ondertussen (niet vergeten toch dingen op te schrijven!) aan je probleem.
Of nogmaals: zet het een tijd in de koelkast.

note: out-of-the-box, creativiteit, inzicht, sociaal worden, etc KUN je allemaal aanleren/verbeteren. Het een wat makkelijker als het ander. Maar het vergt vooral heel veel training en oefening. Er gaan meestal jaren overheen.

[ Voor 7% gewijzigd door alaintje op 20-06-2014 12:32 ]

[Caelorum]

alaintje schreef op vrijdag 20 juni 2014 @ 12:30:
[...] Doe een wandeling en denk ondertussen (niet vergeten toch dingen op te schrijven!) aan je probleem.[...]

Hoe vaak ik wel niet heb gehad dat ik onderweg was ergens naartoe en allerlei oplossingen bedacht en vervolgens 5-6 uur later weer thuis kwam en het allemaal ben vergeten. Een kladblok (+pen) meenemen is echt het allerbeste wat je kan doen bij een wandeling ^^

[Barryvdh]

Caelorum schreef op vrijdag 20 juni 2014 @ 13:51:
[...]

Hoe vaak ik wel niet heb gehad dat ik onderweg was ergens naartoe en allerlei oplossingen bedacht en vervolgens 5-6 uur later weer thuis kwam en het allemaal ben vergeten. Een kladblok (+pen) meenemen is echt het allerbeste wat je kan doen bij een wandeling ^^

Ik kan altijd goed nadenken als ik onder de douche sta

[Caelorum]

Ff je monoloog opnemen? ^^

[PolarBear]

Titelfixje? Het is outside (buiten) the box ipv out of the box. Out of the box is dat iets het uit de doos meteen doet, outside the box is buiten de gestelde kaders denken

[Verwijderd]

In mijn werk gebruik ik vaak een soort van reversed engineering voor problemen, ik werk dan bijvoorbeeld eerst in een testomgeving uit hoe de interface/applicatie/library zijn data zou moeten krijgen en vul deze statisch, waarna ik terugwerk naar een dynamische oplossing en een echt database datamodel.

Voordeel hiervan is ook dat de meeste delen van de library in principe los aan te sturen zijn, dus geen dependency hebben naar een database, waardoor het herbruiken van losse delen stukken beter gaat.

Ik heb wel gemerkt bij veel bedrijven waar ik gewerkt heb dat 'outside of the box' meestal meer leek op 'houtje-touwtje' code waarbij er allerlei manieren bedacht werden om om problemen die door legacy code ontstaan waren op te lossen.

[Pathogen]

Verwijderd schreef op maandag 23 juni 2014 @ 11:49:
In mijn werk gebruik ik vaak een soort van reversed engineering voor problemen, ik werk dan bijvoorbeeld eerst in een testomgeving uit hoe de interface/applicatie/library zijn data zou moeten krijgen en vul deze statisch, waarna ik terugwerk naar een dynamische oplossing en een echt database datamodel.

Voordeel hiervan is ook dat de meeste delen van de library in principe los aan te sturen zijn, dus geen dependency hebben naar een database, waardoor het herbruiken van losse delen stukken beter gaat.

Ik heb wel gemerkt bij veel bedrijven waar ik gewerkt heb dat 'outside of the box' meestal meer leek op 'houtje-touwtje' code waarbij er allerlei manieren bedacht werden om om problemen die door legacy code ontstaan waren op te lossen.

Dat is meer working around the box

[BikkelZ]

Aan de andere kant werkt het gros van de developers aan systemen die gewoon nauwelijks van elkaar verschillen qua technische uitdaging. Wat data op en neer scheppen tussen een UI en een database, al dan niet met een webservice er tussen. Je pikt de mensen er ook zo tussenuit die toch een uitdaging nodig hadden en met super inventieve oplossingen komen die totaal niet schalen en de code alleen maar lastiger te lezen maken voor een theoretische besparing in te kloppen code.

Voor mij is het organisch laten groeien van een applicatie icm constant refactoren en TDD beter dan een groot plan van te voren.

Waar ik wel uitdagingen tegen kom is in UI of algoritmes. Altijd mooi om iets 12x sneller te laten gaan doordat je een loop omkeert of een tussenarray kunt skippen. Of dat je app grafisch iets doet wat niemand anders doet. Vaak wordt dat getriggerd door iets wat een designer of een klant wil.

[ Voor 4% gewijzigd door BikkelZ op 23-06-2014 18:01 ]

[Verwijderd]

Pathogen schreef op maandag 23 juni 2014 @ 12:19:
[...]

Dat is meer working around the box

'Around' is theoretisch gezien ook buiten de doos

Eigenlijk vind ik 'Outside of the box' een beetje een marketing/bullshit-bingo term waar ik weinig mee kan. Meestal zijn de beste oplossingen die ik ken gewoon binnen de bestaande doos (lees : beperkingen/randvoorwaarden, bestaande omgeving/code) gemaakt door juist net even verder te denken dan anderen.

Ik zit op het moment ook door de code van een junior te bladeren die compleet om de bestaande code heen programmeerd en echt allerlei omwegen gaat bedenken (onderandere met javascript) om dingen die normaal gesproken simpel zijn voor elkaar te krijgen.

In weze is dit innovatief omdat het nog niet binnen het huidige platform gedaan werd ... echter is het best jammer dat er een hele solide basis is om dingen op te zetten en die uitbreidbaar/schaalbaar is waar ik best een hoop tijd en denkwerk in heb zitten.

'tis goed dat hij op vakantie is .....

[H!GHGuY]

out of the box?

Niet gewoon het probleem oplossen waar men mee afkomt, maar uitzoeken wat het echte probleem is en daar een oplossing voor aandragen. Dan krijg je meteen de stempel 'hij denkt out of the box".

out of the box is wat mij betreft niet meer dan: denkt verder dan zijn neus lang is. Draagt oplossing aan die "verrassen" omdat ze "meer" oplossen dan het aangedragen probleem.
Het betekent niet: komt met een allesomvattende (lees: complexe en niet onderhoudbare) oplossing af.

Hoe doe je dat?
De juiste vragen stellen. Elk deel van het probleem in twijfel trekken. En een goeie portie "5 why's".
Bij elke oplossing de vraag stellen: welk probleem los je op? en niet enkel bij elk probleem: welke oplossing heb ik hiervoor nodig.

[Verwijderd]

Apple "Think different"..

Nee, even serieus, het is een skill en een manier van denken die je kunt leren beheersen door middel van het krijgen van ervaring. Het is het leren "troubleshooten".
Word eens voor 3 maanden systeembeheerder of iets anders waarbij je om moet gaan met Servers (Linux VPS's is meer dan prima). Bij elk probleem moet er zo snel mogelijk een goede oplossing komen. Voor die oplossing moet je alsware al "out of the box" denken.

Dat is een beetje mijn idee van "out of the box". Oplossingen bedenken voor een specifiek probleem.

[ Voor 10% gewijzigd door Verwijderd op 25-06-2014 23:36 . Reden: Kleine toevoeging! ]

[Herko_ter_Horst]

Nog even een keer voor de duidelijkheid:

"Out of the box" = "zoals het uit de doos komt", oftewel: direct bruikbaar.
"Outside the box" = buiten de gebaande paden, vanuit een nieuw perspectief. Veel mensen zeggen inderdaad ook "thinking out of the box", maar dat lijkt me eigenlijk niet correct.

Stap 1 in dit proces is erachter komen wat jouw persoonlijke "box" eigenlijk is. De "box" wordt in mijn optiek gevormd door je ervaring, de regels en gewoontes waarbinnen men wil dat je werkt én de beschrijving van het probleem.

Zoals eerder al aangehaald: iemand kan zó vast zitten aan een bepaalde technologie/programmeertaal, dat hij oplossingen die daar geen gebruik van maken niet eens accepteert, laat staan dat hij ze zelf zou bedenken. Dat is een behoorlijk stevige box

Je bewust zijn van jouw box is een belangrijke voorwaarde voor het kunnen denken outside the box.

Stap 2 is dan om door je box heen te breken en vanuit een ander standpunt naar de box en het probleem te kijken.

Stap 3 is dan actief op zoek gaan naar de beste oplossing voor het probleem op basis van je ervaring, de regels en gewoontes waarbinnen men wil dat je werkt én de beschrijving van het probleem. Dit lijkt tegenstrijdig (zie stap 1), maar dat is niet zo.

"Thinking outside the box" is mijns inziens namelijk geen doel op zich, maar een manier om bewust om te gaan met je eigen (of opgelegde) limieten. Het heeft bijv. geen zin om heel "innovatief" voor een nieuwe programmeertaal te kiezen die mogelijk beter aansluit bij het probleemdomein, als niemand in het team ervaring heeft in die taal en het project volgende week (lees: gisteren) af moet zijn.

Thinking outside the box is mijn optiek een middel om bewust om te gaan met je eigen grenzen, te weten wanneer je over die grenzen heen moet gaan, en onderbouwd kiezen voor de best beschikbare oplossing. Het is voor mij ook geen vereiste voor de oplossing van alle problemen. Je kunt het gros van de problemen naar alle waarschijnlijkheid ook prima binnen je box oplossen. Maar op het moment dat je het gevoel krijgt dat er iets wringt, je er achter komt dat er eigenlijk een ander probleem onder je huidige probleem zit, of als je echt iets nieuws wilt verzinnen, zul je buiten je box moeten denken.

"Gewoon" een goede oplossing verzinnen o.b.v. je skills en ervaring vind ik dus geen goed voorbeeld van "thinking outside the box", juist omdat je skills en ervaring zo'n belangrijk onderdeel zijn van je eigen persoonlijke box. Je moet daar m.i. bewust doorheen breken.

[ Voor 14% gewijzigd door Herko_ter_Horst op 26-06-2014 14:13 ]

[Pathogen]

Oh mijn god, al dat gemierenneuk over de juiste definitie! Denk even buiten de box, dan snap je gewoon wat er bedoeld wordt...

De suggestie dat er een vast stappenpatroon is om dit te doen vind ik ook erg grappig

[Herko_ter_Horst]

Pathogen schreef op donderdag 26 juni 2014 @ 14:13:
Oh mijn god, al dat gemierenneuk over de juiste definitie! Denk even buiten de box, dan snap je gewoon wat er bedoeld wordt...

Sorry, pet peeve

De suggestie dat er een vast stappenpatroon is om dit te doen vind ik ook erg grappig

Hoezo? De meeste programmeertalen bestaan uit een beperkte set vrij simpele primitieven waarmee desondanks de meest complexe problemen kunnen worden opgelost.

Dus het is (binnen mijn box, uiteraard ) helemaal niet vreemd dat een complex probleem als buiten de box denken beschreven kan worden door een paar eenvoudige stappen. Bovendien: als je iets beters wilt, dan is dit stappenplan uiteraard recursief toepasbaar op zichzelf

[stefanass]

Pathogen schreef op vrijdag 20 juni 2014 @ 11:03:
De makkelijkste manier om tot OOTB oplossingen komen is meerdere, verschillende mensen inschakelen.
Niet alleen IT-ers, niet alleen mensen die de context van het probleem kennen.

Dit is voor mij 1 van de beste tips. Bij OOTB gaat het er volgens mij juist om dat je het probleem op verschillende manieren bekijkt, waardoor je (soms) tot een ongebruikelijke / slimmere manier het probleem weet op te lossen. Juist door het probleem te bespreken met mensen uit andere disciplines, zowel binnen als buiten IT, kan dit je een andere blik geven op het probleem en daardoor ook een andere oplossingsrichting geven. Ik heb zelf regelmatig baat gehad door over lastige problemen een brainstorm te houden juist met mensen van bv. test, beheer, devvers, maar ook mensen van sales, consultants of een product-owner.

[ Voor 0% gewijzigd door stefanass op 26-06-2014 14:40 . Reden: typos ]

[jeroen79]

Verwijderd schreef op dinsdag 24 juni 2014 @ 11:51:
Ik zit op het moment ook door de code van een junior te bladeren die compleet om de bestaande code heen programmeerd en echt allerlei omwegen gaat bedenken (onderandere met javascript) om dingen die normaal gesproken simpel zijn voor elkaar te krijgen.

Het kan natuurlijk zijn dat die junior netjes binnen zijn eigen doos zit te denken: Zelf vanaf 0 iets bouwen in plaats van een bestaand platform te gebruiken.
Dat bespaart een hoop tijd die je anders kwijt was aan het lezen en vragen over dat platform.

[TRON]

Zelf ben ik van mening dat het belangrijk is om er achter te komen wat het probleem achter het probleem is om op te lossen. Het is namelijk niet altijd noodzakelijk om oplossingen om te zetten in software.

Wat ik vaak bij mijn klanten doe is het schetsen van de processen die ten grondslag liggen aan de mogelijke software-oplossing. Daarin zie ik vaak dat een aantal elementen niet opgelost hoeft te worden met software, maar met het maken van afspraken en het toezien op de afspraken.

Ik denk dat men vaak meer tevreden zal zijn met een totaaloplossing (proces & afspraken & software) dan alleen met software.

[base_]

Bij ingewikkelde projecten kan UML erg veel helpen om vanuit verschillende standpunten naar een juiste programmastructuur toe te werken.

[drm]

offtopic:
Mag ik deze gelegenheid aangrijpen om het verschil aan te geven tussen de uitdrukkingen "thinking outside the box" en "out of the box"?

Thinking outside the box betekent: buiten de gezette kaders denken. (Box betekent hier: afgekaderd geheel)
Out of the box betekent: een kant-en-klare oplossing. (Box betekent hier: Doos, als in: "kartonnen doos", als je die open doet, dan zie je ineens dat je de oordopjes er gewoon bij kreeg (w00t!!))

/Taalpurist exit.

[Caelorum]

drm schreef op maandag 30 juni 2014 @ 22:23:

offtopic:
Mag ik deze gelegenheid aangrijpen om het verschil aan te geven tussen de uitdrukkingen "thinking outside the box" en "out of the box"?

Thinking outside the box betekent: buiten de gezette kaders denken. (Box betekent hier: afgekaderd geheel)
Out of the box betekent: een kant-en-klare oplossing. (Box betekent hier: Doos, als in: "kartonnen doos", als je die open doet, dan zie je ineens dat je de oordopjes er gewoon bij kreeg (w00t!!))

/Taalpurist exit.

Moet je het de volgende keer wel op tijd doen

Herko_ter_Horst schreef op donderdag 26 juni 2014 @ 14:05:
Nog even een keer voor de duidelijkheid:

"Out of the box" = "zoals het uit de doos komt", oftewel: direct bruikbaar.
"Outside the box" = buiten de gebaande paden, vanuit een nieuw perspectief. Veel mensen zeggen inderdaad ook "thinking out of the box", maar dat lijkt me eigenlijk niet correct.
[....]