Answers.com defines failure as:
- The condition or fact of not achieving the desired end or ends: the failure of an experiment.
- One that fails: a failure at one’s career.
- The condition or fact of being insufficient or falling short: a crop failure.
- A cessation of proper functioning or performance: a power failure.
- Nonperformance of what is requested or expected; omission: failure to report a change of address.
- The act or fact of failing to pass a course, test, or assignment.
- A decline in strength or effectiveness.
- The act or fact of becoming bankrupt or insolvent.
(Definition: © 2009 Answers Corporation)
As depressing as it sounds, there comes a point in one’s professional life when we have to face difficult trials, one of those being the ugly word “failure”. I had this happen to me a couple of weeks ago and this is what inspired me to open a blog to share my experiences as a professional Web developer so that others will benefit from it. I know that in a mysterious way I will benefit as well. The experience that I had was mostly due to misinformation, but yet it taught me great lessons. I am going to talk about them shortly.
In late January 2009, my boss asked me to join him and three other departmental managers to discuss a new initiative by the company. At this meeting were present: the president of the company (if I remember correctly), the marketing manager, my boss, business office manager and I. The purpose of the meeting was to revamp our two newspaper websites subscription forms to accept promotion codes and process payments in real time. I proposed PayPal because it is a free service and “ubiquitous”. Managers usually like the word “free,” especially if the service is widely known. The existing subscription form did not use a database, so I had to use one to store promotion codes. Because PayPal already collects billing and shipping information, there was no need for me to reinvent the wheel and do this on the new form. I told them that this project was very straight forward. I promised to deliver the front-end of the application and develop a back-end area for them to be able to manage promotion codes. Pretty simple. The meeting was finished. Of course there were some questions, but the general idea was already in my mind.
I began development of the new application in early February. The business manager and I proceeded to create one PayPal Merchant Account for each newspaper website. I had never had any experience with PayPal payments integration, so this was a good opportunity for me to learn about it. Progress with the application was a little slow at first. I had problems figuring out how to design the SQL database tables that would store subscription package information and associate these with promotion codes. Because I had to deal with more than one newspaper, I also had to take into account the need to associate these with a particular newspaper. I was successful at doing all of this in the end (thanks to my boss, who gave me a few pointers regarding the subscription packages), but when questions started to arise, the only people that could answer my questions (the marketing manager and my boss) were unable to do so. I was referred to the circulation department’s manager since she would be dealing with this aspect of the project.
I completed the front-end portion of the application in a couple of weeks and proceeded to show it to the marketing manager and the circulation manager. The application only implemented PayPal Website Payments Standard, which is very basic and did the trick for what I was trying to accomplish. In my research during development, I learned that PayPal had the ability to do recurring billing, but had not considered it for implementation due to the initial meeting I had with the department heads. None of us could remember why we decided not to go with it. Anyhow, the demonstration went well until I mentioned, “PayPal also does recurring billing.” That set out a firestorm for me. I put my foot in my mouth so deep that I couldn’t take it out. I brought up this feature to them because I was “sure” that they wouldn’t want me to use it. Well, they told me to “look into it.” Now, in my experience, when a client, be it internal or external, asks me to look into something, they actually mean “do it.” So that’s what I did. I spent hours upon hours studying PayPal’s Subscription Button API and integrated it with my online form. I was so excited about it that I told the marketing manager and circulation manager in an e-mail, “I have successfully integrated PayPal subscriptions into the new online subscription form.” I scheduled a demo, but only the circulation manager could make it. Before she and I could meet, I proceeded to develop the administration portion of the project. Once I had that finished, the project would have been rendered “completed” if the managers gave it the OK.
The demo of the new iteration went badly as a matter of fact. It turns out that integrating PayPal’s recurring payments created more problems than it solved. I was so upset that I didn’t bother demonstrating the administration interface because it wasn’t needed. At that point I told the circulation manager that I couldn’t “help” her. The newspaper’s subscription and billing system, which were developed by another company, weren’t designed for what I was trying to do. Long story short, we had to schedule an appointment with this company’s programmer to find out what to do about it.
The Eye Opener
Monday, 10:00 AM. The circulation manager and I had a conference call with the subscription and billing system’s programmer. I found out something quite shocking. It turns out that at some unknown date in the past, the IT manager of the newspaper had sent the circulation manager a link to a “demo” of a new Web-based subscription form that was integrated with both newspapers’ subscription and billing systems. The circulation manager put it in the back burner and didn’t look at it again. The programmer assured us that the company had already paid for development of this new subscription form and that it was ready to go. I don’t know how long in the past that had happened. In a way, I felt part of my burden was lifted from me, but that “damage” had already been done. I was saddened by the discovery, especially because of the work hours I invested in it: over 62 hours.
Lessons Learned and Advice
I know that I have gone a long way to depict the above story and I hope my boss doesn’t mind me talking about this. The point is that I am illustrating something that happened to me as a professional and the steps that I took to look at this from a different angle. Here’s what I learned and my advice to anyone who faces similar situations:
- Make sure the right people are involved at the beginning of the project: all of the people present at the initial meeting in January were important, influential individuals. However, the person who was most familiar with the subscription and billing aspects of the entire project proposal was not present until very late in the project. You are the one working on the project, not them. They just propose what to do and they expect you to do the work for them. It is your responsibility to make sure that the right questions are asked to the right people.
- If all the stakeholders are involved, investigate previous work: when I was in college, my software engineering class taught that one part of requirements gathering includes determining if a previous system is in place. Unfortunately, I assumed that this didn’t exist. My assumption was, “if it had been in place, they would have notified my department to replace the links on the newspaper websites with the new forms.” I was right in my belief, but unbeknownst to me, an “evil” form was lurking beneath the depths of a server located somewhere in the USA.
- Do not, let me say it again, DO NOT under any circumstances become discouraged: part of being a mature person requires dealing with problems in a positive manner. It’s easy to become self-centered and complain about what happened to oneself. Instead, take a step of humility and examine the positive aspects of the experience. Did you learn something new? Did you have fun doing it? What new techniques did you use, devise, or learned to get the job done? The answers to these questions are good experiences that can later be of benefit for you in the future. Few things occur in vain and things happen for a reason. Therefore, dust off and move on, carrying with you a heavier belt of experience. In my case, I learned a lot about PayPal and when it is appropriate. In a later project, I was able to intelligently inform my boss why we couldn’t use PayPal. This project was proposed in late March with a due date of May 1, 2009. I’m still working on it. In addition, I learned new techniques:
- A particularly useful (call it magical) and amazingly simple solution called GhostForm by Jeremy Schneider. This one helped me to solve a big problem I had with ASP.NET Web Forms and PayPal.
- Thanks to two other articles about ASP.NET ListView Grouping (one by Matt Berseth and another from 4GuysFromRolla) I was able to solve another problem I faced during development of this project’s administration interface. I ended up using the technique by 4GuysFromRolla.com because it didn’t require multiple queries.
- Because my PayPal implementation used a database and I had to generate the PayPal buttons on the fly, I had to resort to Encrypted Website Payments (EWP). I found several nice articles about EWP, but one in particular that was helpful was at this forum post on the ASP.net website and also at this article (ButtonEncryption.cs). Thanks to the wonderful developers who contributed the information.
- Don’t worry about the time invested (or wasted, if you prefer): As I mentioned earlier, the time spent on the project, no matter how long it took, how arduous it was, how many tears or how much blood you shed to get the project done, think of the “mishap” as another addition to, well, your experience. Be positive about it. You did not waste your time. This was time well invested. Be thankful for it. The company may have lost resources (with regards to time and perhaps other business opportunities) but you on the other hand will be rewarded later if you act professionally about it. The company will try to benefit from the problem as well and will look for ways to leverage your work.
- Do not point fingers: this is a true time waster, especially in the business world. Finding people to blame for what they did or failed to do will only hurt your reputation and give the impression you are trying to make excuses. The company did not hire you to reveal to them who’s at fault. The hired you to be productive.
“Such is the university of life.” Boy, I can’t remember how many times my mom has told me this, God bless her. Every day is a new day to learn something new or to mess things up, but make the most out of what you have now because if you don’t, you may later wish you had. Life is a roller coaster–it has its ups and downs– and this is no different in the life of a professional. Professional life is an extension of your personal life. How you deal with problems in your personal life will be reflected on how you act at the office.
I hope that my experience will encourage others to keep going and advancing in their challenging careers. If you have anything to add or any links that you would like to share that have other suggestions with how to deal with a failed project, share them with me!