Skip to content


If you don’t care about the customer, why bother?

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?

Posted in Thoughts.


Meet the new world. Same as the old world.

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.

Posted in Thoughts.


Is the honeymoon over?

My father-in-law used to ask me this relentlessly after my wife and I had just gotten married.  There was a specific definition he had in mind.

I’m asking that question about the iPhone.  Like a progressing marriage, I’m finding the quirks and limitations of the platform.  Some of those limitations are now obvious in the implementations of some of the system applications.  That’s not to say the applications aren’t great, it is just clear that the developers of those applications hit some of the walls that I hit and worked around them.

The point is that they need not be deal-killers.  Just like any software platform, there are bugs and limitations.  The truly talented people are the ones who sees the platform for what it is and what it can deliver, rather than what it can’t do out of the box.

In the days of Windows CE, I did quite a bit of support work with the developer comunity on the newsgroups (does anyone run news servers anymore?).  You could see difference between people who were looking to solve the bigger problem and the people who were looking to have their problems solved.

That is the line between the casual and the committed.

The honeymoon might be over, or it might not.  I’m facing some big challenges and spending some serious time on the gameulation (yes, I made that up) product that I’m working on with another company, so much so, that I’m delaying releasing my completed app — I just haven’t been able to bring myself to make a trip to RadioShack for some testing equipment.  I’ve got too many challenges in my current project to make the time during my daily (and nightly) focused development time.

The great news is, however, despite the challenges, the app I’m building is looking pretty good.  Going from a kernel of an idea of how I’d do the things I’m doing to the realization of the first stage of that mental design on a platform, language and framework I’d used to develop one small app has been a great challenge and liberating mental exercise.

Posted in Uncategorized.


iPhone — a pretty good developer experience

With the right kinds of starting points and examples, iPhone programming is pretty easy if you’re experienced with programming in general.

Let’s face it, my interest in Macs is recent.  I’ve never used one daily for work, and I’ve never been in a situation where I’ve developed *for* one.  I’ve developed on one, for Windows using VMWare Fusion and Visual Studio and I’ve written some stuff in Ruby on one, but this has far less to do with Mac than it did with writing Ruby code — it was back-end code, so I avoided the UI questions…that time.

With the iPhone, that’s not the case.  You can’t hide in the back end, and you can’t just ignore the UI issues.  Compelling iPhone apps go beyond the simple form-based apps I built with embedded Visual Basic on Windows CE.  They need a slick interface, things need to flow, to be dynamic and to fit into the framework.

The odd thing is, and maybe it’s just me, it comes fairly easily with some work.  If you’re just starting out, I’d suggest a few resources.

First, peruse Apple’s document: The Objective-C 2.0 Programming Language.  Personally, my head doesn’t just absorb a language by reading about it, so once you get through the first bit and have your interest piqued by the language’s capabilities (and it is an interesting language – with an ugly syntax, in my opinion), you need to give yourself an assignment.  Something to start kicking the tires of the platform and the language with.  You’ll come back to this document later.

While you’re thinking of your project, the next thing I’d grab is The iPhone Developer’s Cookbook by Erica Sadun.  Daniel Pasco, CEO of Black Pixel Luminance described it as, “…the Petzold book for iPhone developers.”  That’s a decent description, but it’s far more practical than I remember Petzold.  This book probably has a description and a decent sample for most of the things you’ll do in your tire-kicking project.  It’s an easy read and a practical guide to getting things done, so save your in-depth, what parameter do I pass to this to do that questions for the Apple documentation.

Speaking of the documentation, being unfamiliar with the Xcode help system, I didn’t have my searching set to full-text.  Figure out how to do that and as you look for flags and methods, you’ll do much better.

If you’re the kind of person who says, “I can probably do that” when it comes to new platforms and new programming challenges, I’d say you’re only practice away from being able to do it on the iPhone.

If you find that maybe you don’t have time or the ability to get going, let me know.  I’m always happy to discuss ways in which I might be able to give you a hand.

Posted in Uncategorized.


Which do you like better, the business or technology?

One question I’m frequently asked is, “you seem to have experience working as a business interface lately, what do you like more, technology or working with the business?”  I never know if this question is a binary test, “if you say business, you’re out” or simply someone trying to understand more about who I am.

Recently I explained that my bias was 60/40 on the technology side, but that’s sort of an arbitrary, made-up answer, which I quickly confessed to the person I was having the discussion with.  There are many applications for technology, particularly software, and it happens that the place where I’m personally most focused is in the realm of understanding a business challenge and solving it with technology.

It ends up being a very interesting question, and one that has career and success implications, no matter how you view yourself — as a technologist, a business person or somewhere in between.  Technically, I’m somewhere in-between, I suppose.  I’ve always been focused on business issues.  As I discovered my career direction in school, I considered economics, business, journalism, and even this odd music technology hybrid.

As I find myself in roles at the intersection of those things that I enjoyed combined with what I finally earned my degree in, Computer Science, I have the most fun and consequently have the most impact on a product.  The fact is that you don’t have to be a team leader, interfacing with the business, to make the most of that combination.  You can do it with your IC dev hat squarely on your head, or as a dev manager, or wherever you live.

I’ve always believed that one of the foundations to getting a team running well is to foster clear understanding of why we do what we do, to build up the information that everyone needs to make decisions into the collective consciousness of the team.  That way, when a developer is sitting at home or in her office late at night coding some new feature, they don’t get stumped and have to find a PM to answer an email, or a business partner or me to decide what to do.  The understanding is in their head, for the most part, and they can proceed and check in on their decision in the morning when people are around.  If the team truly understands what it is trying to accomplish the right decision usually gets made.

But what is the team trying to accomplish?  Sometimes it’s an internal development goal.  We need to re-architect the file structure.  We get it, it’s a technical goal, clearly in our domain.  Decide and move forward.  But, what happens when the feature is requested by the business?  You need to understand the business.  You need to think like the business and act like the business to decide just exactly what it is that the business wants, or more specifically, since we are technologists, we need to decide how to translate what the business wants into what it really needs long-term.  If you don’t understand the business, it is difficult to accomplish this.

In a Microsoft-style organization, this role might fall to the PM, but still, if you’re writing code, the more you understand of the business, of your customer, the more likely you’ll produce something that they like and ultimately need.

How do you foster this in a team?  That involves communication in several areas, and most of all, relationships.  In the technical documents, make sure that there is documentation of the problem and what the customer or the business partner expects and needs.  In team meetings, take opportunities to discuss the projects and talk about wins and losses for the business based on what your team does.  Tie your success to the business’ success, and do what you can to help the business succeed.  Have the business representatives come to the team and talk about their plans, highs and lows and how your team fits with their success.  One of the most empowering things for a team is to have the people that care come and say intelligent (this is very important) things about what they do and how you help them do it.  This can backfire, however, if the discussion is not thoughtful and shows a lack of insight into the business and/or the technical challenges that the team faces.

One of the most inspirational moments on one of my teams was when one of the senior executives came to my team and said, “that little thing you did for us at the end of the last release is going to save us $4M in costs over the next year.  Thanks.”  Why did we do that little project?  First, the business knew us well enough to ask if there was something we could do.  They knew us well enough to know that we would be receptive to the idea of helping the company over the long-term even though it made our short-term work a bit harder.  We understood our priorities.  We succeed when the business succeeds, and we know that when a little extra effort is traded for a big payoff for our partners or our customers it is almost always worth the effort.

So, keep focusing on your relationship with the business.  When there’s a problem that needs solved, have key members of your team be involved in the solution process, whether that means fixing the problem or just being along for the ride, offering help and suggestions.  Without wasting time and creating randomness, push the relationships with the customer as low on the team as they should go and from the manager seat, set the priorities, the tone of the team and track the things that are coming out of the relationships you’ve fostered.

Measure yourself like the business would measure you.  Help your partners understand how to measure your success and follow up by doing the measuring.  If you impact sales, make sure that every release meets that goal.  Use randomized testing to be able to clearly state, “We succeeded.   Our goal was to raise metric X and reduce metric Y.  The test demonstrates that we delivered exactly that for our customers who were exposed to the new system.”  That would have meant +$Z in sales last year.  Make sure that from the intern to the managers everyone knows exactly how you succeeded.

Be the solution and information source.  Solve problems and provide the data that the business needs to understand its performance better.  Be their partner and you will, by working closely with them, have more empathy and understanding for their priorities and goals.

Most of all, prioritize.  Prioritize the projects, prioritize the customers and prioritize your values for code, documentation, testing and every part of the process.  Make sure that everyone has a foundation upon which to make good decisions about what the team should be doing and the team will naturally start to move mostly in the right direction.  That doesn’t absolve you of understanding what the team does, it just means that there is usually positive momentum in the direction you need to go.

If you do it right, one day, someone will have an insight that you never would have had if you hoarded the information, the priorities and the relationships, and you will see your team do something amazing.  They’ll do the right thing without you having to ask, suggest, hint or manipulate them to do it, and in that moment, you can breathe out and savor your success…until someone comes to your office with the next crisis.

Posted in Thoughts.


CV Posted

I’ve just posted my background information here.

Posted in News.


The Beginning

Everything has to start somewhere, and today I announce that Deep Focus Technologies which specializes in Software, Technology and Consulting services is open for business. I’ll post more on my background soon. I’m currently spending my time developing iPhone apps. My first application is nearly done, so I’m racing Apple’s approval of Deep Focus Technologies into the iPhone App Store. After the first app, I’ve got a backlog of projects and ideas waiting to be implemented. If you have ideas or technology needs, I’d love to discuss them with you! You can contact me at matt at deepfocustech dot com
test link

Posted in News.