They Want Your Life

by kwilson Posted on August 18, 2011

It’s important to look at the implications of the services and products we use every day in our lives.  It is easy to start using something, receive benefit from it, consider it a “good” thing, and then not give it a lot of thought after that.  We should keep thinking about our use of the product.  Is it still good for us? Have our needs changed, and should we discontinue use of the product? Maybe our use of the product has transformed, and now it can replace other products or services in our lives.

These are all questions that we need to take time to consider, if we want to have control of our own lives (by which I mean our time).

I started thinking about this again after reading an article in Fast Company magazine.  I find the magazine thought provoking and I spend  2-3 hours a month on the issues that I receive.  I think I benefit greatly from that time spent with the trend news and innovative ideas that I come across in the magazine.

Recently I was reading Discovery Engines: Policing the Riot of Information Overload. The question the article addresses is how do “we” filter through the social networking content to find the information that we want and find useful. If you have ever spent any time on YouTube, Twitter, Facebook, or any blog pages (I know you have or you wouldn’t be here!) you understand the problem. There is so much junk out there, it is hard to find useful content.

It reminds me of the old joke (turn away if you don’t like gross) about the little boy who accidently spit out his chewing gum while walking through a chicken pen. He started looking for it on the ground to continue chewing it. Unfortunately, he found it six times.

Anyway, this is all lead-up to the point I want to make. I understand the issue very well and think about the questions this article brings up often. However, there was one real gem of a comment made in the article that gave me pause.

Fans who use YouTube through its Leanback interface (designed for TVs and leveraging its what-to-watch-next algorithm) stick with the site for 30 minutes a day, compared with 15 minutes for the average viewer. Although that’s encouraging, it pales when compared with YouTube’s goal of several hours of daily viewing.

Did you catch that? YouTube’s goal is to get you to watch YouTube videos several hours every day. Well, actually, as usual, the statement is probably misleading toward YouTube. In a Telegraph article on Chad Hurley, one of YouTube’s co-founders, Mr. Hurley does compare YouTube to TV and suggest that most of the average 5 hours per day TV watching will be replaced with gathering content from the web.  Obviously, YouTube desires to be a big part of that to make lots of money selling advertising. (As an aside, I wish Farhad Manjoo, author of the Fast Company article, had provided a reference for this statement that purports to be fact. One of the problems with magazines is a willingness to make “factual” statements without providing a way for the reader to check up on it, but that’s another post for another day.)

This caused my mind to begin thinking about this whole issue of who controls my life. YouTube apparently wants most of my non-sleeping, non-working hours so that they can sell my time to advertisers. You can’t blame them, they have to make a profit, right? They can only make a profit on my time. But, they have to compete with the slots casino down the road from me, the Pittsburgh Steelers and Pirates, TV, and the local adult-beverage-purveying establishments for my limited time. (Not that I give any of my time to many of those listed time sinks.)

Somehow, in an effort to make a profit, it is okay for organizations to waste everyone’s time and encourage people to throw their time away on trivial pursuits (not to be confused with the game by the same name). What kind of a society do we have once a large percentage of citizens are averaging 4-5 hours a day watching YouTube videos? Will they spend the rest of their “free” time stuffing quarters in a machine and pulling the lever hoping to hit it rich so they don’t have to be productive any longer?

This comment raises some big questions in my mind. But it’s not YouTube’s fault – they need to make a profit.

You and I have to be careful to whom we give our life (time). I’m going to be thinking about this a lot more in the weeks to come.

Posted in Big Questions, General | Comments Off

Serendipity bug finds

by kwilson Posted on July 22, 2011

I’m surprised at how many times in my career I have experienced serendipitous bug finds.  It just happened yesterday to me and the team I work with.  What do I mean by that?

I was working on a bug that had been reported by a client.  Our application supports multiple languages, so reports can be generated in several different languages.  We got a report that a portion of the report was still showing up in English while the rest of the report was showing up in the preferred language.  Our support for languages is pretty sophisticated, the application allows users to create their own “custom languages” for languages that we do not yet support directly.  Adding that feature really complicated the localization code, so it didn’t surprise me that there was a bug in there somewhere.

I dug into the problem on my machine, was able to recreate the bug as reported and set about fixing it.  It was pretty straightforward, there was precisely a bug in that area, so I coded a fix for it, dutifully unit tested it and passed it along to QA to certify.  The bug came back and I was told that it still was happening.  ”Couldn’t be”, I thought to myself, “I tested it.”  I went into the QA environment, and lo and behold, the QA analyst is right, it doesn’t work.

At this point I tried a lot of things.  In some environments it worked, in some it didn’t.  I could switch from one database to another on my machine and in one it worked and in one it didn’t.  I began to investigate the differences in databases.  Eventually, I found that in one of the databases (the one that didn’t work, surprisingly) the translated content was missing.  Now, it became a whole different issue.  Why was the content missing?

We checked into the production database and the translated content was also missing.  Serendipitous bug.  Now, I didn’t know which bug had actually caused what the user was seeing.  Something (we pretty quickly tracked down what), was incorrectly deleting translations that we had loaded into the database.  It was a weird set of conditions that did it, but over time, it happened a couple of times.

It worked out well – if we had found the bad delete error first and fixed it, I probably never would have found the other error.  There were two intersecting bugs that yielded the same results.

As I said, you would be surprised how many times it works that way.

PS – I’m sure these were the last bugs in the application (yeah, right), and if you think that the application I’m talking about must be a disgrace because we found these bugs, you haven’t been paying attention to software.  I would say this app is about as “bug-free” as almost any application you could name.  I’m sure there are better, but I’m also sure there are much worse.

Posted in Problem Solving | Comments Off

Ask the customer what they are seeing

by kwilson Posted on July 18, 2011

It is well understood by software developers and customer support staff that you really need to get the details about a reported problem to be able to find the problem and correct it.  We ask all sorts of strange questions that I’m sure the client does not expect.  After all, you built the product, why don’t you just “fix it?”  Why ask so many basic questions?

The reason is that you really need to understand exactly what the client is seeing.  What did they do that led to the problem? What are the exact sequence of events? What is the exact message? How often does the problem occur? Have you figured out a way around the problem?

I recently had an experience that drove this home to me.  The incident is totally unrelated to software, but I think you’ll see the connection.  You would think I would know better, but let me tell you what happened.

My daughter took a friend for a photo shoot, she has been doing senior pictures for some of her friends, and doing it quite well I might add.  This particular boy wanted some pictures taken at the soccer field since he plays soccer, so they went to a soccer field not far from our house.  During the course of the photo shoot he did what soccer players do and gave the soccer ball that he was using for a prop a good kick toward a practice backstop.  The ball sailed over the backstop into a hillside that is covered in some of the densest jungle that I have ever encountered (as will become clear soon).  Photo shoot over!

They weren’t dressed for a jungle expedition and they looked for the ball for a few minutes, but soon gave up to try again another day.  They came home and I heard the story from my daughters.

Being the man of the house and not wanting to have a soccer ball lost forever, even if it wasn’t mine, I offered to go find it.  I had jeans on and it seemed like it wouldn’t be that big of a deal.  They told me approximately where the ball should be and off I went to do the heroic deed of returning the lost soccer ball.

Well, I was in for a surprise.  As I said, the place where the ball left the playing field was very thick jungle, low growing brush with branches all intertwined.  Tall trees that blocked out the sun.  Vines growing up trees and everywhere else.  I looked for poison ivy and didn’t see anything that looked like that to me, so I dove into the situation.  I was looking for a soccer ball, not a golf ball, so how hard could this be?  Well, pretty hard it turns out.

I searched for 45 minutes (I did find 3 golf balls by the way) and never found the ball.  I struggled through the brush, eventually breaking off a branch to use as a tool to knock back the vines.  I crawled, I climbed, I eventually walked around the hillside and came in from the top.  I tried to the left, I tried to the right.  I looked in the tops of bushes, I looked under the brush.  I tried to consider where the ball might have bounced (how it could have bounced I don’t know).

I realized there were a lot of questions I didn’t have the answers to.  How hard had he kicked the ball?  How high was it when it went over the backstop?  Did it make any sounds when it hit?  Did they hear it bouncing around after it entered the jungle?  Where had they looked?  I was by myself so I didn’t have any way to answer those questions.

Well, I returned home unsuccessful, but undefeated.  Two days later I told my daughter she was coming with me, we were going to get the ball.  I got a couple of metal rods to use as tools, I took pruning shears and a hatchet to cut through the jungle.  I also got a flashlight or two so that I could see better in the dark underbrush.  I put on a long sleeve shirt so that I didn’t have to worry about being scratched by the branches and some thorns.  I put on hiking boots so that I would have less chance of being injured moving around there.

We arrived at the field and I asked my daughter where the ball had gone over.  Right here – where I had understood from our conversation before.  How high was it?  Not very it turns out (I had thought the ball was deeper in the jungle – interesting).  Had they heard a sound?  Yes, not much, but it seemed close to the edge of the jungle?  (Hadn’t expected that.)  Where had they looked?  Well, right in this area because they thought it hit in this tree.

So, before I got the tools out and started destroying jungle (I didn’t really want the environmentalists after me anyway) I stepped under the tree and began to look around.  There was a good chance the ball had gotten stuck in the branches of the tree or the bushes that were under the tree.

Sure enough, there it was, lodged in a tree branch almost within reach without even entering the jungle.  It was hard to spot, but it was right there.  I switched sides and reached in and pulled it out.  Within 5 minutes we were headed for home – victors.

If only I had gotten that information originally, I could have saved 45 minutes of some of the worst searching conditions I have endured for a while.

I was once again reminded that it pays to get the details before you dig into a problem.  That is the way software support is as well.  We need to ask those questions of the the person reporting the problem.  As engineers, we are all too often ready to jump in and start searching for the answer, when the answer really comes from having all of the information and taking a few minutes to think about what the probably cause is.

I have seen that happen many times.  You spend a lot of time looking through code, trying to find where the bug is and you can’t.  Then you stop and discuss it with others and you talk about all that you know about the issue.  You talk about exactly how the product works without looking at the code.  Where could the problem be?  Someone will say, “Oh, it has to be in this module because after the user does such and such, it will be processed in this way and then we will write an update to the database.  That must be the problem.”

Sure enough, 15 minutes later you are looking at the line of code that is incorrect.  It saves a lot of time.  The same advice as last time – “think first.”  If you know where to look and what you are looking for, it is often pretty easy to find what you are trying to find.  Make sure that you ask the customer exactly what they experienced.  Get the facts first, then start searching.

Posted in Life Lessons, Problem Solving | Comments Off

Think first

by kwilson Posted on July 10, 2011

The tagline for this blog is carefully considered.  Think – Design – Build.  Three steps, in a precise order, the way software development should be.  I have been working in an agile environment for about three years now, I like the concept.  As mentioned earlier on this blog, I have been a proponent of agile concepts since 1999 or 2000 when I read a copy of Kent Beck’s Extreme Programming Explained.

I’m still uneasy with the way I understand agile and the way I have seen it implemented.  You can’t build great, long-lasting, well-designed software by starting with the most important feature first, and just doing what is necessary to make it work.  That is much of agile, summed up in a single sentence.  Building on that, you can really build a lot of software and you can make a lot of progress.  But, it comes at a price.

Without planning ahead and thinking about the entire picture of what you are trying to build, you are very likely to end up with what us old-timers call “spaghetti code.”  Then, we are told, you just refactor it (see Martin Fowler’s Refactoring: Improving the Design of Existing Code).  Now, I think the concept of refactoring is a great idea, and whatever we can learn about how to do that well will serve us in our endeavors.  However, by definition, we are admitting that we didn’t do it right the first time.  As they say, “You don’t have time to do it right, but you have time to do it over.”

I haven’t completely made up my mind about this paradox, but I will share one of the best lessons I learned when I first began developing on a product that was intended to be sold to dozens, hopefully hundreds of clients.  I was new in the field of 3rd party vendor software in the IBM mainframe world.  I had developed code for 5-6 years, but this was my first experience in developing code for programs that would be sold and shipped to dozens of clients who would all get on the phone and call the minute they started using it if it didn’t work.  This stuff had to work.

I took my job very seriously, so when I was given a task, I got started right away.  Can’t waste any time, have to start writing code and figure this out.  And so, I spent a couple of hours planning my approach and starting shoveling in the BAL instructions.  I was pretty good at it too.  Along about lunch time I went to see my team leader, Jim, who was also a developer.  The organization we worked for believed that team leaders should develop code – kept them sharp, they understood what they were “leading.”  He had a part of the project that my module was to fit into.  I wondered how far along he was.

When I got to his cube to check, I realized he hadn’t started yet.  He wasn’t even behind his 3270 terminal.  He was sitting by the window at a little table, looking out the window.  I knew he was good – maybe he was done.

“Have you started coding yet?”, I asked him.

“No, ” he replied, “I’m thinking.

Thinking!  That is all he did for three days.  Everytime I stopped by he cube it was quiet.  No keystrokes, no mad debugging sessions, no cups of half-drank coffee lying around.  Just peace and quiet.

“When are you going to start coding?”, I asked him.   “I’m almost done with my module and I’ll be needing your piece soon.”

“You can finish when you like,” he told me.  ”I’m not starting it till I know how it will end.  I have to figure it out.  By the way, how are you going to handle the carriage control?”

“Well, I haven’t figured that out yet, ” I admitted.  ”I don’t think it will be that hard.  I left it till the end, I’ll figure out exactly how it fits in when I get there.  It is just a minor part of the whole thing.”

To his credit, he didn’t laugh at me or fire me.  He just kind of smiled and went back to thinking.

A couple of days later while I was “refactoring” to try to get carriage control to fit into my module, I went to his cube because I heard wonderful noise.  He was typing.  I stepped into his cube, but he barely looked up while he waved me away.  ”Don’t bother me right now, I’m almost done.”

I walked away, but I smiled as I did.  ”Almost done?”  There was no way, his part was more difficult than mine and I knew he hadn’t even started till this morning.

When he came to my cube late in the afternoon, he was tired, but looked happy.  He was ready to test it.  He needed my module.  Unfortunately, my module was in pieces all over the DASD.  It wasn’t ready to be integration tested, it couldn’t even be unit tested.

We began to talk, and as we talked I realized that most of what I had written wasn’t going to work.  I had missed a couple of important design requirements.  He showed me his code – beautiful, well-structured, easy-to-read, well-commented BAL code.  I tried to keep my code away from him, didn’t want him to see it, but eventually he needed to look at it so that he could help me figure out what was wrong.

We did make it work.  It was pretty clever, as most of the stuff we wrote together was.  That code probably died a natural death 10 years ago or more, but I learned an important lesson, “Think first.”  It makes the rest of the project easier.

That concerns me about agile.  The code is the thing!  I like that.  But I think it misses the point.  The code is the result of a good developer understanding what the problem is and thinking about a way to solve the problem.  The code is really the AFTER THOUGHT.

Think first – code after you know what you are going to do.  You might just end up with something that doesn’t need “refactored.”

Posted in Process | Comments Off

Welcome to wiserve.com

by admin Posted on July 4, 2011

I haven’t had a blog in quite some time, although I started blogging back in the old days.  I wrote an application named htmlPX in Java around 1999.  I wrote it to learn the Java programming language, but also to make it easier to build HTML pages.  It was a pre-processor that allowed me to build functions in HTML and then generate a website by building simple pages that used the functions to generate the appropriate HTML code.  I still find it a very useful application.

After releasing that application, I began to build web site and try to find my way in the web world.  I suppose if I had stuck with it, I might be a well-known web personality by now, a lot of other folks made quite a name for themselves without having too much extra-ordinary skill or knowledge.  I built a few blogs and tried my hand at a little e-commerce through affiliation sites.  I didn’t find that too profitable or too interesting, so I moved on to other things.

A few years ago I moved out of the programming end of software development and into management.  It is a move that everyone who has been in the field for a while contemplates.  I did that for a couple of years, but really missed the programming end of things and when a reorg came along in the company I worked for, I was able to move back into the programming end of things.  Here I am now with a lot of new stuff to learn, and yet a lot of hard-earned and well-crafted experience.

I plan to use this blog to share some of the lessons learned as well as chronicle my efforts to continue expanding my programming and software development skills.  I have interests in all of the aspects of software development including methodologies (I was an early proponent of agile in my organization in very late 1990′s), programming languages, software design, coding techniques, and development tools in general.

I hope you benefit from the journey as much as I plan to.

Posted in General | Comments Off