The Marketing Machine

With the wild success of the recently released design patterns cards I have found that traffic inevitably draws “piggy backers”. Until this point I had never considered this kind of marketing, favoring a more direct approach. As I browsed some of the sites that linked to my post I found the same thing on all of them. A site had traced down through all the links originating from my post and had promoted their own goods there.

So I visited – a couple times. The site is actually pretty good, at first glance. I have not taken the time to delve into the real meat of the material yet and have since decided not to. Mark Turansky evidently followed this chain deeper than I and found that the site is simply an attempt at pushing an e-book outlining all the design patterns information. This, in itself, is fine. Linking to my site is fine. Linking to links off my site is fine. The message they are pushing, while doing all of the above is not.

As Mark’s post points out there are a number of ludicrous claims being made by the “publishers” of this book, most of which revolve around the book having supernatural powers. The book is touted as being able to do things like, “get your tasks done twice faster, write bugless code and create an efficient and reliable software architecture”. There are a couple problems with this. First, the use of design patterns generally does not speed up the engineering process. It instead shifts the focus of the work from initial coding, bug fixed, and maintenance to the initial design work. The basic premise of a good design is that it is easy to implement and maintain – not necessarily easy to write or create. Second, bugs are a function of developers. People are prone to error and are thus unlikely to ever write bugless code. So unless this book will make you superhuman, write code for you, or will provide a mechanism to automatically fix bugs I seriously doubt it will ever provide you with less bugs. Mark covered this in pretty good detail so I will leave you to read his post – he also includes “testimonials” that are very obviously fictional.

I applaud the marketing effort. It is effective (at least it appears to be) and it will likely drive some business to the site. However, I loathe pushy marketing practices that attempt to dupe consumers into buying a fictional uber-product. If this site simply had good information, real testimonials, and realistic claims I might even be inclined to buy their product. As it is, this won’t be happening.


Customer Service Sucks

Stick with me – this isn’t just a rant. There are some (hopefully) useful tips to follow.

I remember the days when you could call up a company for just about any reason and speak with a relatively polite and helpful person. Unfortunately those days weren’t too long ago. It seems, at least from my perspective, that the state of customer service is in decline. The chances of talking with someone who is both polite and helpful at any given company is a long shot indeed. However, this trend is not the rule in all cases. One of the few companies I have had a recent good experience with (there are more but I am at a loss right now) is Bank of America. I can call for virtually anything and be treated with dignity, respect, patience, and kindness, even if I call with a totally asinine question, which I occasionally will do.

As I discussed in my post, Outsourcing and the Economy, the current focus of our increasingly globalized world is centered upon low cost and fast turnaround. Unfortunately, the attributes often embodied by low cost and fast turnaround atmospheres will typically clash with the customer’s vision of good service. One only has to look to the local “department” store. I loathe going into Wal-Mart because of the emotional atmosphere that has been set by the lowest possible cost mentality. Likewise, I dread the customer service Nazis at Target when returning an item.

So what is the underlying issue here? Companies have come to focus more on one set of stakeholders than on another. As a customer I am a stakeholder in companies I do business with by virtue of my market transactions. Employees are stakeholders as they have a vested interest in the output of the company. Shareholders are stakeholders as they provide funding and expect a return on investment (ROI) from the company. Of these, who benefits most from customer service? Who benefits least?

What this really comes down to is a marketplace tug of war. Customers demand a certain level of customer service, which requires funding, while equity holders require a return on investment, which also requires funding. If the funds are at odds with each other the source that is able to keep the company afloat is typically going to win out. So this conundrum really has two facets. First, stakeholders must understand the importance of foregoing a portion of their ROI with the understanding that it is an investment in customer loyalty. Second, customers must understand the relationship companies carry with their shareholders and must make attempts to limit actions that will cause an unnecessary use of funds. This could be as simple as looking up store hours on the web instead of calling and speaking with an operator or could be as complex as not returning that item that broke because of consumer negligence.

So I filed this under both business and software and have posted this to a number of software related aggregators. Why? Because software is business too. If you fancy yourself the savvy leader of a software firm, have plans to launch your own software empire, or totally hate software but see or find yourself leading a company take this advice to heart: focus on the customer first and the bottom line will come. The goodwill gained will help in two ways. First it will gain confidence in the hearts of consumers. Second, and possibly more importantly, it will avoid negative reactions from consumers. I will remember the poor service that has caused me to shun BellSouth far longer than I will remember the good service that drew me to Bank of America.

Value the customer and profits will follow.


A Socket-based Java Mail Client

A while back I found myself with a need to send email through Java. I can’t remember the reason why I didn’t use JavaMail (this was 2002-2003 so it may have been before it was released/stable) but I ended up implementing my own version of RFC-2045. After a long time of coding and testing I emerged with a working mailer, which I am going to share with the world now.

I don’t see any reason why you would choose to use this over the JavaMail package or something similar – I am not endorsing it for use but simply for nostalgia and learning purposes.

If you are interested in downloading the entire source, you can do so here: mcdonaldland-mailer.zip