🚀 go-pugleaf

Jaap Beetstra wrote:

> John Bokma wrote:

[snip ]

>> Flexibel vind ik een editor gemaakt voor Perl, die opeens ook perfect
>> werkt met elke willekeurige andere programmeertaal, taal, enz. Ok, nu
>> niet allemaal Emacs roepen :-D.
> 
> Als je dat opeens weglaat, ben ik het met je eens.

Dan zat het in het ontwerp ;-). Met opeens bedoel ik, de Perl editor is 
af, en plotseling blijkt die ook zonder de code aan te passen in te 
zetten als C, C#, XML enz editor, inclusief ondersteuning van de 
rarigheden van die talen (qua folding en kleuring b.v.).

> Een editor die zo
> aan te passen dat-ie ook werkt met een andere programmeertaal, in
> kortere tijd (zo kort mogelijk) dan een volledige rewrite.

Precies, en ik weet van geen software die dat doet. 

> Software die opeens buiten specs werkt ken ik ook niet,

Grappig, ik dacht juist dat alle software dat deed ;-)

> maar software
> die uit te breiden is zie ik gelukkig nog wel eens.

uit te breiden, ja. Probleemloos, nee. En als het uit te breiden is, is 
het vaak binnen nauwe grenzen. Zodra je iets verder wilt moet er altijd 
iets sneuvelen.

>> Precies, en flexibiliteit bereik je niet met minimaal gezeur. Dat is
>> bloed, zweet & tranen. Ontwerpen, prototype, terug naar de
>> tekentafel, etc.
> 
> Hee, prototype, code in de ontwerpfase :)

Ik heb hopelijk ook nergens beweerd dat dat niet mocht :-). Overigens 
mag dat prototype best een wegwerp iets zijn (b.v. een GUI gemaakt in 
een klik-klak programma).

>> En dan zat het of in het ontwerp, of heb je stiekem dingen aan zitten
>> passen (ik sluit 100% geluk even uit).
> 
> Yep, het zat in het ontwerp, of ik heb zitten refactoren. Maar het
> ontwerp is bij mij niet het resultaat van een ontwerpfase, maar van
> continu ontwerpen tijdens een iteratief ontwikkelproces.

Ik heb dat te vaak (ook bij mijzelf) fout zien gaan. De project-
documentatie is dan de source en zo. De documentatie is de source, alles 
is de source.

Mijn ervaring is dat bij veel projecten x tijd eerst niet achter de 
computer zitten flink tijd bespaard. En x tijd is dan niet 5 minuten :-
D.

> Maar als een klant vraagt om UltraEdit,

Dan stuur ik 'm naar www.ultraedit.com  :-D.

> waarom zou ik hem dan een jaar
> laten wachten tot alles af is? Na twee weken (oid) kan hij NotePad
> krijgen,

Nah, zie je nu wel dat eerst nadenken echt helpt? Notepad zit als source 
bij Visual C++ van MS. (Ik weet niet of het 100% de source is, maar wel 
een berg) ;-) Met een beetje snel hacken kan je vast na 1 week iets meer 
dan Notepad laten zien ;-)

> waar hij alvast zijn eerste klusjes mee kan doen. Na een
> maand of 2-3 heeft hij de 20% van de functies die hij 80% gaat
> gebruiken. Na een jaar het totaal. En zelfs al is het na 15 maanden,
> omdat refactoren meer tijd kost dan gedacht, dan heeft hij al 12
> maanden lang op 80% kunnen werken, tegen anders 3 maanden op 100%.

Maar goed, ik snap je verhaal, maar het kan volgens mij beter:

De klant vraagt om UlraEdit

Er wordt vervolgens een eisenpakket gemaakt, en uitgezocht wat de 
opdrachtgever precies wilt. (ca. 1-2 maanden).

Er wordt een prototype [1] gemaakt (dat kan zelfs getekende windows 
zijn, of iets met een GUI toolkit in elkaar gezet, of een hack op een 
bestaande (Open Source) editor [2]). Feedback wordt verder verwerkt.

Er wordt een ontwerp gemaakt wat volledig het eisenpakket afdekt van de 
opdrachtgever, ca. 1 maand.

1 maand coderen

Na 4-5 maanden heeft de opdrachtgever iets wat 100% aan de *nieuwe* 
eisen voldoet [3], maar geen UltraEdit is.

Klinkt wellicht gek, maar ik krijg regelmatig opdrachten waar men een 
vaag idee heeft van wat het moet worden, maar na een serieuze 
ontwerpfase komt er een ander, en ik hoor nogal eens beter, produkt uit.

Ik werk ook wel eens op jouw manier, maar ik merk dan dat dat altijd 
frustrerend werkt voor beide partijen. Het lijkt telkens bijna af, maar 
dan moet er net weer iets anders. En zeker met meerdere ontwikkelaars 
kan dat erg lastig worden, want wiens code moet omgehackt worden? Een 
mooi voorbeeld uit een grijs verleden:

In de GUI library was ergens een rekenfoutje gemaakt, en dingen moesten 
3 pixels opgeschoven (of zo iets, erg grijs verleden). Het voorstel was 
om dat probleem maar in de aanroepende code (ben even kwijt hoeveel 
bestandjes, maar veel) te fixen door ergens 3 af te halen (hoe ga je dat 
documenteren...) . De library ontwikkelaars hadden het namelijk te druk 
(met hun ego, of zo).


[1] Maak duidelijk dat het het topje van de ijsberg is, en niet bijna 
    klaar.

[2] Een van de dingen die ik altijd doe is uitzoeken hoeveel ik ergens 
    anders vandaan kan halen, al dan niet Open Source.

[3] Omdat alles tot in den treure is besproken is de kans dat het uit te 
    breiden is op nieuwe eisen redelijk.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html