Better than Thou

Återigen en engelsk titel, det bor uppenbarligen en liten Dolph i mig.

Ni har kanske råkat ut för den det här inlägget handlar om: idealisten, evangelisten. Då talar jag inte om alla de corporate evangelists det vimlar av från Sun och Microsoft främst, utan den verklige idealisten som har sett ljuset och sen inte kan låta bli att försöka sprida det till alla som vill (och efter ett tag inte vill) lyssna.

I mitt fall rörde det sig om Smalltalk. Alltså, det var Smalltalk som företeelse som var 'ljuset'. Och i min närhet fanns idealisten som höll Smalltalks fana högst i alla lägen.

Inget ont om Smalltalk och dess olika dialekter - mer OO-purism än så är svårt att tänka sig - allt är objekt - även klasser och integers (1+2 innebär att man skickar meddelandet '+' till objektet 1 med parameter objektet '2'). Para det med grymma utvecklingsmiljöer och en varm och cosy feeling som bara Smalltalk kan ge och man har en vinnande kombination. Eller?

Problemet kommer när man skall jobba kommersiellt tillsammans med idealisten. Kommersiellt innebär att man skall jobba för pengar som nån känner sig villig att hosta upp.

Det innebär ofta också att man ska jobba i ett team tillsammans med folk som har kompetens på den valda plattformen (och den valda plattformen är en kommersiellt gångbar plattform = inte Smalltalk).

Smalltalk hade kunnat vara vad Java och C# är idag - preferred choice of språk och utvecklingsmiljö för bulken av alla nystartade utvecklingsprojekt.

Det är som sagt squeaky (förlåt vitsen) clean vad gäller objektorientering. Det saknar också den ofta (enligt min mening) onödiga statiska typningen i Java/C++/C#.

Helt enkelt en produktiv miljö second to none.

Men, marknadens vägar äro outgrundliga, eller snarare beroende av smarta marknadsförare med stora pengasäckar i bakfickan (läs Sun, Microsoft).

Hade det funnits en dylik pengasäck bakom marknadsföring av Smalltalk på den tiden då Javas showcase var vinkande tomte-appleten, så hade Sun kunnat lägga ner den satsningen.

Då var Smalltalk sedan länge redan moget och hade bevisat vad det gick för (det var under en period ganska stort i USA som plattform för t ex banksystem och administrativa system).

Resultatet av den frånvarande marknadsföringspengapåsen är att det inte finns nån marknad (i alla fall inte i Sverige) för Smalltalk.

Då återkommer vi till problemet med idealisten. Att sitta i projekt med honom (i en kommersiellt gångbar miljö) blir en evig whine-fest.
"Aaargh. I Smalltalk hade det varit mycket enklare".
"Varför tycker alla Java/C#/C++-människor att det är så j-a bra. Det suger ju jämfört med Smalltalk".

Kort sagt ingen rolig person att dela skyttegrav med.

Och omöjlig (eftersom han är en idealist) att få att inse att det handlar om stålar. Den bästa teknologin vinner inte - det är den med mest buzz som vinner och på den fronten står sig Smalltalk slätt.

Jag älskar idealister - må de sprida sina tankar och visioner till massorna i evig tid - bara jag slipper sitta i samma projekt som dem...

Singing along with the Choir

När jag ser tillbaka på mina inlägg hittills har de, till största delen, drupit av negg.

Uppenbarligen har en det öppnats en ventil, ett utlopp genom vilket jag kan negga om företeelser i systemutvecklingsbranschen.

Därför känns det jobbigt att, i strid med tidigare inlägg, verkligen plussa nåt:

Test-driven utveckling

När man insett storheten finns det inget sätt att vända åter. Att köra utan är samma känsla som att cykla mitt i stan (bilar är hårdare än människor) utan cykelhjälm (om man nu haft det alltid i 10 år (ja, jag är en farbror)).

Osäkert - minus frihetskänslan man får med vinden i håret.

Processen är solklar:

1. få en spec på en ny feature


2. skriv ett testfall som testar din nya feature


3. kör testfallet


4. Testa om det funkar. Om ja - avbryt


5. Ändra/bygg om tills du tror att det funkar


6. Gå till punkt 4 - lather, rinse, repeat!

Om alla gjorde så skulle världen be a better place...

Stating the Bleeding Obvious

Jag har tidigare redovisat min personliga taxonomi över svenska utvecklingsbloggar (Someone else's News), men måste nu tillfoga en ny - The Bleeding Obvious-bloggen.

En dylik blog handlar om nåt extremt basalt och har lägre höjd än Nederländerna.

Nu kanske jag svär i kyrkan när jag pekar ut en medbloggare som hemmahörande i denna kategori, men den ligger 11:a på http://bloggtoppen.se (Data/IT), så så jävla synd är det inte om honom: http://www.svensk-server.info/

Det gick dessutom inte att kommentera utan att registrera sig först (och som jag har längtat efter ett membership på svensk-server.info - not), så han får finna sig i att jag gnäller här istf på hans blog.

Den första artikeln har the groundbreaking title HTML Dokument (jo det var utan bindestreck) och redovisar hur man ska använda bla <html>-taggen...

En blick på en bra html cheat sheet site (t ex http://www.psacake.com/web/dy.asp) ger massor mer info befriat från särskrivningar och putslustiga kommentarer.

Ibland önskar man att det inte var riktigt så enkelt att publicera saker på webben. Hade det bara varit lite svårare så hade vi sluppit en hel del bleeding obvious skräp producerat av medelmåttor...

Bjarne Spilling the Beans

No Java pun intended (beans alltså).

Lyckades leta reda på den här intervjun som jag minns att jag läste för ett tag sen:

http://members.safe-t.net/jwalker/programming/interview.html (not working anymore)
http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtml

Bjarne Stroustrup (mr C++ för oinvigda läsare) berättar vad han egentligen tycker om sin kreation.

Den bekräftar vad jag tyckt väldigt länge: C++ är datavärldens motsvarighet till att skruva i en spik med en fogsvans - du kommer slinta och såga dig i benet.

Det är ju faktiskt så att C++ nog inte är rätt verktyg nånsin; ska du skriva ett operativsystem eller drivrutiner så vill du inte ha overheaden som OO innebär med t ex traversering av funktionspekararrayer för att hitta rätt implementation - du väljer good ole' C istället.

Ska du bygga vilken-annan-applikation-som-helst så vill man ju ha:

• bounds checking
• garbage collect
• ett språk som inte på ett så uppenbart sätt inbjuder till att skjuta sig själv i foten med
  

Hoppsan. Hamnade nästan in i en språk A är bättre än språk B-rant och sånt är ju aldrig roligt.

Roligt är det däremot när folk säger sanningar som man förvånas av.

Stå på dig, Bjarne. Tell it like it is...

Four Letter Word

Påminn mig att jag ska skalla alla som använder ordet 'agil' i svenska språket.

Det är inte ett ord, har inte varit ett ord och kommer inte bli ett ord på svenska.

Det är nog irriterande med agile hit och agile dit på engelska.

15 minuter daglig masspsykos

Varje morgon kl 09:00 samlas Sveriges alla (nåja majoriteten känns det som i alla fall) systemutvecklare i små grupper om 5 - 15 pers, berättar vad de gjort den senaste dagen och vad de tänker göra idag.

Nej, det är inte improviserade AA-möten som utspelar sig på landets alla IT-arbetsplatser. Det är såklart Scrum.

Inte nånsin har jag varit med om att någon metod/metodik/metodologi har fått en sån fullständig impact på så kort tid. Från att knappt ha hört talas om fanskapet till att folk inte gärna sitter bredvid en på tunnelbanan om man inte är Certified Scrum Master.

Det är inte så att jag tycker det är dåligt eller så, men jag blir alltid skeptisk när nåt nästan övergår i religion. "Vad säger Scrum att man ska göra i den här situationen" som om Scrum-väsenet tryckte i nåt dammigt hörn i konferensrummet och hade nåt viktigt att dela med sig av.

Backlogen är helig (ordet backlog betyder väl egentligen saker man borde gjort men inte hunnit. I Scrum (helgat varde dess namn) så är nåt man precis kommit på en backlog item (alltså nåt man redan borde gjort fast man precis kom på det)). Snacka om att ge Losec-marknaden en extra skjuts.

Finns det inte i sprinten så ska man inte göra det. Tanken är sund; isolera utvecklings-teamet från den yttre världens alla krav-glidningar och scope creeps. Sprinten blir ett 300 DPS Sword of Scope Defence som teamet kan vifta med när de bakåtslickade frisyrerna kommer och försöker få in lite features som kan hjälpa dem att kränga skiten till nån ny kund.

Problemet kommer då man inser att man faktiskt inte får med allt man verkligen gör i backlogen och senare i sprintarna. Man ser ut som en lat jävel när det visar sig att man har en sprint-velocity som Micke Persbrandt på väg hem från krogen.

Sprintplaneringen blir också en speciell upplevelse eftersom det (vad jag vet) inte finns nåt utrymme (=tidpunkt, dedikerad tid) egentligen för att _speca_ en backlog item. Den är oftast på formen 'Användaren ska kunna skicka meddelanden till andra och notifieras när han får ett meddelande sänt till sig'.
Spec behövs minst på områdena Info-design, databasdesign, protokollnivå, kravbild (ska t ex användaren kunna lägga upp nån på en ignore-list? Framgår inte av backlog-itemet).

Urspungskravet kommer ju oftast från nån som inte håller på med implementation och därför inte kan antas kunna speca på den nivån (eller ens veta att det behöver specas på den nivån).

Vad det hela kokar ner till är att man försöker tidsskatta i princip helt ospecade krav. Under upp-taskningen sker ju nån slags specning, men det sker inför hela gruppen och blir frustrerande efter fyra-och-en-halv timme, let me tell you.

Vet inte om det bara är jag som upplevt det, men det verkar som om Scrum (oh, herde på livets stig), inte riktigt tycker att man ska speca (= en (eller ett par tre) person(er) samlas, ritar pilar och streck, kommer överens och skriver ihop ett snärtigt dokument på 1-1,5 A4 som beskriver hur implementationen skall gå till).

Speca är fult. Luktar vattenfalls-modellen och gammal död hud. Fast där nånstans brister illusionen lite.

Behold, the revolting underbelly of Scrum...

Pärlor för ingen?

Inser plötsligt att det jag jobbar med (och skriver om i den här bloggen) kanske intresserar ungefär en promille av Sveriges befolkning.

Det kanske kan översättas till en promille av en promille av världens befolkning, eftersom intresset för utveckling av datasystem (eller snarare nån som gnäller om detsamma) kan antas avta med kvadraten på risken att dö i svält/hamna i husarrest i Öst-Timor/få fågel-influensa/hamna under vatten pga växthuseffekten... etc you name it.

Är det då värt det? Hittills har ingen. Och jag menar _ingen_ hittat min blog. Inga kommentarer har reggats (utom mina egna patetiska). Jag skulle lika gärna kunna vara den sista utvecklar-gnäll-bloggen på jorden. Tänk er den filmen. 'Utvecklar-gnäll-bloggarnas planet'. På slutet hittar de frihetsgudinnan i sanden med the collective works of Donald Knuth under armen.

Sad sad developer.

Someone else's News

Har ni nyligen läst svenska bloggar om systemveckling? Då har ni kanske märkt att de ofta är på nån av formerna:

• "Har ni hört att Freakalizer (påhittad hajpad teknologi red. anm.) nu kommer i version 3.2? Det är jätteintressant och de har bland annat lovat högre prestanda och bättre interoperabilitet och antigravitationsflänsar. Cool! Can't wait to try it out!"
• "Det är jättesvårt att välja mellan alla standarder och produkter som kommer. Och nu kommer alltså Freakalizer 3.2 som inte gör det lättare att välja, särskilt som MastaSoft precis släppt sin DudeMaster 6.2 i dagarna"
• "Jag har testat Freakalizer 3.2 och gjort en test app som skriver ut 'Hello World'. Källkod finns att ladda ner. Jag är ju inte nån erfaren Freakalizer-utvecklare så jag har ju bara testat lite och här är vad jag tycker."
  

Alltså en av följande:

Halleluja-bloggen

Väljer ett spår (t ex Java, .Net eller Ruby/Rails t ex) och väljer sedan ut nyheter som sen helt okritiskt presenteras som 'mycket intressanta'.

Bloggaren utmålar sig själv som nån som nästan maniskt kastar sig över vilken alfa-release som helst som släppts av nån håglös open source-utvecklare bara det hamnar inom träffområdet för bloggens inriktning.

Detta är ofta fallet för bloggar som är show cases för företag (eller för enskilda konsulter som försöker profilera sig inom vissa områden). Konsultföretag har gärna teknikbloggar, men innehållet är så streamlined och devoid of personliga tyck och tänk för att undvika att (Gud förbjude) någon presumtiv kund skulle bli upprörd och låta bli att köpa företagets tjänster.

För oss som inte genomgått lobotomi så är detta uppenbart efter att ha läst ett par rader och därefter faller såklart hela bloggen.

Räkna-upp-alternativ-bloggen

Tar inte ställning. Försöker att täcka in området genom att räkna upp alla möjliga alternativ. Ger inte mer kött på benen än en tio minuters session med Google. Why bother? Tyck för fan nånting!

Jag-bara-testar-bloggen

Tycker att det räcker med att fluffigt beskriva den nya teknologin. Ursäktar sig hela tiden med att han/hon inte är expert, men kläcker ändå ur sig lite useless code som inte åstadkommer nåt, men finns att ladda ner!

Jag vägrar att läsa ytterligare en blog där mänskan inte påstår sig kunna det han skriver om!

Skriv för f-n om nåt du kan (eller ta reda på mer så att du kan det du vill skriva om)! Livet är för kort för bortförklaringar.

Pidgeon Swedish

Tänkte hitta lite enkla sätt att marknadsföra min blog och googlade på 'blog java' - 'visa svenska sidor' (tanken var självklart att helt utan skam svara på nåt halvtrist inlägg och bifoga min blog-address (cross-linking rules!)).

Hamnade dock på "Enkel tanken Java & Spindelväv Teknologien Blog" på sajten som kallar sig för "Simple Thoughts - Enkel lösandet för komplex problemen". En hilarious babelfish-approach till Java-utveckling.

Rekommenderas.

Bland pärlorna finns "Hur Till Möjliggöra Befästa (SSL) IMAP & POP3 Med ( fri) Jag- Undertecknat Intyg" och t ex "Hur Till Skapa Jag- Undertecknat Intyg"

Priceless...

Här är länken: http://blog.taragana.com/index.php/sv/

UML - Underliggande Megakomplext eLände

UML - the Entreprisest of them all.

Här har vi nåt som verkligen faller management i smaken. En rigid struktur av dokument, och diagram som specificerar systemet. En illusion av ordning, struktur och specifikation som får alla i beslutsfattande position att komma i brallan.

Optimalt skall man köpa in Rationals verktyg för en förmögenhet och sen ska man börja med, håll i er nu, ett projekt för att modifiera RUP (Right UP your ass) att passa det projekt man för tillfället skall bygga.

Rational har också (i enlighet med teoremet 'Management ska komma i brallan') låtit antyda att det är möjligt att, håll i er igen nu, grafiskt rita systemet i deras astronomically overpriced system och sen trycka på 'generate'-knappen och - vips!- så är systemet där. Färdigt att deployas och köras.

Hur har de då lyckats med detta? Jo, genom att sälja where the wallet is. Hos management. Kostymer möter kostymer och kommer överens om vad som ska gälla som strategi vad gäller systemutveckling. RUP/UML blir ett stridsrop, ett sätt att visa att 'vi har minsann ett enat grepp om systemutveckling'. Notera ingen inblanding av nån som faktiskt fattar nåt om systemutveckling (arkitekter, utvecklare).

Enter The Consultant. The Consultant har för länge sen slutat bry sig om vad som egentligen gör att systemutvecklingsprojekt blir framgångsrika. Istället har han (eller mer sällan hon) koncentrerat sig på att pricka in lämpliga buzzword technologies och methodologies.

Eftersom ingen in-house-utvecklare med självrespekt nånsin kikat åt RUP som lösningen på nåt (utom möjligen för att skriva ut specen ifall pappret är slut på muggen), så måste man ta in The Consultant för att ta fram en RUP-mod som passar projektet och införa den.

Resultatet blir en mängd dokument (artefakter som de j-a freaksen kallar't) som ingen nånsin läser. Undrar hur många hektar regnskog som gått åt i den dokument-bonanza som RUP/UML innebär.

On a side note så är själva grundtänket fel med UML vad gäller objektmodellering - det fokuserar på arvshierarki istället för objektmodell. Arvshierarki är bara kodhygien - hur objekten hänger ihop är det som är intressant.

Well, well. Para RUP med en hajpad Enterprise-technology of your choice (t ex den här: Följa John), och resultatet låter vänta på sig (resultatet i form av ett användbart system alltså).

Den som nöjt kan dra sig tillbaka efter projektets downfall är The Consultant, med 1200 kronor i timman i 1000 timmar och en ny entry i sin CV - klar för nästa uppdrag...

När mönster blir monster

Boken Design Patterns av Gang of Four har varit och är required reading för utvecklare av alla slags system. Tanken är bländande - best practices abstraherade och nerkokade till en bukett av pärlor att plocka ur när man bygger sin applikation (ursäkta ett något utflippat bildspråk ("bukett av pärlor"?)).

Problemet uppstår när vi vanliga dödliga börjar gå loss i denna bukett. Exemplen är legio på när ett ordinärt order-lager-inköps-system (substituera mot valfri vanilla-applikation) blir en orgie i patterns.

Många av de mer basala patternsarna (heter det så?) är inte så svåra att knö in i ditt system. Kanske lite Composite, lite Delegate osv. Man får blodad tand. Lite Decorator ovanpå det här (lite krystat i order-lager-inköps-systemet, men what-the-heck).

The mother-of-all-patterns-you-don't-need: Factory ligger sen nära till hands. Och vad är en Factory utan en FactoryManager (som gärna ska instansiera sig från XML).

Rätt vad det är så har man slutat bygga systemet och börjat "The Race of Patterns". Det gäller att få med så många som möjligt. Flest patterns när man dör vinner.

Har vid tillfälle suttit med underhåll av ett system som var byggt på detta vis. En ordinär web request routades genom dispatchers, handlers och delegates så att inte ett öga var torrt. Detta ledde också till att (som ni kanske gissat) 80% av applikationen bestod av infrastruktur för att stödja alla dessa design patterns. Själva business-logiken var gömd långt inne i nån handler nånstans och det var i princip omöjligt (ok, nu tar jag i lite) att avgöra var man skulle hamna för ett givet anrop.
Att fixa buggar och lägga till funktionalitet blev också lite av en bygg-deploy-starta-håll-för-ögonen-övning eftersom man säkert som amen i kyrkan glömt att haka in sin nya handler i nån obskyr XML-fil.

Missförstå mig rätt - patterns rockar, men bara då dom verkligen behövs. Alltför ofta är det ingen som gör en rimlighetsanalys innan man tillför en eller ett par extra nivåer av indirection för att stödja ett till pattern - och kunna bocka av det i boken Design Patterns.

Såpa är bäst på TV

Jag ska försöka att inte bara negga, men en nystartad blog kommer liksom ofta från ett inneboende behov att negga - nåt man kanske inte vill eller kan göra som 'representant' för ett företag eller ens när man skyltar med sitt eget namn. Vem vet var jag hamnar i framtiden där de tycker att teknologi X är the new black och då kan det ligga mig i fatet om jag har neggat upp X i brygga under mitt eget namn. Men, men - here goes nothing.

SOAP. Simple Object Access Protocol. Faller på första ordet som utgör "S" i dess akronym. Simple, I think not. Sällan har så många name spaces, externt deklarerade entiteter och dylikt samsats i en och samma XML-blobba som i ett ordinärt SOAP-meddelande.
Testa att skicka ett SOAP-meddelande med texten 'Hello World' till en intet ont anande mottagare och förundras sedan över hur detta meddelande kunde bli 3016 bytes långt (har inte räknat bytesen i just detta exempel, men ni förstår vad jag menar).

SOAPs styrka ligger i WSDL, dvs formatet för att beskriva ett protokoll (alltså vilka tjänster som finns i en web service och hur meddelandena är strukturerade). Det är barnsligt enkelt att definiera en web service i WSDL och generera en handler-klass som sen pratar med web-tjänsten ifråga med ett enkelt vanligt anrop med typade parametrar. Så långt allt väl.

Problemet uppstår när man försöker t ex köra igenom en rimligt strid ström av meddelanden och man inser att de informationsbärande bytesen man skickar ligger nånstans runt 5% av junket man skickar. Overhead är bara förnamnet.
Dessutom är min erfarenhet att messaging mellan system är något som är väldigt specifikt; man diskuterar ett API, kommer överens om format och dylikt och utvecklar det hela. Vid förändringar så måste självklart båda sidor byggas om. Behovet av att ha referenser till XML schemas för validering och namespaces för att undvika krockar måste i rimlighetens namn höra till de extrema undantagen.
Detta suger bandbredd och CPU till den milda grad att det i princip är helt oanvändbart, ja rent ut sagt oansvarigt, att använda SOAP i de allra flesta fall.

Ett Simple Object Access Protocol (över HTTP) bör tillåta:

• GET-baserade anrop (skit i indempotensen). För ostrukturerad data t ex ett id, kör webtjänsten med get och en url-parameter. Går dessutom utomordentligt att provköra i browsern
• POST-baserade anrop för mer strukturerad data (t ex resultatet av ett inmatat formulär)
• Lean and mean XML-representation av ett objekt:


<user>
<username>leif</username>
<mailaddress>leif@leif.com</mailaddress>
</user>




Ett dylikt webservice-ramverk langar man ihop på en eftermiddag (nåja) - satisfaction guaranteed!

Följa John

Jag har varit så pass länge i systemutvecklingsbranschen att jag insett ett par saker.

• There is no silver bullet
• Om något pushas som det bästa sen sliced bread så är det nåt grundläggande fel nånstans
• Det är (faktiskt) inte alltid fel att uppfinna hjulet igen (eller kanske inte hjulet, men kanske chassit, karossen och inredningen för att fortsätta på den något krystade bil-liknelsen)
  

Låt mig ta några exempel. Jag tillhör, måste jag erkänna, dem som svalde krok, lina och fiskespö när J2EE-tåget lanserades med buller och bång på senare delen av 90-talet.
Här kom en spec, en standard som skulle lösa alla mina problem - persistens, distribuerade lösningar, messaging och en hel massa annat. Sun, i sin oändliga vishet, publicerade en "show case"-app i form av "pet store" full av
J2EE-patterns att använda för intet ont anande utvecklare världen över.
Inte nog med det - "Enterprise" i namnet gjorde att management i tusentals företag också svalde betet. Att använda J2EE blev ett slags kvalitetsstämpel; en garant för att lösningen var byggd på solid grund, lätt att underhålla och skala upp.

Hej vad vi alla bedrog oss. Om man bara hade använt sin (iofs på den tiden betydligt kortare) erfarenhet och utbildning och verkligen läst specen istället för att kasta sig över ett kodexempel och med ett fånigt flin på läpparna sjösätta sin första Entity Bean i nån mer än lovligt buggig och seg 'container'.

Vad som framgår som pinsamt tydligt nu i ett förklarat ljus är att J2EE-specen var ett typiskt 'Design by Commitee' piece of crap. En kopp komplexitet tillsammans med fyra liter configuration i form av XML och sex matskedar magi - vad containern har för sig under huven visste man inte riktigt (och det var ju inte meningen att man skulle behöva veta det heller). Lycka till förresten med att sätta en debug-stopp långt inne i JBoss mitt i nån ConfigurationFactoryManagerFactory eller nåt som är i full färd med att instansiera sig själv utifrån nån vidrig XML-blobba.

Applikationerna blev precis det motsatta mot vad som utlovades:

• Skalbarhet - my ass. Nåt segare än en J2EE-applikation med Entity Beans går inte att uppbringa. Det är datavärldens motsvarighet till en bil med prestanda från en Trabant och komplexitet hos en Ferrari F1
• Maintainability - tanken var att eftersom allt var byggt efter en enhetlig spec skulle man kunna byta utvecklare i ett projekt lika ofta som man byter kalsonger. Vem som helst skulle kunna kliva in och vara produktiv på en gång. Detta föll genast eftersom alla var tvungna att kringgå den vidriga specen med hembyggda lösningar (som ofta blev mer eller mindre de facto patterns för J2EE-utveckling) som t ex "fast lane" (dvs gå direkt med JDBC mot databasen för att göra saker som inte gick att göra med J2EE (som att läsa upp fler än 10 objekt t ex (hmm, ett persistensramverk som inte fixar att läsa upp ett tjog objekt eller så från databasen borde ju fått folk att tänka efter)))
• En tredjeparts-marknad med färdiga komponenter färdiga att bara drag-and-droppa in i din container och vips så funkar allt! Att bygga ett system skulle bara kräva en systemdesigner (gärna i kostym) som i samråd med beställaren grafiskt drar-och-släpper komponenter i en grafisk högnivå-utvecklingsmiljö. En luttrad utvecklare inser kanske att det är omöjligt att t ex komma fram till en generell definition av ett så basalt begrepp som 'användare'. Vissa system behöver user name och mail address, medan andra behöver längd i cm och hårfärg. Marknaden för tredjepartskomponenter blir snabbt begränsad till komponenter för typisk generell funktionalitet - mail-skickning, och messaging t ex

De enda som drar nytta av eländet är företag som säljer J2EE-containers och de som konsultar i ämnet. Mest de som gör bådadera, t ex säljer en vidrigt komplex container (läs WebLogic) och sen säljer vidrigt dyra konsulttimmar för att röja upp i de katastrofprojekt som (naturligt nog) inte kan leverera utifrån en galen spec (läs J2EE) implementerad i en överkomplex container (läs WebLogic). Där har ni en bra affärsidé. Synd att det inte var jag som kom på det.

J2EE är en typisk 80-20 deal. Det går bra att utveckla 80 procent av din applikation (om du kan stå ut med att den är seeeeg), medans resterande 20 procent är omöjlig att utveckla eller måste byggas i strid med vett och sunt förnuft för att kringgå alla hinder som J2EE lägger i vägen.

First post!

Hej, här är jag. Det här är tänkt att vara en blog om livet som systemutvecklare. Fett roligt är det också. Bloggen alltså. Jag lovar. Att det blir det.

Namnet 'Hellre fåraherde' är väl valt. Alla i branschen har upplevt ett 'Hellre fåraherde'-tillfälle (dvs man vill hellre stå på en äng och räkna får än sitta med nosen i en korrupt databas). Master-databasen ditchar. Oförklarliga core dumps. Mer problem than you bargained for. Men så är det. Det bästa systemet är, på ett perverst vis, det som aldrig gick i produktion (såtillvida det inte berodde på din egen inkompents (felstavat med flit för att det är skoj att felstava inkompetnes)).