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 😂

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.

This post contain learnings from over twenty years working as a programmer and close to half a century living on this planet. I met my partner over a decade ago, not long into our relationship we had a conversation: “why do you say things as if you know them, when you don’t?” I would usually reply “Of course I don’t know these things. I’m obviously guessing, you should know this”. When I first was confronted by this I felt misunderstood and even a little attacked.

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.

When you are a member of a remote team, one of your most important tasks as an employee is to ensure everyone is able to see what you are up to. I have worked in a remote team for about a year and in semi-remote scenarios for an even longer period, therefor it is time to share some of my experiences on how to communicate progress (or lack there of).

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.

I realized today that my way of doing things is really quite simple, so I decided to write it down: This is my natural way of doing things. However, not everyone follow this simple three step process. It is like my current boss said: “I assume you just set off down a hill when you go skiing”. My response was: “Of course, I always do that. Don’t you?”. If you know everything about the terrain and have identified all the possible consequences, to me, you have removed all the fun.

First thing about giving advice is that you should add a disclaimer: “These are my experiences, views and opinions. Treat them as such and then make your own reflections on whether they’re worth taking to hear or not” The version of me that existed a couple of years ago would not add the disclaimer. I’d just burst out my opinions as truths without blinking. Anything from advice on coding to career advice I’d lay out without giving it a second thought.

we know that setting a deadline solves nothing we know that after a deadline, there’s someone who has to clean up afterwards we believe that workers don’t need to be bullied or pressured into performing to be successful we believe that managers who can’t make their team perform without deadlines should consider changing profession This is just some thought and I’d love your input in comments to make this better.

I I’m have interviewed for higher management positions during my career. One question which pops up in all of them is this: “do you have experience in leading through middle managers” A fair question one would think given that as a higher position manager you’ll have some other managers below you. However, there is one thing I’ve seen many places which too many higher level managers miss. That’s the ability to keep in touch with what’s happening on the lowest level.

Many companies spend an awful amount of resources and focus on trying to motivate their employees. This is of course I theory a great thing which should benefit employees. There is however one thing every company should look into before looking at how to motivate: What are we doing which demotivate people? Are there hurdles in our organization which prevents people from doing their job? Is there something we’re doing which drive people nuts?

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.

Smidig 2010 er nettopp over og jeg tror alle deltagere var rimelig fornøyde. Selv var jeg også godt fornøyd etter å ha truffet mange kule og kunnskapsrike kolleger fra rundt om i landet. Det begynne å ligne litt på en veldig trivelig re-union å være på Smidig. Litt som å komme tilbake til hjembygda også treffe igjen gamle kjente. Det er riktignok en ting som har slått meg etter å ha reflektert over det som ble sagt under konferansen.

Jeg var så heldig å få sjansen til å holde min lyntale på Oslo XP Meetup igår. Det var utrolig spennende fordi det var diskusjon umiddelbart etter lyntalen. I motsetning til på konferanser så måtte jeg her svare for mine tildels breibente påstander om det ene og det andre. En ting jeg åpnebart formidlet uklart var dette rundt spesialistenes rolle i smidige prosjekter. Mange tolket mine utsagn til at man skulle ha spesialister som kun jobbet med sin spesialitet og at ingen andre på teamet gjorde det.

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.

Tittlen er et kjent slagord fra miljøbevegelsen når det gjelder hvordan man skal bekjempe klimaproblemene vi står ovenfor. Jeg føler det samme slagordet gjelder for smidige metoder og hvordan man best klarer å få smidige metoder til å fungere i sin organisasjon. Smidig systemutvikling handler veldig mye om kommunikasjon og mellommenneskelige relasjoner. Likevel er dette et element som veldig skjelden blir adressert hverken i prosjekter eller i debatter om smdige metoder.

I andedammen her i Norge har skeptikerne til smidige metoder virkelig fått vann på mølla ettersom flere og flere “står frem” med sine historier om hvordan de ikke har vært på et eneste bra smidig prosjekt. Smidige fundamentalister vil gi deg følgende svar: “Hvis det ikke virker, så gjør du det feil”. Hvilket egentlig ikke er noe svar siden det ikke gir den som sliter noen løsning. Særlig ettersom svaret på “hva er riktig måte?

En smidig tilnærming til samarbeid og problemløsning er ikke noe som bare gjøres i programvareutvikling, det gjøres også når man skal bygge enorme konstruksjoner. I Discovery Channel programmet Build It Bigger viste de historien om hvordan Washington fikk et nytt baseball stadion for sitt lag Washington Nationals. Det at man lager enorme stadioner i USA er ikke noe oppsiktsvekkende, men det som gjorde meg “varm under kraven” var hvordan de gikk frem for å bygge denne stadionet.

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.

Hvis man til enhver tid har øyne og ører åpne vil man kunne lære noe nytt i de mest pussige situasjoner. Dette gjelder også når du ser TV på en lørdag kveld. Jeg så Chris Rock sitt Kill The Messenger show på SVT2 denne helga. Ikke bare var showet hysterisk morsomt, men det inneholdt også jobb relaterte råd! Hvem hadde trodd at en av de mest reflekterte uttalelsene jeg har hørt siste året om jobb kommer fra Chris Rock?

Den absolutt beste konferansen for smidige metoder, Smidig 2008, går av stabelen 9. - 10. oktober i Oslo. Her vil du ha anledning til å dele erfaringer med de absolutt beste og mest erfarne menneskene i Norge når det gjelder smidige metoder. Jeg skal holde en lyntale som heter Agile sier du? Fragile sier jeg hvor jeg vil belyse det faktum at de aller fleste som heveder de benytter smidige metoder faktisk ikke gjør det fullt ut og dermed ender med en slags mellomløsning som tar det værste fra smidige metoder og kombinerer det med det værste fra tradisjonelle metoder.