Archief - [ALG]SE Software "engineering"

QplQyer · 12 jan 2007

Na het lezen van een tekst op de site van kwitters (http://dewitters.koonsolo.com/sejoke.html), die lijnrecht tegenover mijn ideëen ingaat, moet ik wel reageren. En aangezien hier misschien wel een interessante discussie uit voortvloeit, leek het mij gepaster om het in een thread te gooien.

De tekst:

Koen Witters zei:
Software Engineering is a Joke.

During my studies at the university we had a course called "Software Engineering". The professor of this course strongly believed in the fact that software development would soon evolve in an engineering practice, with strong rules and metrics that will make the development itself more controllable. A specified process will guide all people involved and will eventually guarantee quality. This quality would then be evaluated with other metrics and stuff.

Unfortunately for him and for everyone who wants to become a "Software Engineer", software development and engineering are, even at the most fundamental parts, completely different. Engineering is the practice to develop something touchable, something that obeys the laws of physics. This implies that the product produced can be evaluated with the laws of physics. You can make all kinds of statistics, strength calculations, etc on the product. Engineers can therefore define their requirements with physical attributes, and so they can also be evaluated this way.

Software on the other hand, doesn't obey the laws of physics, by the simple reason because it can't be touched. Sure, it has physical parts, but those physical parts are not that important. Do you think you click on buttons in your desktop environment? Think again, the only thing you click is the button of your mouse, and the virtual push on the button projected on your monitor is just an illusion. Yet it looks, feels and even smells like a real button, great isn't it?

Programmers, just like artists, try to represent the world. They don't model or create real physical objects, they just try to capture a part of the world in an illusion. Programmers do this in both the source code and the final program. The better you can capture the world in your source code, the more understandable it will be. Source code only makes sense if you can imagine what it represents, what it does. Programs only make sense when the user knows what everyting represents: a button, a folder, a help manual. These are all representations of real world objects in a virtual environment, nothing more than an illusion.

The confusion of software engineering probably comes from the fact that programmers often have the same intelligence as engineers, and most of the time share the same interests. It's sometimes hard to make a distinction between programmers and engineers because of their simularities, but that doesn't mean that programming is therefore an engineering practice.

So to conclude: as a software developer you need the brains of an engineer, the writing capabilities of a poet and be able to represent the world like a painter. So don't believe the software engineering hype! So called "Software engineering techniques" can be applied and may be useful to you, but don't believe that they encompass everything. Painters, musicians and writers also use well known techniques, and engineering has nothing to do with it. Your knowledge, skills and most important your creativity and imagination are your greatest programming strengths, use them, because software is created, NOT ENGINEERD!

Koen Witters

Mijn antwoord hierop:

"Engineering betekent volgens de "free dictionary" het volgende:
"The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems."

Nergens wordt in de definitie van engineering verwezen naar de noodzaak aan fysische processen of enig ander. Het enige wat een ingenieur onderscheidt van een ambachtelijk persoon, is dat de ingenieur wiskundige modellen gebruikt om dat te beschrijven wat hij wenst te implementeren, waar de ambachtspersoon een systeem zal bouwen op basis van ervaring en "trial-and-error". Een ingenieur gaat daarentegen, voor hij het systeem bouwt, de specificaties omvormen naar een ondubbelzinnige specificatie (weg van de natuurlijke taal), in een wiskundig model, waarmee hij kan redeneren. Nadat hij de gewenste specificaties in het model heeft gestopt en de benodigde berekeningen uitgevoerd, zal hij de resultaten uit het model in de werkelijkheid transformeren.

Een klein voorbeeld:
De gemeente wenst een brug te bouwen over een rivier, die ruimte moet bieden voor 2 rijstroken en 2 fietspaden.
Een bouwkundig ingenieur zal deze specificaties omvormen naar een wiskundig model, door hier bijvoorbeeld 1m te nemen voor de breedte van een fietspad en 3m voor de breedte van een rijstrook. Deze parameters zijn ondubbelzinnig, en kan hij gebruiken in zijn wiskundig model, waarmee hij het aantal liter beton dat hij nodig heeft, welke betonsoort, en dergelijke meer gaat berekenen.
Nadat hij alles heeft berekend, wordt de brug gebouwd op basis van zijn berekeningen.

Zouden we dit voorbeeld ambachtelijk doen, dan zouden we wat beton bij elkaar klutsen op goed geluk, testen, het lijkt een week lang te blijven staan, het zal dus maar goed zijn (en drie maand later stort het in).

"Software engineering" beoogt het bovenstaande proces te gebruiken om software te ontwikkelen. In jouw tekst schrijf je dit af als op voorhand mislukt omdat het hier niet om concrete zaken gaat. Echter, het al dan niet concreet zijn van een zaak is geen voorwaarde om het bovenstaande proces te kunnen aanvatten. De enige voorwaarde is dat we waar we mee bezig zijn kunnen vatten in een wiskundig model (wat we bij software kunnen met behulp van de "formele methoden").

Software "engineering" momenteel gebeurt jammer genoeg inderdaad op de ambachtelijke methode, men schrijft een stuk code, men test het, ziet een fout, en verbetert de fout. Talloze uren gaan naar debuggen, testen en na deployment het fixen van de bugs die nog niet gevonden waren tijdens het testen (in plaats van naar nieuwe features te bedenken en te implementeren).

Met echte software engineering zou dit niet het geval zijn, daar zouden we de specificaties ondubbelzinnig kunnen neerschrijven in ons model, en kunnen controleren of het programma dat we hebben neergeschreven, er wel degelijk aan voldoet.

Conclusie: software engineering is geen op voorhand gefaald paradigma, maar een noodzaak om het softwareproductieproces betrouwbaarder te maken. We moeten afstappen van het "kunstige", of beter "gekunstelde" software-maken en overstappen naar een professionelere manier van software bouwen.

Enkele referenties:
http://klabs.org/richcontent/verification/holloway/nasa-97-16dasc-cmh.pdf
http://www.cs.ou.edu/˜beseme/besemePres.pdf

--
De discussie is dus: kan software development tot een "engineering practice" gemaakt worden.

Asshen · 12 jan 2007

Waarom zou je nou net wat de job van een programmeur leuk maakt eruit willen halen ?

Het feit dat je creatief moet zijn met code is het enige wat me draaiende houdt. Ik laat bandwerk liever aan anderen over

K.

QplQyer · 12 jan 2007

Dit heeft niks met het wegnemen van creativiteit te zien ... absoluut niks. Ingenieurs doen nu toch ook geen bandwerk me dunkt?

Emerxill · 12 jan 2007

Ik vind dat die mens ergens gelijk heeft. Bij engineering kunt ge door uw mathematische berekeningen meestal tot redelijk realistische en bruikbare materie komen omdat deze gestaafd moeten worden met de fysica. Als de wiskundige modellen voor een brug niet kloppen zal ze instorten.
Bij software engineering kunt ge zonder deftige modellen een werkende applicatie maken of omgekeerd moet een developer soms adhv een model dat op niks trek een werkende applicatie zien te bouwen, meestal dmv zijn creativiteit en trail en error.

Bubbling Zombie · 12 jan 2007

Beste manier (imo) is en blijft test driven development

Cad@verKe · 12 jan 2007

engineering heeft niks met bandwerk te maken

software zal nooit bandwerk zijn want bandwerk voor software = ctrl+c / ctrl+v
ontwikkelen van software is elke keer opnieuw (in beperkte maten) een uniek proces, elke applicatie wordt op een andere manier gebouwd, iets bouwen wat reeds bestaat wordt niet vaak gedaan en is ook vrij nutteloos want hoe ga je je product verkopen als het al bestaat, elke programma moet op zich toch wel iets unieks zijn om aantrekkelijk te zijn voor de consument

engineering heeft ook veel met organisatie te maken, hoe kan je groepen van mensen vlot laten samenwerken aan een gezamelijk project, en op gebied van programmeren zijn technieken als MVC of het drie-lagen systeem ook een soort van engineering methodes

trial-en-error is haalbaar op kleine schaal, maar als je aan een groot project werkt moet er toch wel een voorop gebouwde methode en aanpak opgesteld worden, engineering dus

dJeez · 12 jan 2007

Bubbling Zombie zei:
Beste manier (imo) is en blijft test driven development

Laat unit testing nu imho net eigenlijk een equivalent zijn van het wiskundige model dat de bouwkundige ingenieur hanteert om zijn brug te bouwen. Je toetst je applicatie aan de test, als de test faalt moet je terug naar het tekenbord (je IDE

), om daar verder te sleutelen aan de applicatie tot de test klopt.

Zoals QplQyer al aanhaalde: niets (regelgeving terzake even buiten beschouwing gelaten) belet trouwens dat een bouwkundig ingenieur in het wilde weg een brug gaat bouwen (de stabiliteit van het bouwsel is dan uiteraard niet verzekerd), net zoals niets je verplicht om een bepaalde methodologie te hanteren bij het programmeren - en ook hier kan dat een serieuze weerslag hebben op de stabiliteit van de applicatie.

Bubbling Zombie · 12 jan 2007

dJeez zei:
Laat unit testing nu imho net eigenlijk een equivalent zijn van het wiskundige model dat de bouwkundige ingenieur hanteert om zijn brug te bouwen. Je toetst je applicatie aan de test, als de test faalt moet je terug naar het tekenbord (je IDE ), om daar verder te sleutelen aan de applicatie tot de test klopt.

Tenzij dat je natuurlijk eerst je test schrijft, en dan je software schrijft gebaseerd op die testen.

QplQyer · 13 jan 2007

Bubbling Zombie zei:
Tenzij dat je natuurlijk eerst je test schrijft, en dan je software schrijft gebaseerd op die testen.

Bubbling Zombie zei:
Ik vind dat die mens ergens gelijk heeft. Bij engineering kunt ge door uw mathematische berekeningen meestal tot redelijk realistische en bruikbare materie komen omdat deze gestaafd moeten worden met de fysica. Als de wiskundige modellen voor een brug niet kloppen zal ze instorten.
Bij software engineering kunt ge zonder deftige modellen een werkende applicatie maken of omgekeerd moet een developer soms adhv een model dat op niks trek een werkende applicatie zien te bouwen, meestal dmv zijn creativiteit en trail en error.

Zelfs zonder deftige wiskundige modellen voor een brug kan men een brug bouwen, op goed geluk en door trial and error. Maar het gaat minder kosten wanneer men op voorhand berekent wat men nodig heeft en hoeveel van alles.

Vergelijk het desnoods met andere ingenieurs-activiteiten, werktuigkunde bijvoorbeeld, met lego technic kan je ook zaken bouwen zonder ze te modelleren, maar met een model heb je meer garantie dat wat je bouwt juist is en altijd zal doen wat je ervan verwacht (je kan het model immers valideren).

Unit-tests zijn een vorm van controle (en model), maar ze zijn ook maar beperkt tot de invoer die de test genereert. Zoals Dijkstra al zei "testen is voldoende om de aanwezigheid van fouten aan te tonen, maar niet afdoende om hun afwezigheid aan te tonen".

Overigens is het niet omdat iets ambachtelijk ook zou kunnen, dat het niet nodig of zinvol is om naar een gestructureerdere aanpak over te gaan.

Bubbling Zombie · 13 jan 2007

QplQyer zei:
Unit-tests zijn een vorm van controle (en model), maar ze zijn ook maar beperkt tot de invoer die de test genereert. Zoals Dijkstra al zei "testen is voldoende om de aanwezigheid van fouten aan te tonen, maar niet afdoende om hun afwezigheid aan te tonen".

Overigens is het niet omdat iets ambachtelijk ook zou kunnen, dat het niet nodig of zinvol is om naar een gestructureerdere aanpak over te gaan.

very true. Je moet natuurlijk ook wel mensen hebben die competent zijn qua testen schrijven en dergelijke meer. Je kan ook twee soorten testen gebruiken: de gewone unit tests ( 1 + 1 = 2 ) en acceptance tests (de onderbroek slaagt groen uit als de maan achter venus staat). Heeft altijd wel gewerkt. Je moet natuurlijk wel weten met wat je bezig bent. Overal gewoon Assert.IsTrue() schrijven is nogal lame-o en weinig effectief.

kwitters · 13 jan 2007

Aha, eindelijk eens iemand met wat commentaar op dat provocerend artiekelke

.

QplQyer zei:
Met echte software engineering zou dit niet het geval zijn, daar zouden we de specificaties ondubbelzinnig kunnen neerschrijven in ons model, en kunnen controleren of het programma dat we hebben neergeschreven, er wel degelijk aan voldoet.

Hier kom je echt tot de essentie van de zaak: Software engineering oogt op "ondubbelzinnige requirements", "wiskundig implementeren van requirements", en dan "valideren van requirements met implementatie". In een academische wereld klinkt dit allemaal heel mooi, maar spijtig (en bij mensen die coden voor't plezier gelukkig

) blijft dit allemaal maar theorie. In mijn wereld krijg ik te maken met klanten die niet weten wat ze willen, en als ze het weten zullen ze wel van gedacht veranderen. Ik moet interfaces schrijven die "intuitief" aanvoelen en die "fijn" zijn om mee te werken. En voor games moet ik dingen "fun" maken. Ik moet code schrijven die makkelijk te begrijpen is voor andere programmeurs, die flexibel is voor toekomstige, ongekende requirements/systemen/ports etc. Om dan nog maar te zwijgen over allerhande afwegingen die je moet maken: maak ik de code robuust of correct, maak ik de code leesbaar of optimaal, welke programmeertaal is het meest geschikt, welke library gebruik ik best, ... . Als jij wiskundige formules weet om zaken te berekenen zoals "intuitieve interface", "fun factor", "flexibel naar toekomst toe", "begrijpbare code", "optimale library", etc, dan mag je die mij altijd vertellen.

Kijk, ik zal je proberen duidelijk te maken wat juist het "artistieke" aan software development is: software (vooral high-level dingen) is een "venster" op te wereld. Het beeldt een stukje af dat wij kunnen begrijpen als zijnde iets van de wereld. "ceci n est pas une pipe" zou evengoed "this is not a button" kunnen zijn

. Dit is uiterst subjectief, en dat deel is wiskundig niet berekenbaar. Hetzelfde voor de code: de leesbaarheid van de code is uiterst subjectief. Wat is het meest leesbaar: button_count, nButtons, MAX_BUTTONS, x of Variabelke. Probeer dat maar eens wiskundig te berekenen (veel geluk

).

QplQyer zei:
Conclusie: software engineering is geen op voorhand gefaald paradigma, maar een noodzaak om het softwareproductieproces betrouwbaarder te maken. We moeten afstappen van het "kunstige", of beter "gekunstelde" software-maken en overstappen naar een professionelere manier van software bouwen.

Software engineering is een op voorhand gefaald paradigma. Een brug is geen venster op de wereld, het is een object in de echte wereld. Software is een illusie op een scherm, en code is de menselijk begrijpbare beschrijving van de werking. "scientific and mathematical principles" hebben op dat deel van de development niets te zoeken, het gevoel van de programmeur hoe duidelijk, leestbaar, fun iets is zal de kwaliteit bepalen.

Nog een laatste statement: code is de interface tussen computer en mens. Het deel code-computer is wiskundig en logisch berekenbaar, het deel code-mens is uiterst subjectief. En het is o.a. dit laatste deel dat nooit tot "engineering" kan behoren.

Vich · 13 jan 2007

Sowieso is software engineering en software engineering 2. Het ene bedrijf is het andere niet. Bij het ene bedrijf ga je enkel als een code monkey kleine opdrachten aannemen en is het seriewerk, terwijl je bij een ander bedrijf juist een mooi geheel kan afwerken. Bij het ene bedrijf ga je enkel code schrijven, terwijl je bij het andere ook mag meedenken aan het ontwerp. Bij het ene bedrijf heb je een klant die jou zegt wat hij wil (en niks anders!), terwijl je bij het andere bedrijf meer mag meekneden aan het product.
Bij het ene bedrijf ben je een programmeur die dingen mag implementeren, bij de andere ben je eentje die enkel bugs mag fixen. Bij het ene bedrijf krijg je tijd om je creativiteit te ontplooien, terwijl je bij het andere bedrijf enkel deadline-gericht werkt. etc.

Ik vind dat de meeste reacties hier allemaal een kern van waarheid hebben, het hangt er gewoon vanaf op wat jouw specifieke visie is van wat software engineering is.

kwitters: kan je me zeggen wat je met "het deel code-mens" bedoelt?

kwitters · 13 jan 2007

Vich zei:
kwitters: kan je me zeggen wat je met "het deel code-mens" bedoelt?

Het is in feite het deel van de code dat begrijpbaar is voor een mens: identifiers etc. We proberen eenerzijds code zo dicht mogelijk bij onze menselijke "taal" te brengen, zodat we kunnen zien wat er juist gebeurt. Als het deel code-mens niet nodig was dan programmeerden we nu zonder problemen in machine-taal.

Vich · 13 jan 2007

kwitters zei:
Het is in feite het deel van de code dat begrijpbaar is voor een mens: identifiers etc. We proberen eenerzijds code zo dicht mogelijk bij onze menselijke "taal" te brengen, zodat we kunnen zien wat er juist gebeurt. Als het deel code-mens niet nodig was dan programmeerden we nu zonder problemen in machine-taal.

Dat is gewoon een kwestie van oefening. De eerste computers werden zelfs op een lager niveau dan assembler geschreven, door rechtstreeks hexadecimale in te voeren.
Een taal of vertaalslag creëren is nog steeds puur engineering. Highlevel programmeercode is best ook te analyseren door een computer (bvb code>uml en uml>code software).

Naar mijn mening heeft goed kunnen programmeren zeer weinig met creativiteit te maken: goed kunnen programmeren is een behoefte van een klant kunnen omzetten naar een set van theoretisch samenhangende regels.
Anderzijds kan programmeren wel een creatieve bezigheid zijn door mee te doen aan het uitdenken van het programma zelf. Ook kan je creatief omgaan met algoritmes, maar dit soort van creatief bezig zijn is volgens mij niet te vergelijken met een artist. Je kan het zeg maar niet aan de muur hangen en het is enkel creatief voor mede-programmeurs. Je hoeft echter geen schilder te zijn om een schilderij mooi te vinden of een dichter om een gedicht te begrijpen.

[edit] Sowieso moet je ook naar de context bekijken: multimedia software programmeren lijkt creatief omdat je een systeem maakt dat art weergeeft. Het is en blijft echter programmeren, alleen ervaar je het anders, vanwege de context van het project.
Ook krijg je in een multimediaproject vaak ook overlapping van taken: je zal als programmeur eventueel mockup textures of levels maken en dat geeft natuurlijk direct een meer creatief gevoel aan je job.

(en dit bedoel ik niet als waarheid, maar als mening, hoe ik ertegenaan kijk)

[edit] lol, ik zie nu pas de naam van het html bestand

kwitters · 13 jan 2007

Vich zei:
Dat is gewoon een kwestie van oefening.

Yeah right, ik ken niemand die vlot de hexadecimale instructies leest uit een exe. Zelfs crackers grijpen terug naar assembler.

De eerste computers werden zelfs op een lager niveau dan assembler geschreven, door rechtstreeks hexadecimale in te voeren.

Daarmee dat ik ook machine-code zei en niet assembler...

Highlevel programmeercode is best ook te analyseren door een computer (bvb code>uml en uml>code software).

Een computer begrijpt de context niet.

Je hoeft echter geen schilder te zijn om een schilderij mooi te vinden of een dichter om een gedicht te begrijpen.

Je hoeft geen game-programmeur te zijn om van een game te genieten, je hoeft geen scripter te zijn om op een forum rond te hangen. Je hoeft geen library developer te zijn om een API duidelijk te vinden.

Misschien hebben schilders en programmeurs wel meer gemeen dan je denkt

.

killgore · 13 jan 2007

kwitters zei:
Hier kom je echt tot de essentie van de zaak: Software engineering oogt op "ondubbelzinnige requirements", "wiskundig implementeren van requirements", en dan "valideren van requirements met implementatie". In een academische wereld klinkt dit allemaal heel mooi, maar spijtig (en bij mensen die coden voor't plezier gelukkig ) blijft dit allemaal maar theorie. In mijn wereld krijg ik te maken met klanten die niet weten wat ze willen, en als ze het weten zullen ze wel van gedacht veranderen. Ik moet interfaces schrijven die "intuitief" aanvoelen en die "fijn" zijn om mee te werken. En voor games moet ik dingen "fun" maken. Ik moet code schrijven die makkelijk te begrijpen is voor andere programmeurs, die flexibel is voor toekomstige, ongekende requirements/systemen/ports etc. Om dan nog maar te zwijgen over allerhande afwegingen die je moet maken: maak ik de code robuust of correct, maak ik de code leesbaar of optimaal, welke programmeertaal is het meest geschikt, welke library gebruik ik best, ... . Als jij wiskundige formules weet om zaken te berekenen zoals "intuitieve interface", "fun factor", "flexibel naar toekomst toe", "begrijpbare code", "optimale library", etc, dan mag je die mij altijd vertellen.

Alles wat jij hier opnoemt heb je wel degelijk bij andere ingenieurstakken ook en hebben minder te maken met engineering als wel de grilligheden van mensen hoor. Er moeten altijd keuzes gemaakt worden, deze kunnen geoptimaliseerd worden door wiskundig-wetenschappelijke berekeningen in sommige gevallen, maar uiteindelijk kan men vaak genoeg nog verkeerde keuzes maken. Of je nu aan een brug werkt of aan een programma.
Hetzelfde over die opmerkingen over "de klant", daar wordt natuurlijk op academisch niveau mooi over gezwegen, maar heb je meer dan gelijk in, maar weerom: dat geldt zeker niet enkel voor software development. Een elektrotechnieker gaat ook keuzes moeten maken waar ie zot van komt door klanten. Heb daarover enkele maanden geleden nog een best interessant artikel gelezen (tiens, vo univ zelfs

) over een project leader van de pentium 3 of 4, hoe die zot werd door eisen van enerzijds bedrijven die servers op de markt brengen, andere die end-user modellen maken, dan weer mensen die het op academisch/R&D niveau nodig hebbern, ...

kwitters zei:
Kijk, ik zal je proberen duidelijk te maken wat juist het "artistieke" aan software development is: software (vooral high-level dingen) is een "venster" op te wereld. Het beeldt een stukje af dat wij kunnen begrijpen als zijnde iets van de wereld. "ceci n est pas une pipe" zou evengoed "this is not a button" kunnen zijn . Dit is uiterst subjectief, en dat deel is wiskundig niet berekenbaar. Hetzelfde voor de code: de leesbaarheid van de code is uiterst subjectief. Wat is het meest leesbaar: button_count, nButtons, MAX_BUTTONS, x of Variabelke. Probeer dat maar eens wiskundig te berekenen (veel geluk ).

Hier weer het zelfde, dit heeft niets te maken met SE zoals jij het voorstelt. Anderzijds weer met een andere interpretatie van software engineering die idd duidelijke & aanpasbare code beoogt, dit is echter imho eerder een populaire term die op zich niets met het begrip ingenieur te maken heeft.

SE slaat erop hoe een programma in elkaar moet zitten, welke algoritmes je gebruikt en meer nog, welke aanpak je het best gebruikt als je een algoritme moet zoeken. In deze context is engineering perfect mogelijk. Bv het gebruik van grafentheorie is bij programmastructuur & algoritmen extreem nuttig.
Andere vbn, het moet niet altijd puur wiskundig zijn om onderdeel uit te maken van engineering: ook design patterns zijn onderdelen van software engineering hoor.

Ook gebeurt een groot deel van software-engineering naast het echte developpen. De software ingenieur zal veel eerder een algemeen concept uitwerken, het echte programmeren echter wordt overgelaten aan "gewone" programmeurs. Net zoals een bouwkundig ingenieur niet zelf gaat metsen. Deze "gewone" programmeurs moeten dan nog steeds over enkele "creatieve" vaardigheden beschikken zoals jij zegt, zoals daar is duidelijke code schrijven.

Ik geef je volkomen gelijk dat software development niet puur kan gebeuren door software engineering. Maar op dat vlak geldt dit voor zowat elke ingenieurstak. Ik heb het vb gegeven van een bouwkundig ingenieur wiens werk ook nog steeds afhangt van kwaliteit van metsers. Ook een elektrotechnisch ingenieur zijn werk hangt af van de mensen die uiteindelijk de chips en zo zullen produceren, hoe goed zijn ontwerp ook is ... .
Maar als anderzijds de software ingenieur al op voorhand, onder andere met de hulp van wiskundige modellen bepaalt hoe het programma moet werken, welke algoritmes erin moeten en welke structuur je moet hebben, er zal toch veel minder tijd aan testen verloren gaan. Dat dit laatste (structuur) iets minder wiskundig bepaald kan worden -> akkoord, maar dit wilt niet zeggen dat het onmogelijkis bepaalde technieken (ik heb design patterns al vermeld) niet kan gebruiken om het op een vrij deductief kan bepaald worden. Het is ook zeer belangrijk dat hij/zij een immense "gehele" kijk op het software pakket heeft.
Maar dat wilt niet zeggen dat er voor een bepaald, voornamelijk "ontwerpend" deel geen ingenieurstoepassingen kunnen gebruikt worden. Voor computerwetenschappen staat dit nog in zijn kinderschoenen, als ik zelf kijk naar het aanbod dat ze nu aan cw'ers geven bij ons en vergelijk met 5 jaar geleden of zo (via keats) dan is dat al zeer zwaar veranderd, zeer waarschijnlijk om die reden.

edit: interessante discussie wel

.

EraSerX · 13 jan 2007

Witters, je mist het punt van software engineering compleet in uwen tekst. Het doel van engineering is een model/systeem/techniek te voorzien zodat verschillende mensen aan eenzelfde project kunnen werken. Een ingenieur die een brug bouwt, doet net hetzelfde. Hij zorgt voor een plan dat een team van metselaars kan lezen en implementeren, hij gaat zelf geen steen aanraken.
Software Engineering doet net hetzelfde. Die zorgt voor design patterns en ander leuk speelgoed zodat een team van coders functioneel en efficient een design van een engineer kan implementeren. Als je dat niet doet en 20 man aan een project laat werken zonder plan, gaat uw huis of programma niet echt lang rechtstaan.

Jij werkt in een bedrijf waar een klein team aan diverse projecten werkt en daar lukt het nog zonder dergelijke Engineering technieken. In grote bedrijven zoals banken heb je zo een Software Engineer nodig of alles loopt in de soep. Wat niet wegneemt dat je nog altijd creatieve coders nodig hebt om de boel te implementeren...

as a software developer you need the brains of an engineer, the writing capabilities of a poet and be able to represent the world like a painter

nie overdrijven eh, code is code, geen poezie en geen schilderij.. misschien goed gevonden en slim geschreven

QplQyer · 13 jan 2007

Hier kom je echt tot de essentie van de zaak: Software engineering oogt op "ondubbelzinnige requirements", "wiskundig implementeren van requirements", en dan "valideren van requirements met implementatie". In een academische wereld klinkt dit allemaal heel mooi, maar spijtig (en bij mensen die coden voor't plezier gelukkig ) blijft dit allemaal maar theorie. In mijn wereld krijg ik te maken met klanten die niet weten wat ze willen, en als ze het weten zullen ze wel van gedacht veranderen. Ik moet interfaces schrijven die "intuitief" aanvoelen en die "fijn" zijn om mee te werken. En voor games moet ik dingen "fun" maken. Ik moet code schrijven die makkelijk te begrijpen is voor andere programmeurs, die flexibel is voor toekomstige, ongekende requirements/systemen/ports etc. Om dan nog maar te zwijgen over allerhande afwegingen die je moet maken: maak ik de code robuust of correct, maak ik de code leesbaar of optimaal, welke programmeertaal is het meest geschikt, welke library gebruik ik best, ... . Als jij wiskundige formules weet om zaken te berekenen zoals "intuitieve interface", "fun factor", "flexibel naar toekomst toe", "begrijpbare code", "optimale library", etc, dan mag je die mij altijd vertellen.

Dergelijke afwegingen gebeuren, zoals killgore reeds zei, ook in andere ingenieurstakken en zijn niet de essentie van wat "engineering" is.

Bij een brug moet men dergelijke zaken ook doen, in de eerste plaats moet ze functioneel zijn (net als software). Maar ook daar zijn de specificaties niet ondubbelzinnig. Om het met mijn voorbeeld aan te tonen: "plaats voor twee fietspaden en twee rijstroken". Dat is duidelijk een redelijk vage omschrijving (hoe groot maak je een rijstrook, een fietspad? Welk soort wagens zouden voornamelijk voorbijrijden, vrachtwagens of voornamelijk personenwagens?), en de ingenieur zal daar een interpretatie van moeten maken die hij vertaalt in zijn wiskundig formalisme.

Daarenboven krijgt ook hij af te rekenen met zij-aspecten die hij niet kan berekenen, bv. op hoeveel cm hij een railing moet plaatsen als er een voetpad zou zijn, zodat de mensen niet te dicht tegen de rand moeten stappen, maar ook niet te dicht tegen de zijkant. Dat is ook iets wat niet te vertalen is in wiskunde en waar hij enigszins vage, abstracte begrippen als "goede plaatsing van de railing" gaat moeten omzetten en concretiseren.

Uiteindelijk doe je dus hetzelfde als een ingenieur. Je vertaalt vage specificaties zoals "intuitief", "fijn", naar een concrete, ondubbelzinnige vorm in een programma. Echter vertaal je dit onmiddellijk naar de eindvorm, waar bij traditionele ingenieurstakken deze eerst in een model worden gegoten. Ook bij software zou een model de moeite lonen, wegens het feit dat software schrijven een aardige som geld kost en verkeerde specificaties, of software die niet voldoet aan de specificaties dus nog meer geldkosten teweeg brengen.

Bij zaken zoals een "intuitieve GUI", kan men een tekening maken of een prototype, zo maakt men ook een tekening en een maquette van een nieuwe brug, om zeker te zijn dat het eindproduct zal voldoen aan de verwachtingen, voor men het eindproduct aflevert. Ook daar komen de zijvoorwaarden van een duidelijke tekening van de brug bij kijken, die voldoet aan afgesproken standaarden (zodat men niet denkt dat de schaal in meters is, terwijl de schaal eigenlijk in feet was).

Er is wel onderzoek bezig naar de wiskundige beschrijving van GUI's trouwens.

Kijk, ik zal je proberen duidelijk te maken wat juist het "artistieke" aan software development is: software (vooral high-level dingen) is een "venster" op te wereld. Het beeldt een stukje af dat wij kunnen begrijpen als zijnde iets van de wereld. "ceci n est pas une pipe" zou evengoed "this is not a button" kunnen zijn . Dit is uiterst subjectief, en dat deel is wiskundig niet berekenbaar. Hetzelfde voor de code: de leesbaarheid van de code is uiterst subjectief. Wat is het meest leesbaar: button_count, nButtons, MAX_BUTTONS, x of Variabelke. Probeer dat maar eens wiskundig te berekenen (veel geluk ).

Dat begrijp ik, en ik ontken niet dat er een stukje artiest-zijn nodig is om specificaties te kunnen vertalen in een ondubbelzinnige, virtuele vorm, noch dat niet alles berekenbaar is (maar dat is het evenmin in gelijk welke andere ingenieurstak). Maar dat verhindert niet dat we een tussenstap, voor het bouwen, kunnen invoegen, die deze specificaties vat. Een wiskundige modellering heeft in dat opzicht het voordeel dat men ook kan vaststellen of specificaties niet tegenstrijdig zijn met elkaar.

Software engineering is een op voorhand gefaald paradigma. Een brug is geen venster op de wereld, het is een object in de echte wereld. Software is een illusie op een scherm, en code is de menselijk begrijpbare beschrijving van de werking. "scientific and mathematical principles" hebben op dat deel van de development niets te zoeken, het gevoel van de programmeur hoe duidelijk, leestbaar, fun iets is zal de kwaliteit bepalen.

De kwaliteit (voor de eindgebruiker) wordt bepaald door de functionaliteit en hoe goed men specificaties heeft kunnen vertalen. Zoals uiteengezet is het daarom belangrijk om voor het bouwen van iets na te gaan of men wel degelijk de specificaties juist heeft verstaan, zodat men geen hele stukken moet herschrijven. Ook kan men dan nagaan of het bouwwerk dan wel voldoet aan de specificaties. Dat is het enige wat engineering inhoudt. Zoals de metser de vrijheid behoudt het metsen op zijn manier te doen, zo behoudt de programmeur de vrijheid om het programmeren op zijn manier te doen. Engineering komt inderdaad niet overal bij het bouwen kijken (na het tekenen van de brug is het aan de werfleider om de brug te bouwen, het model moet dan echter wel duidelijk zijn, anders kom je in de centimeters versus feet problemen terecht, zo moet een software-model duidelijk zijn), enkel in de design-fase, en het is net daar dat het wel degelijk mogelijk is om wetenschappelijke en wiskundige principes toe te passen.

Nog een laatste statement: code is de interface tussen computer en mens. Het deel code-computer is wiskundig en logisch berekenbaar, het deel code-mens is uiterst subjectief. En het is o.a. dit laatste deel dat nooit tot "engineering" kan behoren.

Het is net die subjectiviteit die voor veel problemen zorgt tijdens het coden. En die we door middel van "echte" software engineering trachten te elimineren voor het bouwen, zoals men beter geen brug bouwt zonder plan.

KeaTs · 13 jan 2007

Goh, ik denk dat dit weer zo'n discussie is over semantiek. Software-ontwikkeling omvat meer dan enkel implementatie, heel belangrijk is dat je eerst een deftig design hebt. Bij die design fase kan je ook bepaalde technieken gebruiken, maar uiteindelijk is dit de meest creatieve fase van de ontwikkeling en is dit het deel dat je niet helemaal formeel kan beschrijven en rigoureus kan testen, en waarschijnlijk ook het deel waar witters over struikelt. Daarna volg de implementatie, het eigenlijke programmeren. In de praktijk is dit vaak ook ambachtelijk, maar dit deel *kan* getoetst worden aan standaarden, getest worden op fouten en op functionaliteit. Witters z'n prof gelooft dat het mogelijk is dat in de toekomst er frameworks ontwikkeld worden waarin de kwaliteit van de code zelf perfect getest kan worden, en daarin heeft hij waarschijnlijk gelijk. De design fase blijft altijd een menselijke aangelegenheid (wel, zolang er geen echte AI bestaat, maar da's weer een andere discussie

).

De discussie rond de term engineering is ook semantiek imo. Bij veel ingenieurstaken komt er ook creativiteit bij kijken, en het is enkel het resultaat van die creativiteit die getest wordt. Het creatieve aspect is wel meer aanwezig bij software development naar mijn mening; als je dan toch een brug-metafoor wil, dan zou ik een software developer eerder gelijkstellen aan de architect, ingenieur en het constructieteam in een, gesteld dat hij betrokken is bij het hele proces van design tot implementatie.

kwitters · 13 jan 2007

Deze discussie kan nog eindeloos blijven doorgaan, dus ik ga zowat mijn laatste punt proberen duidelijk te maken.

We zijn er allemaal mee eens dat software development nog in zijn kinderschoenen staat. Aanhangers van software engineering geloven dat we nu in het stadium zitten zoals ingenieurs vroeger. Als men vroeger een brug wou bouwen dan deed men dit men dit zonder eerst sterkte berekeningen e.d. te maken. Software engineers geloven dat software development, net zoals engineering, moet evolueren naar meer formele methodes om software te bouwen, net zoals bruggen etc. Duidelijke specificaties -> implementatie -> valideren van implementatie, een mooi voorbeel van een typisch engineering waterfall model.

Ik, langs de andere kant, geloof dat software developers in het stadium zitten zoals schilders in de 15de eeuw. Zij moesten zich bezig houden met 2 soort zaken: langs de ene kant zeer technische dingen zoals het samenstellen van verven (het engineering gedeelte), en anderzijds het artistieke gedeelte (afbeelden van de wereld). Schilders zijn ondertussen weg geevolueerd van het technische maken van verf, en kunnen zich nu volledig concentreren op het afbeelden van de wereld.
Als ik naar de software development wereld kijk dan zie ik ook een evolutie die zich wegtrekt van technische zaken. Men evolueert naar programmeertalen die dichter bij de mens staan (python, java, ... ). Hoe minder de focus op het technische gedeelte gaat liggen, hoe meer de focus op het maken van duidelijke software en duidelijke code gaat liggen.

En ik ben heel blij dat momenteel in software development het typische waterfall model (dat in engineering meestal gebruikt wordt) achterwege wordt gelaten voor betere zaken zoals agile development, waar de focus duidelijk niet meer op processen, planning, op voorhand gedefinieerde requirements, etc. ligt.

Als jullie je beter voelen bij formele methodes, gespecifieerde processen en up-front ondubbelzinnige requirements, dan ga ik jullie plezier niet afpakken. Maar laat mij dan ook mijn coder-plezier hebben in het maken van verstaanbare code en software waar de gebruiker zich goed in voelt

.

Archief - [ALG]SE Software "engineering"

QplQyer

Legacy Member

Asshen

Legacy Member

QplQyer

Legacy Member

Emerxill

Legacy Member

Bubbling Zombie

Legacy Member

Cad@verKe

Legacy Member

dJeez

Legacy Member

Bubbling Zombie

Legacy Member

QplQyer

Legacy Member

Bubbling Zombie

Legacy Member

kwitters

Legacy Member

Vich

Legacy Member

kwitters

Legacy Member

Vich

Legacy Member

kwitters

Legacy Member

killgore

Legacy Member

EraSerX

Legacy Member

QplQyer

Legacy Member

KeaTs

Legacy Member

kwitters

Legacy Member