Creativity, Defects and Systems Thinking

“If you don’t remember that, you will regret it.”

1) Systems thinking, improving the whole: the performance of a system depends on how the parts fit, not how the parts perform individually.

2) Removing defects is not the same as system performance improvement – you’ve got to aim for what you want, not focus on what you not want.

3) Creativity is not continuous – doing the right thing (wrong) vs doing the (wrong) thing right.

Two things that bothers me with Chrome/-ium

  1. My bookmarks and reading history is synchronized in a way I can’t control (yes, I’ve lost all my settings and bookmarks once)
  2. Can’t set proxy settings for the application only – it uses the full system’s proxy settings

WebKit is BSD/LGPL so that’s good, although entire application isn’t open sourced (which Firefox and the Mozilla organisation is about) – it’s open enough.

The things that bothers me with Firefox, making me shift again:

  • Speed, performance. It’s almost on par with Chrom[e|ium] when only displaying one tab, but after that – it’s a different game.
  • Developer tools. While Firebug sparked much of what we have today, again – the tooling is simply better (and I assume it’s the underlying platform that’s part of the reason to this)

Chrome/Chromium has a richer plugin (app) echo system. There’s a lot for Firefox too, but I have the feeling that there are less developers and development traction in that echo system.

docker, vagrant, packer

It’s just awesome. I so wished I’d had these tools when I started my career some 14 years ago. Problems I’ve ran into with Docker:

  • diskspace, as docker with aufs puts all stuff in /var/lib/docker – make sure there’s enough room :-)
  • stability, with the version of Ubuntu and docker at my disposable has been pretty unstable with kernel oopses eventually freezing the entire host OS

But “apart” from the stability issue, it’s really nice to run packer inside an lxc (from docker) with the goal of producing vagrant boxes. :-)

Notes from Evidence-Based Management Training

These are some of the notes I made for myself during my two day training with Scrum.org and others at Scrum.org HQ. Two mind-blowing days, I assure you!

Agility Path comes in to managers at a solution level, Evidence-Based Management addresses the thought level. (If you haven’t heard about it, it’s essentially the next move in trying to improve the profession of software development.)

What do you want to accomplish & how do you want to measure it?

Metrics for improvement, not performance.

Elevating empiricism to business value.

Measuring input, is not output – what do you actually get from this investment?

Success for an Engagement Manager? Help bring relevant metrics, bc of relevant reasons.

IMDb Rating

Fick en fråga av en vän om detta med varför jag ger så “låga betyg till alla filmer på IMDb“. Här är mitt svar, typ:

  1. Rent av skadligt, undvik
  2. Ingen verkshöjd, undvik
  3. Antagligen godkänd produktion, men tveksamt värde avseende handling eller budskap
  4. En enkel historia, troligen hyffsat berättad
  5. Filmen har höjdpunkter och jag lämnar bion med “godkänd användning av min tid”
  6. Enjoyable
  7. Det här gillar jag :-)
  8. Mycket sevärt!
  9. Bland det bästa jag sett och upplevt!
  10. Budskapet eller berättelse rör mig djupt.

 

How To Write Good

Found this on the internetz – a nice litlle basic check list.

1. Avoid Alliteration. Always.

2. Prepositions are not words to end sentences with.

3. Avoid clichés like the plague. They’re old hat.

4. Comparisons are as bad as clichés.

5. Be more or less specific.

6. Writes should never generalize.

Seven: Be consistent!

8. Don’t be redundant; don’t use more words than necessary; it’s highly superfluous.

9. Who needs rhetorical questions?

10. Exaggeration is a billion times worse than understatement.

PHP and Redis

I’m on an old Ubuntu version, and just needed something to dump a Redis value as JSON.
sudo -s
git clone https://github.com/nicolasff/phpredis
cd phpredis
aptitude install php5-dev -y
phpize
./configure && make && make test && make install
echo "extension=redis.so" > /etc/php5/conf.d/20-redis.ini
service apache2 restart

And then
<?php
#
# Serves the JSON clob from Redis
#
header('Content-Type: application/json');
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$data = $redis->get('movie_database');
echo $data;
?>

Visualizing Team Practice Levels

Idé: Varje halvår startar man om. Man identifierar då axlarna man vill använda sig av, t ex parprogrammering, automatiserade acceptanstest, TDD, backlog refinement, … Jag hade kollat på eXtreme Programming för inspiration till fler axlar, eller om det finns något Software Engineering-dokument för organisationen eller motsvarande.

För varje axel identifierar man sedan fyra – fem “nivåer” av utförande. Det går bra att ha olika antal nivåer. För parprogrammering skulle det kunna se ut såhär:

  • promiskuös parprogrammering
  • dagligen, minst 3 timmar
  • nästan dagligen
  • minst en gång per vecka
  • varje sprint
  • en gång varje år

För TDD:

  • så ofta det bara går – all produktionskod drivs fram från test
  • varje gång vi parprogrammerar (kanske dumt att blanda in en annan axel …)
  • minst en gång per dag
  • minst en gång per sprint
  • en gång per år

 

Och varannan sprint eller så ber man teamet sätt ut ett kryss på varje “axel” som sedan sammanställs till “spider chart”. Dessa sätts upp i en serie så man kan se förändring över tid.

Spider Chart Example