I’ve been agonizing over the purchase of a to-do manager for the iPhone for several days.  Reading the reviews, both on the app store as well as on various review sites on the Internet didn’t bring much clarity.  It wasn’t that I was all that freaked about about buying the to-do program, I wanted to make the right choice and buy the right software for what I needed to do.

So, I went with what I knew.  The program I purchased an iPhone front-end for an online task manager that I’d been using for over a year quite succesfully.  In fact, I had purchased this company’s Blackberry front-end for this service and had been quite pleased with it.  It was updated frequently and reported bugs were fixed.  In fact, I’d traded emails with the developer surrounding some issues in the past.

The reviews on the app store weren’t great.  Some of the early reviews complained of the cost.  I dismissed these.  There were some that complained about crashes, but how bad could it really be?  These guys had been building decent software that I’d been using for a year.

The reality is that they were bad.  I’m talking extremely bad.  10 crashes in 10 minutes, at least.  It seemed to me that there was some aspect of this software, or of the scenario that I was trying to use that was misunderstood by the developer and simply went untested.  Using the software for several days convinced me otherwise.  It was as if the software wasn’t tested at all.

I emailed the company, including offering whatever help I could provide to give them information to fix the problem — I’d debug it if they gave me the source code.  No response.  I had recently posted on their message boards on the topic of their Blackberry client with no response as well.  There are scattered reports of no response across their own forum as well as a report of contact which was followed by unreturned emails.  The application, which is obviously broken is still on the app store and has not been updated since July.

It is as if this company does not realize or care that it has customers that are unsatisfied by its products.  It doesn’t have the time, energy or concern to fix the issues, nor does the company have the decency to pull the product from the app store.  It is very clear that this is a business that does not understand its place in satisfying its customers.

Despite more than a year of history, I’m walking.  I can’t trust that this company will maintain their services if they can’t even pull completely broken software off of the market.

The thing that is most interesting to me is that this company also provides software development consulting to some big-name companies and probably some not-so-big companies.  I can’t imagine what their consulting customers must go through as they try to get completed software delivered to them.

I’d like to think that their consulting business works properly and delivers good software and fixes the defects that the customer reports.  Maybe this activity gets in the way of me, the little guy, who just wants to manage the things he needs to do.  If you can’t trust them to do the right thing with a $9.99 piece of software with their name on it, can you trust them with a $9,999.99 piece of software that has your name on it?

Sometimes I feel like a dinosaur.  I went to school and cut my teeth in software development in an age where, to get acceptable results, you needed to understand what the computer was doing.  That meant understanding size and space tradeoffs.  It meant explicitly controlling the computer and its runtime so it did what you needed it to do, rather than what it wanted to do.

There were glorious hacks in the late 80s that were clearly innovative ideas designed to squeeze the most out of platforms.  The virtual memory linker was one.  In order to run more code than could physically fit on an x86 DOS machine, a linker was implemented that cut your app into pages that could be swapped in and out of memory and executed.  To make that technique work better, we worked with a company called MicroQuill which built an analysis tool that, after studying your program’s execution (don’t forget the hours, days, nights and weeks of instrumentation), rearranged your functions into pages where they had the highest probability of being called by another function in the same page.  Memory was small, disks were slow and we needed to squeeze every ounce of potential power out of the platform — for our customers.

The reason this all comes back to mind is because of an interesting discussion about garbage collection and memory management on an iPhone discussion group.  In today’s web world, many commercial sites are based on script languages.  Many of which are extremely powerful and fairly quick.  The ability to run on such high-level languages is a testament to the computer hardware that we all have cheap access to.  Many developers do amazing things with lightning speed on such platforms.  If your resulting app runs slow, get more hardware, or order up some additional compute resources from the cloud.  Problem solved.

An iPhone developer was lamenting the absence of the garbage collector in complex structures where the graph is difficult to follow and apparently clean up after.  The discussion was in the context of autorelease pools being inappropriate for that task.  Interestingly, the GC, while handy and making things much easier for developers, works on explicit actions.  For an object to fall out of the the reference tree and into the garbage collector, you have to explicitly do something to remove that reference.  This activity seems like exactly the moment you would want to perform memory management — to reduce the retain count (refcount for you COM dinosaurs) count on the object that you’re done with.  Just a bit of extra code to explicitly do what you want the GC to do for you.

The iPhone lacks a garbage collector, but the Android has one.  Advantage Google?  Perhaps not.  The way I tend to think about this is that Apple decided explicitly that they didn’t want GC running while a developer wanted their code to run.  The consequence of this is to either hold collectable references longer if you have a GC or make the developer explicitly do the work.  As a developer, I don’t want unused memory stuck waiting for a process that will “steal” CPU cycles from me for the purpose of discovering stuff that my code explicitly said that I’m done with.  Why walk an allocation tree when you don’t have to?

On the other hand, if I was designing a platform to be easy to develop for, or one where additional compute resources were available simply by scaling horizontally, I’d make developing code the easiest and fastest process possible.  The thing that is interesting to me is that it seems that it is easier for a “dinosaur” who is used to doing things themselves and has a relatively deep understanding of what’s going on at the lowest levels to adjust to a less-constrained development world.

While I’m not sure that this is the case for the people I’m discussing this with, people who see horizontal scaling and cloud compute power as a resource only limited by cash, perhaps ponied up by an investor, have a more difficult time adjusting to doing things themselves, and truly understanding the cost and implication of their decisions.   It is a tough realization when you find that buying a second iPhone doesn’t make the app running on the first one any faster.