So Friday was my last day in the office at Picsel Technologies. Not just because the office is moving, but also because I’ve resigned. I now have two weeks to get some real programming done before starting my next job on June 1. What that is I’ll get back to later.

I’ve been at Picsel for a little over one and a half years. At many times I have for various reasons not thought that I’d make it to a year there, so I am satisfied with having endured for this long. I’ve learned a lot, both some good engineering practices and also how not to run a company, which might come in handy some day. (Hint: if you’re going to run a company with authoritarian top-down management, it’s important to put smart people at the top.) Working with Picsel’s excellent technology has been a pleasure. I’ve seen things done that I wouldn’t have thought possible before. I hope the technology ends up somewhere where it can be put to good use.

I consider myself very fortunate to have worked at both Opera Software and Picsel Technologies. On the surface they look very similar (enough so for Opera’s lawyer to fedex me a very unfriendly letter when I was leaving) but they’re actually complete opposites. By working with similar kinds of projects (mobile applications for Japanese mobile operators and manufacturers) but with completely different approaches, I’ve gotten unique insights into what works and what doesn’t. Balancing the priorities between technology, products, processes, customers, and employees is essential. I’ll give it a little more time before I write about it though. I am going to utilize this knowledge in my future career.

Anyway, a company is just a shell with logo and a legal department. What matters are the people in it. And the people are what has been the best part of working at Picsel’s Tokyo office. I’ve met the most incredible, competent, and friendly people at the office. Most of them are not there anymore though, so it doesn’t make sense for me to stay either. But the connections I’ve made at Picsel Tokyo, both personal and professional, is what has really made the time there worth while. I consider myself lucky to have worked at Picsel!

I don’t know what the little fellow was up to, but imagine the destruction, had it hit me in the face (I walk pretty fast too). I suppose it had escaped from one of the houses. It probably won’t survive very long, considering it won’t get warm for a while yet and the abundance of cats in the neighborhood. Not to mention its suicidal tendency of flying towards people on the street.

By the way, did you know there’s a population of wild parrots in Tokyo? Escaped parrots have taken up residence in the trees lining the south side of the French Formal Garden of Shinjuku Gyoen. Yes, they are very particular about where they live. They’re larger than budgerigars though, and manage to survive.

© MzePhotos.com, Some Rights Reserved

Anyway, I was going to write about software architecture, not parrots. The last couple of days I’ve been thinking about what software architecture is. The word gets thrown around a lot, and people even carry the title “software architect”.

In my work there’s talk about architecture as well. We’re doing architecture.

Now, I’ve figured out that what gets called software architecture can, in down to the monkey’s balls practice, be classified as one out of five tangible things. I might at some point come up with more, and if you have any suggestion then please leave a comment. Anyway, here they are:

1. Build-time composition
   Can be in the form of invasive composition done by a proper composition system, as outlined in the book Invasive Software Composition, written by my favorite professor Uwe Aßmann. But more often in the form of simple #ifdefs, or link-time selection of different libraries.

2. Design patterns
   This is probably my favorite one. Design patterns are powerful not primarily because the pattern in itself is clever, but because they communicate the intention of the programmer to others quickly. If someone knowledgable reads a piece of codes that says it’s doing a visitor pattern, say, then you immediately know what to expect.
3. Naming conventions
   This might be the most common excuse for an architecture. And I’d count object oriented languages’ attempts to hide things behind (often long) namespace and (often nested) class names as just another naming convention (often termed “object oriented design”). Architecture often seems to take the meaning that things that belong to one part of the system starts with a certain prefix (such as a class name). It’s useful for finding things in the source tree, though.
4. Function pointers
   … in one form or another. All programmers use function pointers, often termed callbacks, handlers, functors, virtual methods, delegates, etc. Function pointers allows control of flow during runtime, but more often they seem to be used as a bad substitute for build-time composition. At some point there seems to be a line where this common code monkey tool turns into architecture.
5. Layers of indirection
   It has been said, perhaps by Mark Twain, that any programming problem can be solved by adding another layer of indirection. It is often implemented in the form of function calls, or by using function pointers, often in combination with naming conventions. Of course any code monkey can do function calls. But by doing small transformations of values and data types, and perhaps branching depending on the data, and letting the next layer do this in succession, one can seemingly achieve architecture.

Barring further bird attacks, I will consider these five items to be the fundamental building blocks of software architecture. Next, I intend to write about how these can be used to create good architecture. Because one man’s architecture is another man’s code bloat.

Joe Sutter, the author of the book (although he probably had a lot of help writing it), lead the engineering effort to design the plane, which does seem like the most interesting point of view to me. Beside the main story of how the 747’s design came to be, he also tells some quite interesting tidbits from the history of aviation and from the aviation industry. These fit in nicely and makes the pages fly by. Unfortunately, there are a few too many autobiographical digressions that I didn’t like, and also the literary quality of the book is very poor, with many repetitions, and sometimes even contradictions. Anyway, not bad for an engineer.

So yes, designing and delivering jumbo jets seems to be very similar to designing and delivering embedded software. The scales are, of course, completely different though. Not only physical scales – where they measure time in months and years, we measure in hours and days – and costs are similarly orders of magnitude higher in aviation.

What struck me as the biggest difference though, when I was sitting on a modern airliner somewhere over the South China Sea while reading the book’s introductory chapters on aviation history, was that the jet airplanes he described in the early 1950s (such as the Dash 80), are exactly the same as the jet airplanes now, 50 years later! They fly at the same speed, same altitude, and use basically the same engines. That’s really terrible! Commercial aviation has surely come a long way since the Wright Brothers flew, but it did so in the first 50 years of its history. I’m glad I work with software.

Even more sad is that even if you double the speed of an airplane, it would hardly make any difference today anyway. The Americans (I didn’t know that before reading the book), Europeans, and Russians all had their fun trying to make realistic supersonic commercial airplanes. But even if they had succeeded, how much of the total time spent traveling is really spent in the air, at cruise speed, anyway?

For example: from my home in central Tokyo to somewhere in central Hong Kong, which seems like a fairly typical scenario, the flight time is on average about 4 hours. Say you have to be at the airport 1.5 h before the flight, and it takes 1 h to get from the airplane out of the airport, 1.5 h for me to go to Narita airport, and 30 min to get to/from Hong Kong airport, and an extra 15 min in either end to go between stations/taxis etc – that’s 5 hours! So even if the speed of the airplane doubled, you’d only get between where you are and where you want to go 20% faster. No, if anything close to aviation, I’d like to be an airport architect, city planner, and anti-anti-terrorist consultant. That would speed things up.

PS. I always thought of the Jumbo Jet as the airplane with two floors, but a significant part of the book is spent revealing how it came to be that the 747 ended up basically not having two floors! How strange.

But as anyone who uses The Gimp can tell you, its interface sucks. It has always sucked and continues to suck to this day. Interestingly, quite often some discussion pops up regarding this sucky interface, and whether anyone should do anything about it – or whether war is actually peace.

Just the other day there was this article linked on Slashdot about some academic-type dudes who have developed a modified gimp that collects usage data, to analyze how people use it and possible be able to improve the interface.

Ok, it’s done at a university so I realize it’s just someone’s waste of time and government money, but still… Anyone who’s ever used gimp can tell you that there’s just one simple, outstanding issue that accounts for roughly half of its suckiness: The Windows (imagine that in place of “The Horror” from Apocalypse Now!). The Gimp opens gazillions of windows – and they’re not contained in one parent window, like every other application in the world, no – they behave like independent application windows. You don’t need academic studies to figure that out. So if you’re editing the graphics to a web app for instance, you switch to Firefox to see the result, and then back to The Gimp, and you have to open like 8 separate windows to get your UI back to the state it was before switching to another application. This gets deadly tedious.

If I were tasked with designing a commercial car – and I’m a software engineer, mind you – when I got to the matter of how many wheels to equip the vehicle with, I would go with 4. Just like that – it’s a no brainer. Every other car out there has 4 wheels. I think it must make structural sense, and people are used to cars having 4 wheels. A mechanical engineer or a car marketing specialist could probably tell you more. The gods know how many wheels The Gimp’s designers would fit on their cars.

Guys! Don’t go buying that Photoshop license just yet! I have a solution to the problem! (If you run Linux you can skip the rest of this paragraph.) Just use a virtual desktop manager – like the *nix guys do. I use one called Yod’m 3d. Unfortunately it’s been bought up by some suspicious company and made commercial, but the last freeware version, 1.4, works good enough and can be downloaded (legally) for instance from The Pirate Bay. Just run The Gimp on a virtual desktop of its own. Linux people have been doing this for ages, but it’s never been habit in the real world, although I heard the next version of Mac OS will have virtual desktops. Anyway, you can have it today, in your Windows. (I used to run only Linux for many years, so I got this habit of using virtual desktops extensively back then.)

There are still a few nuances to work out of The Gimp though. But it doesn’t require a Ph.D. to figure them out. If you, like me, never start using Photoshop, then at least you won’t be annoyed simply because The Gimp is different – it should be!

I wish it had a line drawing tool though.