Yes, it is a “funny” word play on the legendary sci-fi novel Do Androids Dream of Electric Sheep? The title of this article is something I have had in the back of my mind since very early on in my career and it has stuck with me. Note! If you are offended by swearing, bad language and grammar you will have a blast reading this article as it contains a lot of it 😂

You were forced to work a lot to reach a milestone set by someone else. It could be for a number of reasons and often times it’s because someone made a mistake that these things happen (or the person in charge is an ass or an incompetent ass). You put all things on hold, dig in and put in the hours. Depending on how long this lasts , days, weeks or even months.

Often times when working with developing software you get this urge to think “if it can do X, what about Y”. When thinking this you get this nice feeling inside and a sparkle in your eye. It’s the feeling of being A Proper Engineer. As the stereotype of one is that they are capable of future sight and gifted with the ability of crafting the most amazing designs up front by just Thinking Right.

This is a common challenge once a company has built enough “stuff”. The burden of maintenance and the difficulties in refactoring makes one cry out for “Simplicity, now!’. A common perception of reducing complexity is to “dumb things down”, this is a reaction to the tension of it being difficult to untangle things. It’s often a good idea not to act on this tension, but look a bit further at the issue at hand.

Disclaimer: All my “On..” posts are things I write from beginning to end without any editing or thinking about structure (so it’s like all other posts?). They are just dumps of thoughts I’ve had which I deem that maybe they’re useful for something or someone, so I’ll just dump it here where nobody actually sees them. A friend of mine told me his friends reaction when he said he was starting to learn how to play the flute.

I have been so fortunate as to be part of several young companies and starting new teams in existing organizations. This post is is a summary of my subjective observations, you should treat it as such. 1️⃣ Introduce departments too early # All young companies wants to grow up and become proper organizations. In order to get a head start, many young companies start splitting up their organizaiton into departments way too early in an attempt to look good for stakeholders and potential hires.

Complexity is on the one hand something which can be measured by tools to give an objective value of how complex something is. However, this is not how I’ve come to see the word used in my work as a software developers. In this article I will talk about some of the aspects tucked away in the concept labeled complexity. It tends to be used to cover up subjective opinions or believes getting portrayed as objective observations.

I remember when I first read How To Detect Bullshit by Scott Berkun, I was mesmerized that someone was able to articulate this so well. Throughout my career I have referenced this article to my coworkers. Today, more so than ever before, being able to detect bullshit is one of the most important skills you can have working as a programmer. An endless stream of bullshit # There is an endless stream of bullshit flowing all over social- and traditional media at any given time.

When you start learning to code you develop an idea of what people who does it for a living knows. I remember when I started, I was convinced that everyone around me knew everything and was never in doubt about what the correct approach would be. There was little to read about how to approach coding except for academic articles and books. In this day and age the situation is very different.

Veien til å bli en god systemutvikler er hompete, støvete og endere kanskje ikke der du tror. Hva er en god systemutvikler? Dette er et ladet spørsmål, så først vil jeg legge ned min definisjon av systemutvikling. Det er et lagspill der man sammen leverer en digital løsning på en utfordring / problem.Legg merke til at jeg ikke sier «hva er en god programmerer». Hvorfor ikke? Fordi programmeringsdelen er bare en del av det som inngår i systemutvikling.

Software development as a cooperative game http://alistair.cockburn.us/Cooperative+game+manifesto+for+software+development This quote got me thinking today, because if it really is a cooperative game and teams are how we structure people working to solve problems, shouldn’t we look towards other team activities for inspiration? When you work as a team, it is important to have diversity and a mixed set of skills. Especially in software development cross-functional teams is something that can be a good thing.

Photo by Michael Heiss A popular mantra the past few years is that “software is a collaborative game”. However in a large organization or project, is this really possible? When things get big and the number of communications lines exceed what is possible to handle for an individual, is it really possible to collaborate? A behavior of teams when things get clouded is to construct a world which is tangible and possible to manage.

Jeg var så heldig å få lov til å snakke om noe jeg virkelig synes er spennende på årets JavaZone, nemlig mine erfaringer fra å forsøke skape den nye typen sosiale musikkspiller i foredraget: “How we blew our shot at beating Spotify, spending two metric truckloads of cash doing it”. En takk går til programkomiteen som lot meg slippe til med et tema som kanskje er litt utenfor, men som likevel så ut til å være spennende for mange.

Dette er en artikkel i kategorien refleksjon og det kommer som et resultat av det jeg har erfart i de siste årene hvor Smidig-bevegelsen virkelig har blitt allemannseie. Jeg har både vært team medlem, Scrum Master, arkitekt og delvis produkt eier i ulike sammenhenger. En ting har alltid ligget å ulmet i bakhodet mitt de siste årene og det har med begrepet enkelhet eller simplicity. Begrepet brukes til veldig mye rart og har blitt en viktig ingrediens i alle dokumenter om visjoner og strategier.

Midt i det som skulle være pappa-permen min så stakk jeg innom JavaZone 2009 for å holde en presentasjon om brukergrensesnittsutvikling. Jeg har lenge tenkt på å holde et foredrag om dette emnet, ettersom det er noe jeg ofte ser behov for i prosjekter jeg har jobbet på. Tradisjonelle Java utviklere sliter veldig med å applisere sine kunnskaper om objekt orientert programmering i utformingen av brukergrensesnitt. Det er essensen i utvikling av grensesnitt, ingen sort-magi eller annen heksekunst.

I anledning Software 2009 skal jeg holde en lyntale hvor jeg tar opp et tema jeg, og veldig mange andre jeg har snakket med, føler smerten til på daglig basis: Programvare arkitekter som ikke jevnlig utfører praktisk utvikling påfører sine bedrifter enorme kostnader Hvordan kan jeg påstå noe slik når det jo er de beste som får det store ansvaret av å være arkitekter? Årsaken mener jeg ikke er manglende kompetanse, men snarere en gradvis fjerning fra der hvor den faktiske produksjonen skjer.

Jeg har vokst opp på en gård i fjellbygda Folldal og er dermed veldig mottagelig for analogier og eksempler som tar utgangspunkt i gårdsdrift. Overraskelsen min var stor da jeg leste en artikkel av XP-guru Kent Beck som nettopp bruker bøndenes metode for å dyrke åkeren for å vise hvordan man kan gjøre det samme i applikasjons design. Artikkelen First One, Then Many tar for seg et klassisk dilemma innen systemutvikling.

Flex har virkelig begynt å få fotfeste i Norge det siste året. Dette merker man i jobbannonser hvor det stadig oftere er nevnet Flex kompetanse og man merker det med antallet hendvendelser som kommer angående hjelp til å begynne med Flex. Å starte med Flex er ikke noe stort problem og de fleste utviklere klarer veldig lett å komme igang med å lage applikasjoner. Tilsvarende lett er det å gå i en del fallgruver og gjøre en del feil.

I desember 2007 la Adobe ut Blaze Data Services som Open Source. BlazeDS var tidligere en del av den komerisielle programvare pakken Live Cycle (LC) . Jeg hadde brukt LC Data Services en stund og var veldig interessert i å se hvordan Open Source varianten fungerte i forhold til den ekstremt dyre komersielle varianten. Resultatet er denne korte oppskriften på hvordan du kan starte med BlazeDS. Demo applikasjonen # I tillegg til denne artikkelen har jeg laget en ekstremt enkel demo applikasjon som kan brukes som utgangspunkt for videre abreid.

Obs! Dette er en eldre artikkel som jeg publiserte tilbake i 2005. Den ble vel generelt ganske misforstått og enkelte av digi.no sine mindre begavede lesere ble veldig forvirret av formen den var skrevet på. Artikkelen er fremdeles relevant og det er ingen tvil om at markedet har tatt samme retning som anbefalt i artikklene. I den siste tiden har mange erklært sin kjærlighet til den nye teknikken AJAX (Asynchronus Javascript And XML).