Nov 09

Some Computer Nostalgica

I thought it would be fun to do a write-up all the different computers I’ve been developing software for over the course of my life so far. I intend to update this post with more details as time (and memory – mine, not the computer’s memory) permits. If you’re not into stories about prehistoric computers, don’t read this post. If you’re not into stories by an old dog complaining about today’s computers, don’t read this post.

We ate stones for lunch back then. Sometimes, there was only stone soup.

I started to get into computers in 9th grade, which was in 1981. Although I wasn’t part of the elitist computer project group, I had a friend who let me sneak in the computer room. Our school had two Apple II+ and an old Wang computer (unfortunately, I don’t remember the model). I do remember the Wang had about 16KB of RAM (magnetic core memory at the time). The RAM module was about at least 1m3 in size). Roughly around the same time, another friend of mine told me that a smallish company in our village was looking for “computer programmers”. So I went and spend the better part of my spare time as a high school and university student developing software in BASIC, PASCAL, C and C++ for various precursors and contemporaries of the IBM PC and, later, the Apple Macintosh.


  • Apple II+ – 140 KB floppy disk. 5 1/4″. Single-sided. This was considered mass-storage. Of course you could use the backside of the floppy disk if you knew where to punch a hole. Of course, you would program it in 6502 assembly language. LDA #$22.
  • Commodore CBM II – Considered cool at the time due to its curvy design.
  • Burroughs B20 series – I vividly remember a Borroughs 8088-based early B20 series computer. It came with an enormous monitor and CPU unit mounted next to each other which was so large it occupied most of my desk and thus about 1/3 of my room as a student. Unfortunately, I can’t seem to find a picture of this system online.
  • ZX 81 – This was the first computer I bought myself from whatever little money I made. It was a very clever, although quite awkward little computer, consisting of only 4 chips on board. It had 1KB of RAM. No, that’s not a typo.
  • IBM /36 – Yes, in RPG-II. No, I don’t remember any of it. I refuse to.
  • Nixdorf 8870 – Programmed in Basic. All variables had 2 character identifiers. First one had to be alpha, second numeric. K4$ was the string holding the current record read from the database. 5 MB hard drive the size of a medium fridge.
  • Sun 3/60 – Using vi and TeX to write a seminar paper at the university.
  • VAX 11/780 – Taking a LISP course at the university. Fully grokked recursion back then. Never learned to implement a proper loop in LISP. Recursion was all I needed. It’s fun bringing the VAX to a halt by running your student’s assignment. “Who is this user LISP70 who consumes too much CPU and way too much memory?”
  • Nixdorf Targon – 68030-based. UNIX. Pretty cool. You could login via 10 virtual tty’s and start a C compiler in each. vi in your 11th virtual tty was still kind of usable. :wq.
  • IBM PC – Yup, the real one. Not the XT.
  • Novell Netware 2 on a 80286-based file server – Novell’s Netware 2 over 10BASE2 (of course) was so fast that we didn’t compile our C programs locally on our Compaq PC’s hard drives, but used the Novell server to host the files instead.
  • Atari ST – My second “home” computer. Fantastic machine. 68000 processor. MIDI interface. I even bought a Yamaha DX-21 synth to interface with the ST. Way cool.

In 1989, a friend of mine showed me a Mac emulator running on an Atari ST featuring pirated Apple Mac ROMs. I knew I had to have one. In 1989/1990, Apple ran a Mac SE promo for students which I took advantage of. Working with MPW Object Pascal and later, C++. Even a simple build of our system took 15 minutes+, which made for a great excuse to watch Snooker on TV all day. Those were the days. The Mac SE was upgraded to an SE/30 via a logic board upgrade later on. 68030 / 16 MHZ. Blazingly fast at the time.

Here are some of the Mac’s I used over the years: Mac SE – Mac SE/30 – Mac IIci – Mac IIfx – Centris 610, Centris 650, Quadra 700, PowerMac 7200, PowerBook 100, Powerbook 160, PowerBook Duo 210, Powerbook 5300, Titanium Powerbook G4, AiBook, MacBook Pro 15″ (which I’m writing the post on). Plus quite a few Windows PCs, 8086, 8088, 80286, 80386, 80486, Pentium based. But I lost track. Not a lot of personality and soul left in the computers nowadays. See, I knew I would say it 🙂


Nov 09

The case for native apps on mobile devices

Start-up time

I find start-up time for native apps generally much shorter than their web-based counterparts. A crucial feature if you want to whip out your device for a quick check while waiting in the supermarket queue (if you have network access in your local supermarket, but that’s a different story). Plus, native apps don’t need to pull functionality & UI over the network, which takes time, too. They just pull raw data. Which shortens the time from “clicking the app in the Springboard” to “seeing the content I want to”. Even if most of the JavaScript is cached locally, there’s still the need to periodically pull updated functionality.

More elaborate UI

Native UIs tend to be more elaborate, more sophisticated and, most importantly, much smoother and faster than any Web-based UI. Which isn’t that much surprising if you think about JITing, network latency issues and the need to download at least part of the UI over the network. Native UIs & apps shave off a few more milliseconds from that crucial start-up time.

Off-line mode

I need a full-featured offline mode. There’s no such thing as 100% cell coverage. Connection to the 3G network is (and will be for the foreseeable future) spotty at best (No, most of us don’t live, work & play next to a cell tower 24/7). I even have dead WLAN spots in my house. And you do, too. I can’t get to my carrier’s data network from the local supermarkets checkout line. That said, there’s some room for improvement even for native apps whose primary purpose is displaying content pulled from the internet: Off-line access should be designed right into the app instead of being tagged-on as a second thought.


Pulling less bytes over the network, no need for JITing etc. means less battery drain on my device.


There are iPhones users out there which do not have a flat rate data plan. Having native apps, even for simple games or utility apps which could be done as a web-page, is crucial for this type of mobile user. Even a few bytes send over the carrier’s network cost these users an arm and a leg (on non jail-broken iPhones, access to the carriers network cannot be easily turned off).

Update I

There has been quite some discussion on Twitter about Web apps featuring offline modes, slick Javascript UI libraries for iPhone etc. I seriously doubt that @chockenberry‘s stupendous Twitterific could be done as a Web app with the same attention to detail & performance. And while web apps & technologies are catching up in terms of functionality (and they still have some significant catching up to do), native technologies do not stagnate, either… I think each every point I made still applies today (and will apply for the foreseeable future) in the mobile space.

Web technologies are great for building certain types of applications, e.g. traditional database-driven applications, fully replacing what used to be client-server applications back in the paleozoic era. Web applications work great in an environment where either network connectivity is the norm or where you have discreet slices of time with stable network connectivity – but they will have a hard time catching on big-time in the mobile space.

Update II

John Gruber makes a similar, albeit way more elaborate and way more well-thought-out point. He is still more optimistic about the future of web apps on mobile devices than I am.

Nov 09

AdMob mobile ads…

Ads shown in Tweetie, Twitterific or NetNewsWire are delivered by The Deck (which specializes in ads for a specific target audience). These ads are relevant to me. In fact, these ads are so relevant and interesting that sometimes I wish I could turn on the ads although I licensed the product. Plus, and that’s big plus, the ads are tasteful and well designed. Another big plus, maybe the biggest plus of all is the way the ads are integrated in the applications. They are part of the natural flow and UI of the application. No content is obscured. Nothing flashes or moves. I almost look at the ads as part of the applications content. Close to perfect.

My observation is that mobile ads delivered via AdMob in different iPhone “Lite” apps are neither. They are neither well designed, nor relevant to me nor are they well integrated with the apps. Most of the time they slide in, obscure content and are generally very annoying.

[Update: Another great ad network delivering tasteful apps is Fusion Ads]

Nov 09

Follow-up on “Reasons why we chose JIRA over Fogbugz”

I received a thoughtful e-mail by Michael H. Pryor, President of Fog Creek Software, developers of Fogbugz regarding the concerns I voiced regarding Fogbugz. Much appreciated. I don’t have his permission (yet) to publish the mail, so I post a few clarifying points here without citing his mail:

Fogbugz is delivered with source code (both was back then and still is today). What made (and still makes) me kind of uneasy about the source code delivered was that, AFAIK, FogBugz was developed in a proprietary programming language and was cross-compiled to PHP. I’m not implying that this would have caused problems, just saying I prefer the more straightforward Java set-up JIRA provides (although J2EE and straightforward is an oxymoron).

I was really impressed about Michael’s honesty and openness in the Fogcreek forums regarding the problems they had with MySQL a few years back (which are resolved now and where caused by MySQL anyway, as I understand). Plus, even if a variety of database servers is supported by a product, there’s always a “preferred” server, and my impression was (and still is) that this is MS SQL server (which is a very fine product, no doubt about that).

I understand that there are varied views on the “Attachments-in-the-database” issue, especially from a sysadmin / backup point of view, but I’m still a firm believer in the “let the file-system deal with binary large objects and make sure to backup them, too” theory.

The points I mentioned caused us going with JIRA and thus Fogcreek losing a few thousand dollars. Having a Fogcreek salesperson actively “supporting” us wouldn’t have changed my point of view.

But the honesty and openness from Fogcreek executives and staff back in 2006 (and Michael’s follow-up e-mail today) earned my utmost respect and cause me to still recommend to everyone to check out Fogbugz, especially if they’re into using the bugtracking system for e-mail support, an area where there’s lots of room for improvement in JIRA. Having sales staff trying to “persuade” us or “trying to give us all the facts” wouldn’t have had this effect – au contraire.

Nov 09

Bugtracking is not a platform business, either…

Just my 2c worth regarding Does slow growth equals slow death?

I vaguely remember a keynote by Geoffrey A. Moore at JavaOne 1997 or 1998 talking about platform and application businesses. In this talk, he was making the point that the market for software platforms is traditionally divided basically into 80% marketshare for one vendor and the rest of the vendors share the remaining 20%, whereas application software markets are more like two or three rather large vendors, let’s say 40%, 30%, 20% and the rest of the players are small niche players.

Although a bug tracking system may sport a healthy third-party plug-in business, bug-tracking is essentially application software, not platform software like operating systems or databases.

Disclaimer: I may have gotten the percentages wrong, but you get the point.

Nov 09

Reasons why we chose JIRA over FogBugz

Please keep in mind that the following points may not apply to the latest FogBugz / JIRA versions (check the update below). We evaluated FogBugz and JIRA in the summer of 2006 before going with JIRA. At this time, we’re still on JIRA 3.x due to licensing changes in JIRA 4 and being trapped in interiorcad 2010’s release tornado.

  • With JIRA, we got the source code – in a standard language we are vaguely familiar with using open-source technologies – capable of running on a variety of platforms, including MacOS X which we’re most familiar with (and, quite frankly, prefer)
  • We could start without a separate database server. Plus, no need to license SQL server. Forums were quite clear at the time that FogBugz and MySQL didn’t play as well together as we needed
  • Attachments in FogBugz were stored within the database (at the time). This was the showstopper for us. At least 50% of our 18000+ issues in JIRA have 5MB+ attachments to them. I don’t want these bytes in a relational database. Don’t tell me this is no problem with database server XYZ. I have been a database guy for a very long period of my professional life. No binary large objects in my databases as long as I can still breathe.
  • We didn’t want to administer a Windows server machine – Although FogBugz could be run on Linux or MacOS X, the forums showed that the jury was still out (at the time) if this was a good idea
  • Licensing – There was a unlimited users license of JIRA at the time, which was more affordable for a smaller company like us. This has changed with JIRA 4 (for the worse).
  • Plug-ins – There was and still is a lively plug-in community for JIRA – I understand that the latest version of Fogbugz offers plug-ins, too

One area where FogBugz is way better suited to our needs is E-Mail integration. Basically, e-mail integration in JIRA sucks for us. Way too complicated to set-up & manage. Plus, the e-mails sent out by JIRA are basically unusable for end-user support (at least without a lot of tinkering).

Overall, we have been very happy with our choice. JIRA has been extremely reliable for us – which is requirement #1. We need to get our software done. We aren’t paid for fiddling around with third-party software (for set-up information go here, you will be amazed). Does its job well. JIRA 4 looks like a substantial step forward in terms of UI improvements. There are quite a few other products from Atlassian which play well with JIRA and which we’re looking very closely at, namely Confluence, Crucible and GreenHopper.

E-Mail integration / Using JIRA for technical support still sucks as far as we are concerned (Small company dealing with thousands of not-too-computer-savvy customers around the world). JIRA is quite enterprisey, and it shows – in terms of set-up, in terms of administration and in terms of features. Sometimes, less would be more as far as we are concerned.

[Update 7/26/11:]

We are now on JIRA 4, 25K+ issues, still operating on a Mac mini, 8GB RAM, Intel Core Duo, 160GB hard drive. In 2010, we purchased Confluence and are running Confluence on the very same mac mini as JIRA. Everything is still solid as a rock. We use JIRA’s internal backup mechanism to back up JIRA’s database 3 times a day, Confluence’s internal backup runs once a day. At night, we clone the hard drive via SuperDuper!. Of course, the Mac mini runs protected by a UPS. Both JIRA & Confluence are still on HSQL (I can almost hear the cardiac irregularities of Atlassian support reading this).

My major complaint at this time is pricing:

Our development team consists of 7 engineers, 1 product owner, 1 CTO).

We are heavily invested in Scrum. Therefore, we would love to use GreenHopper. However, we would have to license GreenHopper for all 50 users of JIRA (instead of licensing it for our dev team only), thus adding $550 to our yearly Atlassian upgrade bill. I think this is way disproportional compared to the upgrading cost for JIRA. Thus it won’t happen.

We have a Confluence 100 users license in order to accommodate both our internal staff and partners / distributors.

Team Calendars looks like an absolutely fantastic tool for our development team (sales & marketing uses Exchange, no way of moving them over). However, we would have to license Team Calendars for all 100 users (instead of licensing it for our dev team only), thus adding another $550 to our yearly Atlassian upgrade bill. I think this is way disproportional compared to the upgrading cost for Confluence. Thus it won’t happen.

Oh, and E-Mail integration / Using JIRA for technical support still sucks. But I haven’t given up on Atlassian to come up with a nice JIRA-based user helpdesk solution.


Make sure to read I smell a disturbance in the Atlassian force to get my latest take on Atlassian’s pricing and product strategy.