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. Continue reading
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. Continue reading
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. Continue reading
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. Continue reading
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.
I’m not sure what to title this post, so I gave it the title I did. I recently read the article Microsoft A Victim Of Its Own Success and spent the entire time nodding my head. I don’t know whether all of doom-like predictions by author Howard Anderson will actually come to pass, but they don’t sound too far fetched. We have seen many seemingly impervious-to-destruction companies suddenly find themselves in dire straits. Once in a while a company pulls itself out of the quicksand, but most of the time companies that go into these kinds of death spiral activities, quickly become irrelevant. Continue reading
The article is worth a read as it goes through some of the reasons why Chrome is becoming a real application platform rather than just a great, fast browser.
norske casino på nett
Something I have to get off my chest. This blog has been in existence for about a year and I have only a handful of posts on it. That’s okay, I can add to it as I want. I am doing this mainly for me and if you want to join in and share with me, great.
However, I have received probably 100 comments on various posts on this blog. And, as far as I know, every one of them was spam. Some poor person posting glowing comments that mean nothing and includes a link to their “I’ll help you be the number one result in Google” link. That’s why I set this blog up to not post comments until I have verified them. Continue reading
I ran across a couple of articles about an apparent lack of talent in the U.S. You can see a few similar articles at these locations and you can find a lot more on your own by searching in Google or any other search engine. There are a lot of people who are pushing this idea that the big problem with business is lack of talent.
While I won’t dispute the findings here directly, I do have a contrarian opinion (surprise, huh?) I will point out that most of these stories are put out there by consulting firms who promise to provide a product or service that will help you find, hire, develop, organize, etc. talent. It is to their advantage to convince you and me that talent is hard to come by and you need all the help your budget can afford to make sure you get the talent you need. Continue reading