The World of Jay Little
The Anatomy of an Epic Fail
10/22/2014 11:02 AM
I just finished reading an article detailing an idea for modernizing the US Postal System and I have some thoughts that I'd like to share. Before I begin, I'd like to take a moment to explain why the following critique is so important to me. The long and short of it is that as a software developer, my career essentially consists of solving problems. Software is just the tool I tend to rely upon for getting the job done. Throughout the course of my career I've run into many people who were terrible problem solvers and the people who birthed the idea I'm about to shred exhibit all of the qualifications necessary to join that particular group.

The basic premise of the idea is that sending snail mail is too hard. That's right, you heard me: too hard. You need an address and postage stamps and that's essentially too much to ask. In an effort to solve this problem the hipsters in question have created a system called Signet that requires the following:

(1) Every user must have a "device that uses a laser to etch it with your name and a unique identifying pattern", the result of which will act as the stamp.

(2) The delivery organization must create and maintain an extensive database of all available recipients that can be used for delivery so that the sender doesn't need to know the address of the receiver.

(3) A ubiquitous app that can facilitate real time communication between the delivery service, the sender and the receiver.

So what are the gains here? Well instead of needing a stamp and an address, now all I would require is the device that etches my signet. Okay so no more last minute trips to the grocery store or post office to pick up stamps. That's nice I suppose. Apparently I don't need to know the recipient's address either. On the surface that appears quite convenient.

The only problem is that it is not. Names are not unique. Addresses on the other hand are. Much like an email address, a street address allows us to essentially pinpoint the destination for a parcel with very little information. This system is amazingly effective when it comes right down to it. By forcing delivery to rely upon knowing the recipients name, you create a number of new problems that the new system appears to completely ignore:

(a) The app allows the user to designate the recipient after the delivery organization receives the parcel. This is convenient for the user but increases the burden on the delivery organization. It also increases the possibility of a parcel being delivered to the wrong person. If I have a friend named John Smith, how easy is it going to be for me to use an application on my phone to decide which John Smith should be receiving my parcel? Oh if this particular John Smith is on my contacts list, the problem is solved. But what if he's not? What if I run an online store front and I need to deliver a purchase to a customer? How do I identify the correct John Smith? Now this may sound like nit-picking but this portion of the idea represents its greatest failure because it's ignoring the reality of implementation. Not only does the delivery organization have to maintain a comprehensive list of recipients, but it also has to effectively make that information available to any patron of their services. Consider the consequences of that for just a minute. There are a lot of people that I would like to keep my address from and this system would by it's very nature reveal that address to anybody who wants the information. That's hardly an improvement over the current system.

(b) The app allows the process of delivery to begin without all of the required information being made available. Yes this makes it more convenient for the absent minded among us who cannot be bothered to look up somebody's address and write it on the envelope, but it creates a new and very real problem for the delivery organization. What are they going to do with all of these parcels that are missing pertinent information? Do you have any idea how many parcels an organization like the US Postal Services handles each and every day? This portion of the new process creates a massive new problem in the form of local Post Offices requiring temporary, secure and easily accessible forms of storage in order to compensate for their customers inability (now apparently a requirement) to provide all of the required information up front.

(c) The app requires that anybody wishing to send out a parcel use a special device that can etch their unique signet into an envelope. Call me crazy, but that device sounds like it's going to be expensive. On top of which, it sounds like allowing users to incorporate their own customization into the signet will serve as a breeding ground for other problems. For starters, where do I customize my signet? Presumably within the aforementioned app. How does that information end up in my etching device? Presumably it can sync with the delivery organizations online system somehow. Does that mean my etching device plugs into a computer/phone? Can it connect to a wireless network for this? Just how complex is this particular device?

The bottom line here is that while this idea sounds wonderful from a technology standpoint, it doesn't actually improve the existing process at all. For all the flak they take, the US Postal Service is actually exceedingly efficient when it comes right down to it. This process would only serve to lower that level of efficiency and raise the prices of their service all for the sole purpose of allowing the lazy to procrastinate and wait until the last possible moment to decide who they want to send a particular parcel to.

Is that really an improvement? I think not.
JPL Coding, Independence and Ethics Redux
9/29/2014 4:59 PM
As any of my readers know, ethics is a topic that is very near and dear to my heart when it comes to software development. When you run your own shop, there comes a time when your ethics are going to be tested. I thought I understood what that test would entail only to recently discover that I had absolutely no idea at all. To protect the innocent as well as the guilty names have been changed, but the story that follows is quite true. I hope it will serve as an example to the rest of you out there attempting to sling code for a living. Note: You would be well advised to read this and this before continuing.

This story involves two companies, Company A and Company B. Company A is reasonably well established and I've been writing code for them on a contract basis for many years. Company B is a relatively new outfit that I have not done any work for. Company B was founded and is currently operated by a group of executives that were displaced from Company A and arguably is a competitor. Company A has experienced quite a few shakeups recently, one of which recently involved the departure of it's current majority shareholder and CEO. This person made their way to Company B after having their stake in Company A bought out. This person then attempted to purchase a license to the software that Company A paid me to develop so that Company B could begin using it. Company A indicated that it was not interested in that kind of deal as they treat their custom software as a competitive advantage.

The story does not end there. At this point the executive from Company B decided to contact me. This person made it very clear that Company B was interested in developing a new custom software solution and specifically told me that they wanted to discuss costs and timelines. I was of course ecstatic as this seemed to the be opportunity that I needed to work for myself full time once again. So I took the meeting. As I came to realize very quickly after our meeting began, that is not what Company B was interested in. Company B actually wanted to acquire a working copy of Company A's software. When I suggested various arrangements Company B could attempt to make with Company A, they informed me that they had already tried all of these things and their efforts were met with a lack of success. This is where the meeting took a turn for the worse. This representative of Company B made a remark to the effect of, "If Company A goes bankrupt, that code will just end up sitting on a shelf gathering dust and that would be a real shame."

At this point I thought it would be prudent to inform this person that I would not even consider selling them copy of the source code of Company A's software as such a thing was clearly unethical and it seemed clear that's where this was going. So I did. This representative from Company B seemed to be alright with that though the conversation continued to revolve around brainstorming various methods, all of which were clearly unethical, that could be employed to acquire the source code for Company A's software. The eventual scheme that emerged was one in which Company A would be convinced to license their source code to a particular third party and that third party would then turn around and license a copy of that source code back to Company B. The representative of Company B wanted me to act as that third party.

I am sad to say that I did not reject this idea right then and there. By the time we got to this point, I was thinking strictly in terms of legality and with the appropriate licensing agreements, such a scheme would technically be legal. However in no way could it ever be considered ethical as Company A simply did not wish to license any portions of their software to Company B. The developer and problem solver in me, had for the moment, taken over. My sole concern was attempting to construct a solution for the problem presented to me by a potential client. It wasn't until later when I began to relay the sordid details to my wife and later on to my contacts at Company A that the full breadth and width of the insidious nature of this tactic became clear to me.

The next day I wrote a clear and concise email to the representative at Company B indicating that I would not participate in this project as doing so was not only unethical but would permanently damage my relationship with a current and valued client. I received a response not long thereafter thanking me for my time and consideration. I informed Company A of this incident only to find out that this representative from Company B had been employing a variety of seedy methods in an effort to increase the competitive advantage of Company B over Company A.

The moral of this story is simple: The difference between ethical and unethical behavior isn't always obvious in the heat of the moment. Ethics isn't just about what is legal and what is not. It's about having enough respect for your customers and business associates to recognize that they have the right to be treated as equals rather than as pawns to be moved about on a chess board. Company B clearly doesn't respect Company A and JPL Coding so it decided to deal with us as annoyances rather than as equals. That is very disappointing to me, but at the end of the day, I'm glad Company B revealed this to me as I will not make the mistake of taking their claims at face value in the future.
Search:   [Rss]   [Email]