Home Automation FTW!

Temperature Graph

Although we’ve been living in this house for almost six years now, I never really bothered to figure out how the heating system works. Not until I bought a wireless energy monitor. What a surprise. I had no idea a house could use that much energy! I started to search old documents we inherited from the previous house owner, and finally I read up on the heating system. Left unattended the heat pump had gathered a lot of air and the circulation pump had come to a complete stop. I realized that I needed to get in control. Enter home automation.

At work we monitor software systems in order to (hopefully) act proactively before things go out of hands. It’s as simple as this: if you don’t know, you don’t know! I liked to apply the same principles to the systems at home. Inspired by my colleague Christian Lizell (@lizell) who not only build our monitoring system at work but made his own home monitoring system based on the realtime graphing system Graphite and home automation technology from Telldus, I went out and bought a Tellstick Net unit.

The Tellstick Net is a fairly small device that connects to a cloud based service, and can be accessed with a web interface and an Iphone app. You can connect an array of 433 MHz devices, like on/off switches and dimmers to it and then control them individually and as groups. Schedules can be made so that lights turn on and off, let say on at sunset and turn off at sunrise. Better still the Tellstick Net can recognize a number of wireless sensors. I ended up buying 8 temperature sensors that I connected to outside, inside, the two attics, workshop, fridge, and freezer.

What I had i mind was to read temperature sensor values from Telldus every minute and then send those values to a Graphite backend. Telldus who open sourced their software, offers a REST API with which sensor values can be read. So I started out hacking on the Telldus tdtool.py and Graphite example-client.py and put the code on Github. How I love Python for tasks like this! Installing a Graphite server is quite a task so I ended up downloading a prebuilt VirtualBox Graphite server. Preferably I would like to create a server somewhere in the cloud.

With a graph showing the temperature over time I could tune the fridge, freezer, and workshop (notice the repeating form of the freezer graph). I expect the attic temperature to tell how well the insulation works, but I need more time and freezing temperatures outside to make that analysis. The workshop just need to be a few degrees above freezing.

Next step: When the farming season begins I want to automate irrigation and monitor humidity in the ground. Enter farm automation…

Search for Snow with Hadoop Hive

I don’t know how I ended up becoming the head of our local community association. Anyhow, I’m now responsible for laying out next year’s budget. Most of our expenses seem to be fixed from one year to another, but then there’s the expense for the snow removal service. This year, no snow. Last year, most snow on record in 30 years! How do you budget for something as volatile as snow? I need more data!

Instead of just googling the answer, we’re going to fetch some raw data and feed it into Hadoop Hive.

Just a short update if you’re unfamiliar with Hadoop and Hive. Hadoop is an ecosystem of tools for storing and analyzing Big Data. At its core Hadoop has its own distributed filesystem called HDFS that can be made to span over hundred of nodes and thousand of terabytes, even petabytes, of data. One layer above HDFS lives MapReduce – a simple yet effective method introduced by Google to distribute calculations on data. Hive lives on HDFS and MapReduce and brings SQL capabilities to Hadoop.

Think of your ordinary RDBMS as a sports car – a fast vehicle often built on fancy hardware. An RDBMS can yield answers to rather complex queries within milliseconds, at least if you keep your data sets below a couple of million rows. Hadoop is a big yellow elephant. It has traded speed for scalability and brute force  – it was conceived to move BIG chunks of data around. And it can live happily on commodity hardware. For the sake a brevity we’re going to use some rather small data sets – about 1 megabyte each. It won’t even fill a file block in HDFS (64 megabyte). A more realistic example of Hadoop’s capabilities would be something like querying 100 billion tweets. A RDBMS can’t do that.

You can run Hadoop on your local machine. Like me, on an old MacBook Pro using VMWare. Just download the latest image from Cloudera

The Swedish national weather service SMHI provides the data we need: daily temperature and precipitation data from 1961 to 1997, gathered at a weather station about 60 km from where I live.

Logon to your Hadoop instance and open the terminal to download the data:

wget http://data.smhi.se/met/climate/time_series/day/temperature/SMHI_day_temperature_clim_9720.txt

(sudo yum install wget – if wget is missing)

Trim off header information with a text editor

– – – – – – – –
1961 2010
0101 1231
593537. 179513.
– – – – – – – –

Replace leading and trailing spaces, and replace spaces between fields with commas:

cat SMHI_day_temperature_clim_9720.txt | sed -e ‘s/^[ \t]*//’ | sed ‘s/[[:space:]]\+/,/g’ > temperature.txt

Now we have properly formatted raw data ready to import into Hive. Just type “hive” in the terminal to start up Hive. The columns in the temperature data set looks like this:

TT1 temperature at 06 UTC
TT2 temperature at 12 UTC
TT3 temperature at 18 UTC
TTX(1) daily max-temperature
TTN(1) daily min-temperature
TTTM(2) daily mean temperature
-999.0 missing value

There’s no date data type in Hive, so we’ll to store the date as string.

CREATE TABLE temperature (

It is not intuitive to me why the field separator is defined in the table definition, but that’s apparently how Hive works. Load the data into the Hive table:

LOAD DATA LOCAL INPATH ‘temperature.txt’

Iterate over the precipitation data:

wget http://data.smhi.se/met/climate/time_series/day/precipitation/SMHI_day_precipitation_clim_9720.txt

Trim off header information

– – – – – – – –
1961 1997
0101 1231
593537. 179513.
– – – – – – – –

Replace leading and trailing spaces, and replace spaces between fields with commas:

cat SMHI_day_precipitation_clim_9720.txt | sed -e ‘s/^[ \t]*//’ | sed ‘s/[[:space:]]\+/,/g’ > precipitation.txt

Columns for  the precipitation data set:

PES(1) ground snow/ice code
PRR(2) precipitation mm
PQRR(3) quality code
PRRC1(4) precipitation type
PRRC2(4) precipitation type
PRRC3(4) precipitation type
PSSS(5) total snow depth cm
PWS(3) thunder, fog or aurora borealis code
-999.0 missing value

Create the Hive precipitation table:

CREATE TABLE precipitation (

And load the precipitation data into the Hive table:

LOAD DATA LOCAL INPATH ‘precipitation.txt’

Let’s define a snowy day as a day that has a temperature below 0 degrees Celsius (freezing) with a precipitation of more than 3 mm (approximately 30 mm snow).

– Number of snow days grouped by year
TTTM Temperature < 0 degrees Celsius
PRR Percipitation > 3 mm (approximately 3 cm snow)

SELECT year(from_unixtime(unix_timestamp(precipitation.datum, ‘yyyyMMdd’))), count(*)
FROM precipitation join temperature on (precipitation.datum = temperature.datum)
AND temperature.TTTM < 0
AND precipitation.PRR > 3
GROUP BY year(from_unixtime(unix_timestamp(precipitation.datum, ‘yyyyMMdd’)));

Let’s execute the query:

hive> SELECT year(from_unixtime(unix_timestamp(precipitation.datum, ‘yyyyMMdd’))), count(*)
> FROM precipitation join temperature on (precipitation.datum = temperature.datum)
> AND temperature.TTTM < 0
> AND precipitation.PRR > 3
> GROUP BY year(from_unixtime(unix_timestamp(precipitation.datum, ‘yyyyMMdd’)));

Total MapReduce jobs = 2
Launching Job 1 out of 2

Starting Job = job_201201290156_0082, Tracking URL =
Kill Command = /usr/lib/hadoop/bin/hadoop job -Dmapred.job.tracker= -kill job_201201290156_0082
2012-01-29 13:26:24,615 Stage-1 map = 0%, reduce = 0%
2012-01-29 13:26:33,272 Stage-1 map = 50%, reduce = 0%
2012-01-29 13:26:36,288 Stage-1 map = 100%, reduce = 0%
2012-01-29 13:26:47,395 Stage-1 map = 100%, reduce = 100%
Ended Job = job_201201290156_0082

Launching Job 2 out of 2

Starting Job = job_201201290156_0083, Tracking URL =
Kill Command = /usr/lib/hadoop/bin/hadoop job -Dmapred.job.tracker= -kill job_201201290156_0083
2012-01-29 13:26:54,675 Stage-2 map = 0%, reduce = 0%
2012-01-29 13:26:59,694 Stage-2 map = 100%, reduce = 0%
2012-01-29 13:27:10,791 Stage-2 map = 100%, reduce = 100%
Ended Job = job_201201290156_0083
1961 6
1962 6
1963 7
1964 6
1965 7
1966 8
1967 7
1968 5
1969 7
1970 12
1971 8
1972 4
1973 8
1974 3
1975 3
1976 10
1977 13
1978 8
1979 6
1980 7
1981 17
1982 5
1983 8
1984 5
1985 19
1986 13
1987 4
1988 11
1989 4
1990 1
1991 3
1992 4
1993 6
1994 1
1995 6
1996 2
1997 6
Time taken: 52.914 seconds

Notice how Hive transform the SQL-query into MapReduce jobs. We could of course do this ourselves in Java, but we’d be swamped in code. Hive hides the underlying complexity of MapReduce in the form of more convenient and mainstream SQL.

Hive supports subqueries, let’s calculate the average number of snow days:

SELECT year(from_unixtime(unix_timestamp(precipitation.datum, ‘yyyyMMdd’))), count(*) as sum
FROM precipitation join temperature on (precipitation.datum = temperature.datum)
AND temperature.TTTM < 0
AND precipitation.PRR > 3
GROUP BY year(from_unixtime(unix_timestamp(precipitation.datum, ‘yyyyMMdd’)))
) t;

From these calculations it seems like the worst case scenario for the snow removal service is 19 occasions per year with an average of 7.

Pretty sweet huh!

Flying with Arduino!

I like to build stuff with my hands and I like programming and I like things that fly, so for me the tricopter project was really three things coming together. The project was seeded about a year ago after seeing the amazing videos on Youtube made by David Windestål. I soon ordered the hardware needed for the build from Hong Kong, but my order ended up in the customs and I didn’t get the stuff until late autumn. Finally, with a box full of cheep Chinese RC electronics in my possession, I started out making the wooden frame on which I fitted motors and electronics; a rather crude and simple construction. The only moving part (apart from the three rotating propellers, hence its name ”tricopter”) is the tail rotor that controls the machine’s yaw direction (the ”rudder”). This makes a tricopter a much simpler construction than a helicopter. When almost done with the fittings I discovered that my transmitter did not support the mixing needed to make David’s build work.

While hesitating to buy a new transmitter I stumbled upon the multiwii.com project, a project devoted to make multicopters (tricopters, quadcopters, hexacopters) fly with the help of Arduino (programmable microprocessor), Nintendo Wii Motion Plus (gyro), and Nintendo Nunchuck (accelerometer). It turns out that the gyro and accelerometer used in the Nintendo Wii hand controls are pretty competent. The Arduino is like a very small computer with enough processing power to make real time decisions based on the inputs from the Nintendo PCBs and the user. A tricopter is an inherently instable flying machine, and without the help of electronics (configured correctly) it will flip in a matter of milliseconds. The combination of the three main components makes for a very stable flying platform. Since these units are mass produced they come with a relatively low price tag.

Being a happy Arduino hobbyist I immediately fell in love with the idea to use Arduino as the tricopter’s brain, and as a bonus I could use my old transmitter. The mutilwii project comes with a two programs; an Arduino program that needs to be configured with your multicopters specific settings, such as number of rotors, min and max rpm, yaw direction and a few other parameters; and the MultiWiiConf program used to configure and calibrate the multicopter. Even though I followed the assembly instructions as close as I could, it took a while to sort things out. The soldering of the tiny Nintendo components and connecting all the wires to the Arduino proved to be quite a challenge. Finally when I had found the correct positions for the gyro (Wii Motion Plus) and the accelerometer (Nintendo Nunchuck), I could calibrate the thing and spin up the motors for the first time.

Equipped with three brushless motors, each capable of producining almost 1 kilo of thrust and mounted on the tip of long arms, the tricopter has enough punch to break lose from your hand if not  gripped firmly. With safety goggles on I did a lot of test runs, first holding the thing in my hand, and later on the tarmac outside my maker shed. Luckily nothing vital broke and no one got injured. After a few iterations of weeding out vibrations, trims, and other configurations; it finally took off!

Interviews with Johanna Rothman

It’s been a privilege to spend time with Johanna while doing these interviews. Johanna describes herself as a flaming extravert, and I would like to add to that description that she’s full of humor and wisdom. A great opportunity to meet with Johanna face-to-face, is to attend the PSL Workshop in January next year. There’s still a few seats available. Less than a few actually!

From the PNEHM! interview with Johanna:

“Anyone can achieve this kind of power. Because it comes from within, no one can take it away, except for yourself. And, no one can give it to you, except for yourself.”

From the first part of Johanna’s podcast:

“I took PSL in June of 96, and it was a real turning point for me…”

From the second part of Johanna’s podcast:

“It’s (PSL) really all about: how do you see yourself; how do you understand yourself first; and see what your defaults are; and then how do you make changes–if you choose to make changes.”

Podding with JR

Johanna Rothman (author, speaker, consultant, chair of the Agile2009 conference, and host of the PSL workshop) has published the first part of a two-part podcast interview. Tobias Fors and I are asking the questions BTW.

Part one of the podcast: http://johannarothman.libsyn.com/index.php?post_id=388435

As if a two-part podcast wasn’t enough, I have a text based interview coming up with JR as well. Stay tuned!

Interview with Jerry Weinberg

After another dozen decades or so of incremental improvement, we’ll begin to see some really fine software development. Well, I shouldn’t say “we,” because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

(Update 2015/03/21: This interview was originally published in PNEHM! late 2007. Since the original link has been broken for a while I decided to paste the interview below.)

Q: You’ve been active in the software development field for more than 50 years and still no signs of retirement, what’s fueling you to keep on going?

A: It’s like Edmund Hilary said when asked why he climbed Mt. Everest. “Because it’s there.” I first read about computers, when I was eleven years old–then they were called “giant brains.” As a smart but miserable young kid, I understood that if we were to conquer misery, we would need more brainpower. I immediately knew that I had found my life’s work.

So, the problems and opportunities of software development (and maintenance) field have been there my entire adult life. I happened to be born into the age of programming–not just computers, but as deep down as the DNA in our bodies. It’s what the German’s call “zeitgeist”– we don’t have a single word for it in English, but it’s the intellectual and moral tendencies that characterize an age. Intellectually, it’s obviously challenging enough for a lifetime, but morally it’s even more interesting. The concept of programming has given us infinitely more choices for our future. We’re not stuck with what we have up to now.

The Four Horsemen of the Apocalypse are described in the Book of Revelations as Pestilence, Famine, War, and Death. They were seen as inevitable curses of the human condition, but every one one of the four has already been altered by programming, some for better, some for worse. And this is just the beginning. How could a person not keep going?

Q: For more than half a decade we have seen a steady decline in applications to computer science courses here in Sweden. What possibilities are young people, who want to make a difference in this world, missing out by shunning CS education?

A: Not much, not if CS education in Sweden is like so much of it in the USA: of no practical value. I’d say the students are better off preparing themselves for the future by learning to communicate with other human beings, learning to think like an engineer or physicist or business person, and learning to finish projects that always earn an A+, never settling for B or C work. Those things will open opportunities in the future, which by definition is unknown.

Yes, we’ll need software developers. That seems pretty sure. But formal CS education is probably not needed to become a software developer; I never had any. And if it does turn out to be needed, computing technology is something you can study once you’re out of formal schooling–when what you learn won’t already be obsolete. I don’t mean to say that students shouldn’t take CS as a major in college, but if they do, they should pay more attention to the rest of the universe than typical CS programs do.

Q: You’ve written more than a handful of books about how to amplify your own effectiveness, and constant learning and relearning seems to be one of the key elements in those books. What can the typical software development organization do to support learning?

A: First, there’s got to be an attitude that understands how important learning is to a software development organization. If you don’t stay ahead of this ever-changing field, you fall behind. Some organizations work on a business model that hires people whose knowledge is leading edge, uses them for a couple of years without spending a penny or a minute on education, then dumps them for a fresh crop of leading-edge people. What they don’t understand is how much on-the-job learning walks out the door with these “obsolete” people.

Cost accounting would help–cost and value accounting. If you really figure out how much value one correct new idea can bring to a software project, you would never cut short on any kind of education for your software people. So, assuming you value learning, what can you do as an organization? First, budget time and money for it, and don’t cut corners. Have a training budget and a book budget for each person, and make each manager responsible for seeing that those budgets are actually spent. Do not reward managers for “savings” on the education budget.

Part of the budget should be time and resources for every technical person to “play” with new things–tools, languages, algorithms, just trying things out away from real projects. If you don’t do this, people will play (experiment) on real projects, creating real risks. And allow and encourage employee-generated educational events, such as brown bag lunch seminars or reports on training and conferences, reading discussion groups, membership in professional organizations, and visits to sister sites. Create and environment where social pressure favors learning, rather than simple nose-to-the-grindstone, 24/7 work on sponsored projects. You’ll find that your “real” work gets done faster, cheaper, and better.

Q: Talking about eduction, what about miseducation? What do you think is the most widespread harmful idea about software development?

A: That by shouting at people and threatening them, you can force them to produce better software, faster and cheaper. Software development is an intellectual effort of the highest order–but in order to be able to remain consistently at the intellectual level needed to produce software, people need a safe, quiet, properly organized environment. There are no shortcuts.

Maybe I can generalize this dangerous idea into a short and simple and wrong sentence: There are shortcuts to software. Wrong. Wrong. And Wrong.

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It’s a pendulum swing because approximately every decade, there’s a fresh movement to “solve the programming problem.” High-level languages, structured programming, object-oriented programming, …

But it’s a new direction because it’s the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won’t achieve all its grandest promises either, given the conservative nature of human beings, but that’s all right. After another dozen decades or so of incremental improvement, we’ll begin to see some really fine software development. Well, I shouldn’t say “we,” because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Q: Your most recent book is a novel called “The Aremac Project”. You said to me, in an earlier conversation, that what you are trying to do with fiction is to reach more people in a perhaps more palatable way with some of the hard lessons of software development. Without spoiling the story, what hard lessons did you want to portrait in your novel?

A: Nope. The readers have to “experience” the lessons, through the experiences of the characters. That’s the whole point. 90% of people will not or cannot respond to “telling,” which is why all our education is experiential, and why the novels will all teach through the experiences of the characters. I wish that you could get people to use better software development practices (and drop the worse ones) simply by telling them, but that only works for a small fraction of the population. In a way, it’s unfortunate that it works for even a small fraction, because some of those easy-adopters become evangelists, and can’t understand why the rest of the world doesn’t need to be told what’s good, but needs to experience what’s good. That’s at least part of the reason new practices turn out to be overblown. They might be as good as their evangelists say, if only people would use them.

Playwright George Bernard Shaw has been quoted as, “The only thing wrong with Christianity is that no one has really tried it.” That might be a bit extreme, but we might say about certain software practices, “The only thing wrong with X is that it’s seldom really been tried.” You have to try it to learn it, to evaluate it, and adopt it.

Q: Can you give some examples of “talk and no walk” software practices?

A: First, there are the people who don’t walk because they don’t know what walking is. During the structured programming movement, I had countless clients who claimed to be doing structured programming, but when you looked at their actual code, it was spaghetti, spaghettini, spaghettoni, linguini, vermicelli, or fusilli lunghi. Anything you could twist and tangle, they had it–and called it macaroni. In more modern times, I’ve seen dozens programs that claimed to be object-oriented but were merely warmed-over Fortran pudding.

As for agile, the typical words I hear are, “We’re doing agile, but we’ve left out X and Y and Z. They’re not really applicable to us.” At a recent client, I found. X = user involvement; Y = test before design; and Z = pair programming. I’d say it was agile in the sense that “fragile” contains “agile.”

Second, there are management promises that don’t pan out. The most common case I see is “quality is number one,” followed by “we can skip most of this testing we had scheduled, so we can catch up with the coding.” But there are dozens of other cases, all of which management yielding to real or perceived pressures to shortcut processes–breaking configuration management rules, thawing “freezes” to accommodate some big user with last-minute patchy changes (that always fail), not providing promised people or training or hardware or software or facilities.

Enough? It pains me to write about these things, and generally people don’t like to read about them, either. But that’s us, the software development “professionals.”

Q: You seem pretty relentless about quality, why is quality so important to you?

A: Because if you don’t care about quality, everything else is trivial. (I call this The First Law of Software Engineering.) You need to ship on a certain date? If you don’t care about quality, you just ship. You need to cut costs? If you don’t care about quality, you just stop when you run out of money. You need to boost morale? If you don’t care about quality, you do whatever your people want. (Oh, wait a minute. What if they want quality, even if you don’t care? You want to destroy a professional software organization. Act as if you don’t care about quality. The professionals will leave, either physically or psychologically.) So, that’s why quality is so important, not just to me, but to our industry. And, until we start caring, we’re not going to get better. And I know we can get better, because when I’ve worked with clients whose entire business (or people’s lives) depends on quality, they produce quality software. Curiously, it turns out that quality software is cheaper in the end, but if you’re not into long-term thinking, you won’t see that.

Q: I know there are people out there (in software projects that doesn’t deliver) who want to bring change into their projects, but no one seems to listen to them or even care. Rather than resign, comply or quit; where can they look for light?

A: I keep a stature of St. Jude for these situations. I recommend that the people pray to this venerable personage, the patron saint of hopeless causes. That’s if they want to stay (for some unknown reason). If they’re more flexible, I recommend they leave. That’s the strongest message they can give to management. If they just need the money and don’t care about their work, they can comply as long as they keep drawing their pay. This is usually bad for their health, their family life, and their professional self-respect.

But your question has ruled out all three of the above recommendations, so is there anything else. Yes, there is. Whatever the situation, you can LEARN. Put yourself in learning mode at all times. Improve your technical skills by practicing and mastering new techniques and tools. Improve your listening skills by picking up subtle clues as to what disaster looms next. Practice your speaking and writing skills (outside of work, if you get punished for trying to communicate the way things are and what might improve them). Learn to say NO to meaningless or destructive assignments. All these things will serve you well in the future, and can be justified in your own mind because they’re the only things that have the slightest chance of improving the situation.

You might also read Kipling’s poem, IF, and learn to do those things he suggests, that will be a good use of your time, and on a death-march project, you’ll have plenty of opportunities to practice what Kipling suggests, such as:

If you can keep your head when all about you
Are losing theirs and blaming it on you,
If you can trust yourself when all men doubt you
But make allowance for their doubting too,
If you can wait and not be tired by waiting,
Or being lied about, don’t deal in lies,
Or being hated, don’t give way to hating,
And yet don’t look too good, nor talk too wise:

Read the rest of the stanzas, too. And above all, learn to recognize these situations early so that next time, you can stay out of them in the first place. And, save your money so you won’t have any financial excuse for skipping out when you do find a better situation.

Q: You said “novels”, was that a freudian slip?

A: I have 8 more novels circulating among publishers and agents. It’s quite
a bit harder to get fiction published than it’s been for non-fiction,
and I’m still a novice fiction writer. My most recent non-fiction book
(on testing) was accepted by the publisher in less than 30 minutes. Of
course, if I were J.K. Rowling, I’m sure I could beat that time with a novel.

Q: If you’re the J.K Rowling of software development, who’s Harry P then?

A: Well, first of all, I’m not a billionaire, so it’s probably not correct to say I’m the J.K. Rowling of software development.

But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because “he’s only a tester.” As for Voldemort, I think he’s any project manager who can’t say “no” or hear with Harry is telling him.

Book Review: The Aremac Project

Gerald M. Weinberg has covered the area of systems thinking, writing, and secrets of consulting with a handful of books already. In the light of his previous publications “The Aremac Project” is perhaps an odd one – it’s a thriller, not a handbook. “The Aremac Project” is a thrilling story about young geniuses, terrorism, FBI agents, bombs, a mind reading device, and above all it really is a story about a software development project. Software development is a rare subject in fiction, just Douglas Coupland comes to my mind. This is perhaps a story that could have been written by Coupland. Though Weinberg does not bend the language like Coupland does in his writing, the amount of absurdity in the story is on the same level.

If you’ve read any or some of mr Weinberg’s other books you’ll see pieces of wisdom sprinkled throughout the book. Like the “A Buffalo Story” from “The Secrects of Consulting”. “He’s like a buffalo. I can get him to do anything I want him to do, as long as he wants to do it.” And there’s a Robin Hood character, the “Bag Bandit”, who teaches beaurocrats about queueing theory and systems thinking.

The heroes of this story, the two married genius hardware and software engineers, Tess and Roger, are assignend to a federal funded anti terrorism project, with the aim to develop a mind reading device, lead by professor Wyatt. Tess and Roger are of course not informed about the true origins of this project when they sign on the project, but the implications of the project are bound to make them aware soon enough. Professor Wyatt turns out to be utterly incompetent. In fact, you could read the book and use his examples as anti patterns for project management. Professor Wyatt isn’t just an incompetent leader, he’s a dangerous programmer as well. A hack in the Aremac’s control program’s compiled code causes a massive electromagnetic jolt to be released while Tess is strapped to the machine, rendering Tess to a stable paralyzed condition. With Tess paralyzed, Roger turns his focus on helping Tess back to normal, using the Aremac technology. At the same time a group of terrorists are bombing soft targets in Chicago and the FBI is growing more and more impatient to use the Aremac. Tess and Roger are soon entangled in a very challenging software development project.

Does it end happily? To find out, you’ll have to read it yourself. If you are a swede you might be a little surprised in the end…