At my previous job there wasn’t much need for developing screen shots to show the client because often times I was the client. Or even when I wasn’t the client, the people I was developing for were so happy to have something, that anything I came up with, no matter how clunky, was perceived as the best thing ever.

Recently, I had to develop screen shots for a client to help nail down what their interface looked like and how it would work. We started with a few screens that I thought were a reasonable approximation of what the client needed. The client even thought the screens were pretty close to what they needed. Over the course of a week however, we scrapped almost all of the original screens and created some new screens that didn’t exist before. This wasn’t unexpected, but it did drive home the point that clients don’t know what they want until you show it to them.

Today was an interesting day for debugging.

We’ve developed a flash application for a client that didn’t quite work right in IE6. Today the client called and said this is really going to be a problem as most of the people who will be using the application haven’t upgraded to IE7 and don’t use Firefox (hence they use IE6). So I spent some time trying to track down the problem.

I’d looked at it this before and couldn’t figure it out, so this time I put on my Stubborn Hat and dug in. I knew I had a “screen shot” that worked fine in IE6 while the actual application did not. So the first thing I did was make a static document of the HTML generated by the app. Now what? Should I gradually make the “screen shot” look like the application until the Flash bit stopped working? Or should I gradually change the application’s HTML until the Flash bit suddenly started working? Either way it was going to be a long tedious process. For no conscious reason other than “my gut told me to”, I chose the latter.

Actually, at first I thought it must be some quirk of how IE6 deals with javascript since that’s how we interface with Flash. But after a few minutes exploring that idea, I realized that the “screen shot” and the actual application would have the same quirks as the javascript parts were virtually identical. So, I started in on munging the non-javascript parts of the HTML. After quite a while of carefully removing bits of HTML and not getting the Flash portion of the application to do much of anything I was beginning to despair that I’d picked the wrong strategy. It didn’t seem that I was making any headway against the problem. I’d remove a small div and reload the page, remove a table tag and reload the page, etc. Nothing seemed to make a difference (but on the plus side, I had a much smalled document to deal with :-) Then … finally the Flash app worked in IE6!

And what, pray tell, was the problem? The application had a div tag with an id of ‘left’. Change the id to anything else and the Flash parts work as expected.

Yesterday, we had our first day at SXSW Interactive. Each of us had preselected the web/interactive panels that seemd most interesting to us based on the short descriptions listed on the site. Scott seemed to have found several good/great panels that he found interesting, entertaining, and educational. I was a little disappointed with our first day as most of the panels that I attended either were not very informative or the panelists speaking spent more time plugging their products and very little time actually educating the audience or sharing what they learned during the development of their application/site. 

At the end of the day, we realized that this year’s South by Southwest conference is not just about intensive learning sessions and the latest web technologies, but for us as a development team, is more about a renewed excitement and motivation about our own work and current projects.  In addition, SXSW seems to be an affirmation that we are doing things right or making effective decisions with respect to most of the successful businesses or applications development companies speaking.

Years ago (that seems kind of funny to say after my seven years in business) when Niall Durham was working with me, we used to talk about spending an afternoon here and there building cool new apps just to test new frameworks, languages, or ideas.  But on the planned day, we’d get slammed with phone calls or new business, and our ideas sat on the shelf.  For all our planning, we just never got these brainstorm/build sessions started.

Two weeks ago we mapped out a new strategy.  Fridays are “fun days.”   If support questions or sales calls come in, we’ll temporarily focus our energies on that item.  But at the moment the phone call is finished or our client leaves the office, we get back in step with our team project.

Years ago (and this time, I’m talking 20 of them), I worked for an insurance company.  The manager, Tom Lindberg, used to instruct us to “Pay yourself first.”  This directive referenced putting money into your own savings before you spent on the immediately gratifying things in life.  Thunder Data builds software for clients and for our own products, services, and uses.  TDS is going to take Tom’s advice these 20 years later and pay ourselves first.  

Our dividends will come in a myriad of ways.  These are great teambuilding events where we can get excited about bringing an idea to fruition.  Implementing new APIs or testing theories in web applications introduces concepts that may take root in other projects.  The cool stuff we build may have the wow factor that wins over a new client.  And finally, we are creating applications that will add to our bottom line.

With SXSW formally kicking off this Friday night and running through next Tuesday, our old mindset would have placed our creative scheduling on the back burner.  Now, we’ll look at the day as an opportunity to gear up for the conference.

With the challenges we have faced with losing key staff members, I’ve had to step up–or perhaps I should say “step back”–and relearn some of the old programming and HTML code that started me off in this business.  When I told Scott that I was thrilled with the outcome of my first CSS/XHTML/PmWiki conversion in a long time, he said he needed to experience more of those “small victories.” 

Prior to November when M&M went off to Yahoo, I spent such a limited amount of time accessing code in secure shell that I often forgot the password to access it.  Now, I am finding happiness in remembering some of the old Linux command line stuff I learned in Dr. Donnelly’s class way back when.  Today, I thrilled in seeing the work created playing with opacity and z-index style attributes to create a nice little message box.  In short, I’m enjoying the learning process and the outcome of the lessons learned.

Tiny steps?  Yes!  Small victories?  Bigger yes!

Companies strive–and sometimes succeed–in “getting it right”. Think Apple’s Ipod, Peter Jackson’s “Lord of the Rings,” and Converse Chuck Taylors.

Campbell’s Soup is the maker of Prego spaghetti sauce, and it seems the company recently had a short violin piece commissioned to go with one of the Prego TV commercials. Hearing what was described as a “haunting” melody, I had to hear it myself.

The 30-second-spot score was written with the goal of evoking feelings of nostalgia for listeners. The positive response was so overwhelming that Campbell’s rescored it for a 3 minute download. It really is beautiful in its simple elegance.

But the amazing thing to me was how well Campbell’s nailed their goal. When I played the piece for Stacy and asked her what she thought, she said, “The music reminds me of an elegant ball in the post war years of the 1940’s and 50’s,” then added, “in Italy.” Now, that is getting it right!

January, my 3 year anniversay with TDS.  We currently have 2 positions available to join our Austin team — a graphic artist and an applications programmer.  As a team, we have been doing a lot of brainstorming on our “ideal” candidates (too much during work time which I have been attempting to keep to a minimum, but our excitement for new talent gets the best of us).  Collectively, we have come to the conclusion that we are no longer interested in applicants with little experience (and a lot of heart), but which require training and time to get up to speed.  We desire talented, accomplished, and intelligent people to join our tight knit group — People that are able to start working with little to no training in their trade softwares or languages – mostly training in our business, our vision, and our core values. 

Individually, I have come to the conclusion that our newest team member must be confident.  I want to know that when our graphic artist or software programmer answers the phone, or contacts clients, that their knowledge is not only displayed through their outstanding portfolio, but in their communication skills and conversations that exude confidence. 

We have been going through the interview process for several days now and it is a relief to know that we actually have choices reagarding which qualified applicant we will decide to hire.  Not only for their breadth of knowledge in their field, their desire to learn, their interaction with us as a team, but also for the way that they carry themselves.   I don’t know yet who’s picture we will place next on the Team page, but I do know they will fit in with our mentality, style of professionalism, and willingness to share a few beers (or cokes) at the local pubs and breweries.  :)

In business, we rely on a host of employees, affiliates, partners, consultants, and occasional freelancers to serve our clients and meet our goals.  Yesterday, I learned in jaw-dropping fashion that a trusted part of that network has long been engaging in such deceptive practices that I am left reeling from the blow.

There are two parts to this story that have struck me with such forcefulness.  The first is the sheer cost of the deception.  I have been paying for services that simply weren’t performed.  To shore up the shortfall, I have thrown additional money into the mill.  We have suffered losses in both work performed and in dollars paid.  Secondly, I am immensely pained by the fact that the charade was conducted by a trusted source with whom I’d shared my hopes, concerns, and tears.  

If it were not for the magnitude of the dishonesty, if it were not for the person orchestrating the fraud…

So, now what?  I have to ask myself some hard questions, explore legal avenues, and make difficult decisions.  My mind just nags at the second half of the quote, “Burn me twice, shame on me.”

Earlier this week, I tossed, turned, worked, and worried before finally succumbing to sleep at 5:00 a.m. I had just received a phone call from a client who was terribly unhappy about our work. While I had heard rumblings about this client’s dissatisfaction, I hadn’t realized the scope of the problems. We had built a flawed, bugged system, which they’d abandoned out of sheer frustration.

The funny thing is, I had unknowingly asked our caller how the application was working, and was shocked to hear her simple yet surprising, calm acceptance, “We stopped using the software long ago; everything that could go wrong, did go wrong.” I hung up as embarrassed as I’ve ever been.

We’ve had great satisfaction with our reputation for attentiveness to client needs, so how on earth could we fail so miserably this client? Generally a hands-on manager, why had I not been involved in rooting out answers to their problems? How do we prevent a recurrence of this scenario, and more importantly, how do we go about winning back the confidence of this customer? 

Over the next day or so I was so taken aback by our collective failure. Sales for not indicating to me the depth of the problem. The programming team for simply giving up on fixing the bugs. Me for not having our staff understand that a client problem was our problem. 

Problems like this are small failures that will ripple into potential failure for us as a company. Over the past year we’ve been fortunate to land several large projects, but our busyness creates its own challenges. There are things that must be done in the housecleaning department that we simply don’t have time for. Ditto for new in-house products and projects. And obviously, we may be falling short in the attentiveness department. 

So, the morning after my sleepless night, I arrived early and invigorated for an impromptu meeting. I made an unpopular decision: forty hour work weeks were not an option until we had a laundry list of “to dos” completed. The first item on the agenda is addressing our client’s software. 

All companies make mistakes, and hopefully, most of them will learn from their errors. We are no different. I am no more afraid to openly admit those missteps than I am to share our successes. Because remember, those successes may have found their start in the fixing of an error.

Well, we wrapped up our first full week (and a day) of Phase Two (post M&M era) with Scott Duff in residence. 

Scott knows code, understands processes, server issues, and all the geeky stuff that makes him worth his salt.  While he’s got a lot of learning to do when it comes to the general practice of business, here at TDS, we’re excited to have him on board just in time for year-end wrap up and new year goal setting! 

And speaking of end-of-year trends, every December Manish takes off for India leaving me to get a chance to revisit my roots–programming roots, that is.  Now, I won’t pretend to be a programmer, but I do know enough about code to navigate around and get our clients through any down time without Manish.  In doing my usual December coding, I was thrilled to see the advances Manish has made in his skills over time.  He really nailed down the tenets of programming making it easier for Scott to pick up the mantle and head onward without Manish.  I’m so appreciative of that.

Manish’s and Manasi’s adherence to good code also allowed Scott to avoid getting bogged down in trying to understand or cleanup old code.  With his ability to pick up where M&M left off, we’re just itching for Scott to get us caught up, so we can relax, learn, and play.

And what about December play time?  The holiday season always means the phones stop ringing, and we get to explore the ideas and and build the programs we’ve held at bay all year.  We’re busier than ever and the phones won’t stop!

More on Phase Two of TDS’ goals in the near future.  I’m just dying to pool ideas and collectively set some pretty ambitious goals!