I just got my ComputerWorld Canada last week. It seems like it's been a while since the previous one. I noticed they have gotten thinner the last few months.
I think January 2008 is the slimmest I've seen. It was only 18 pages. While the content is still good, the seeming gaps between issues and the slimming is a concern. I wonder if they will cease publication soon.
It would be too bad if that happens. I've been reading ComputerWorld Canada and its merged predecessors like InfoWorld Canada as long as I've been in tech full time. They are useful to get an idea what's going on at a high level outside of your own company and projects. Although ComputerWorld Canada has always been more focused on the corporate IT departments than on my roles in systems integration and development in an ISV.
I was getting electronic delivery for a while. Around the middle of last year I switched back to delivery of the printed issues and I've been reading them when they arrive.
The tech magazines have had it tough in recent years probably due to the rise of the Internet. It would be unfortunate if ComputerWorld Canada goes away but I guess I could find a site or feed with similar content easily enough on the Web.
Wednesday, February 20, 2008
Thursday, February 07, 2008
The cost of bugs in the field
It's definitely true that the cost of dealing with software bugs that make it into the field is orders of magnitude larger than finding and fixing them pre production.
After our recent reorg I'm now responsible for maintenance on earlier releases of the flagship product out of our office. On Monday I got a trouble ticket about a customer who was experiencing problems after upgrading between minor releases. They wisely trial the upgrades in their lab before going live.
The customer helpfully provided a detailed description of the symptoms, the log file excerpts, as well as a packet capture. It turns out the packet capture was particularly helpful. In the wire trace I could see we were unexpectedly doing an HTTP 500 response in a certain common valid configuration. Embedded in the HTTP 500 response was a stack trace generated by Tomcat. The stack trace pointed directly to the issue. It was a bug in our code introduced by the previous maintenance developer in the minor release.
Looking at the code diff from revision history against the stack trace, it was obvious what the error was. The code fix was just a couple of lines, add a null check the original developer missed and it would be good again. However getting that change "done" on a system installed on a customer site is a tremendous amount of effort.
First I had to set up my development environment for the earlier code base including Eclipse, the application server, database, Perforce, Tomcat and all of that. Task switching between releases is tedious and that burned pretty much a day. There was an extra requirement to reproduce the issue where there had to be more than one Tomcat instance so I couldn't just run everything off my own PC. It took a while to get a separate Tomcat up with the correct Tomcat version and maintenance version of the application source code. Altogether it took more than a day just to get set up and reproduce the issue.
After reproducing the issue the actual code change only took a few minutes to implement. Then I had to install the fixed code and verify it was now working properly.
All done right? With shipped code, far from it. Then I had to package up a new release using the official procedures. Then assemble a patch to upload to the customer along with patch install instructions I had to write. The code fix also has to be merged to other later releases that will need it. The Wiki sites tracking this all had to be updated.
In addition to my own time spent which was several days for about a 3 line code change, there was the support rep in my company who had to manage the ticket and communicate with the customer, as well he had to update his own running site for that release. Additionally the customer lost a lot of time diagnosing this issue and now they have to lose more time doing the upgrade.
All in all more than one person week has been consumed by a code error that was 5 minutes work to correct. That's what happens when code bugs go into the wild.
Compare this to the cost of finding and fixing it earlier. If it had been detected by the original developer or a peer during code review it would have been about 5 minutes to fix.
If the developer had found it in his testing it would have cost around an hour to do the fix, rebuild, redeploy and rerun the test.
If the test team had found it it would have been about half a day to do the fix, do another baseline build, update the ticket tracking system and the testers rerun their test, and close the ticket.
So at every stage it gets progressively more expensive to fix serious bugs. That's why it's so important to find the bugs before they get into production.
After our recent reorg I'm now responsible for maintenance on earlier releases of the flagship product out of our office. On Monday I got a trouble ticket about a customer who was experiencing problems after upgrading between minor releases. They wisely trial the upgrades in their lab before going live.
The customer helpfully provided a detailed description of the symptoms, the log file excerpts, as well as a packet capture. It turns out the packet capture was particularly helpful. In the wire trace I could see we were unexpectedly doing an HTTP 500 response in a certain common valid configuration. Embedded in the HTTP 500 response was a stack trace generated by Tomcat. The stack trace pointed directly to the issue. It was a bug in our code introduced by the previous maintenance developer in the minor release.
Looking at the code diff from revision history against the stack trace, it was obvious what the error was. The code fix was just a couple of lines, add a null check the original developer missed and it would be good again. However getting that change "done" on a system installed on a customer site is a tremendous amount of effort.
First I had to set up my development environment for the earlier code base including Eclipse, the application server, database, Perforce, Tomcat and all of that. Task switching between releases is tedious and that burned pretty much a day. There was an extra requirement to reproduce the issue where there had to be more than one Tomcat instance so I couldn't just run everything off my own PC. It took a while to get a separate Tomcat up with the correct Tomcat version and maintenance version of the application source code. Altogether it took more than a day just to get set up and reproduce the issue.
After reproducing the issue the actual code change only took a few minutes to implement. Then I had to install the fixed code and verify it was now working properly.
All done right? With shipped code, far from it. Then I had to package up a new release using the official procedures. Then assemble a patch to upload to the customer along with patch install instructions I had to write. The code fix also has to be merged to other later releases that will need it. The Wiki sites tracking this all had to be updated.
In addition to my own time spent which was several days for about a 3 line code change, there was the support rep in my company who had to manage the ticket and communicate with the customer, as well he had to update his own running site for that release. Additionally the customer lost a lot of time diagnosing this issue and now they have to lose more time doing the upgrade.
All in all more than one person week has been consumed by a code error that was 5 minutes work to correct. That's what happens when code bugs go into the wild.
Compare this to the cost of finding and fixing it earlier. If it had been detected by the original developer or a peer during code review it would have been about 5 minutes to fix.
If the developer had found it in his testing it would have cost around an hour to do the fix, rebuild, redeploy and rerun the test.
If the test team had found it it would have been about half a day to do the fix, do another baseline build, update the ticket tracking system and the testers rerun their test, and close the ticket.
So at every stage it gets progressively more expensive to fix serious bugs. That's why it's so important to find the bugs before they get into production.
Sunday, January 27, 2008
Sun T series servers
We've been measuring how our server software performs on Sun T series servers against the older V series.
The results with the T series have been very encouraging. For comparable servers the T series performance is around double the throughput of the V series. We're very pleased with this. This is good news because comparable T series cost less than V series and power consumption is lower. With Sun SPARC binary compatibility all the applications still run the same.
I'm very impressed with the T series. One component of our application runs on Tomcat. I wasn't sure how a busy Tomcat would run on a T1000 with a load test. It ran really well. I guess the JVM threading implementation does a good job of utilizing the T series multicore architecture.
The Sun T series is a very interesting architecture. Just one physical CPU with a clock speed in the modest range of 1-1.2 Ghz. The multicore architecture with many CPUs and independent execution threads on the single chip is remarkable.
You can now try out some advanced Sun technology like the T series servers for a free trial using Sun try and buy program.
I've worked with Sun hardware and over the last decade and I've always been a fan. I hope Sun and Solaris can continue to innovate prosper and stay around.
The results with the T series have been very encouraging. For comparable servers the T series performance is around double the throughput of the V series. We're very pleased with this. This is good news because comparable T series cost less than V series and power consumption is lower. With Sun SPARC binary compatibility all the applications still run the same.
I'm very impressed with the T series. One component of our application runs on Tomcat. I wasn't sure how a busy Tomcat would run on a T1000 with a load test. It ran really well. I guess the JVM threading implementation does a good job of utilizing the T series multicore architecture.
The Sun T series is a very interesting architecture. Just one physical CPU with a clock speed in the modest range of 1-1.2 Ghz. The multicore architecture with many CPUs and independent execution threads on the single chip is remarkable.
You can now try out some advanced Sun technology like the T series servers for a free trial using Sun try and buy program.
I've worked with Sun hardware and over the last decade and I've always been a fan. I hope Sun and Solaris can continue to innovate prosper and stay around.
Friday, January 11, 2008
Private domain name registration
I bought a domain name from Yahoo domains recently. It was for a site I was helping my son set up. It's a basic setup. It just uses Blogger to post content. It's working out OK so far.
I didn't realize that you can just buy a domain name from within Blogger now so knowing that I might have done things differently. Still Yahoo domains has a good user interface and it was interesting and not difficult to get it all set up.
One thing that was interesting about domains that I noticed from Yahoo and other providers I checked out like GoDaddy is this private registration option. When you register a domain you have to provide whois information about the domain owner. The whois information includes address, phone number, and e-mail. Registrars like Yahoo warn you that this is public information and spammers and other undesirables will be able to find you when it is posted.
The registrars have a service called private domain information. In this case they offer to substitute their own information in the whois so that you do not have to provide your own personal data. This is an extra cost service. For Yahoo private registration costs almost as much as the domain name itself so it's not really cheap.
I decided not to purchase private registration. First of all I realized that my personal information is public anyway. My phone number is listed and I can be looked up in canada411.ca and elsewhere easily enough. So there's nothing in the whois which isn't already knowable.
The other reason I didn't purchase it is because it is unnecessary. With Yahoo the whois stuff is just a form you fill in. It seems you can enter whatever you want into this form and just manually obscure your identity that way. There doesn't seem to be anything preventing this.
So my tip is to save your money on domain registration and pass on the private registration option since you can just directly type in whatever you want anyway for the whois so you don't need to purchase separate private registration.
I didn't realize that you can just buy a domain name from within Blogger now so knowing that I might have done things differently. Still Yahoo domains has a good user interface and it was interesting and not difficult to get it all set up.
One thing that was interesting about domains that I noticed from Yahoo and other providers I checked out like GoDaddy is this private registration option. When you register a domain you have to provide whois information about the domain owner. The whois information includes address, phone number, and e-mail. Registrars like Yahoo warn you that this is public information and spammers and other undesirables will be able to find you when it is posted.
The registrars have a service called private domain information. In this case they offer to substitute their own information in the whois so that you do not have to provide your own personal data. This is an extra cost service. For Yahoo private registration costs almost as much as the domain name itself so it's not really cheap.
I decided not to purchase private registration. First of all I realized that my personal information is public anyway. My phone number is listed and I can be looked up in canada411.ca and elsewhere easily enough. So there's nothing in the whois which isn't already knowable.
The other reason I didn't purchase it is because it is unnecessary. With Yahoo the whois stuff is just a form you fill in. It seems you can enter whatever you want into this form and just manually obscure your identity that way. There doesn't seem to be anything preventing this.
So my tip is to save your money on domain registration and pass on the private registration option since you can just directly type in whatever you want anyway for the whois so you don't need to purchase separate private registration.
Wednesday, December 19, 2007
Happy 25th Commodore 64
Here's a couple of links around the 25th anniversary of the Commodore 64 [1], [2].
I started out programming on the Commodore in junior high school in the early 80s. Those were the best times to be into computers and programming. The Commodore 64 was a great machine with sprite graphics, sound, and 38911 Basic Bytes free.
I had the Commodore dot matrix printer and easy script word processor that my sister used in university. At that time she was about the only one printing her essays. In word processing things like cut and paste were sensational advanced features.
I had a 150 baud modem which cost over $100. The 2400 baud Hayes modem sold for over $1000 at the time.
Commodore brilliantly made their joystick port compatible with the Atari 2600 so it was easy to get controllers from the Atari and use them for gaming. And we spent many hours playing games on the Commodore64. Some of the best were Mule, Archon, Summer Games, 7 Cities of Gold, and on field football.
I started out programming on the Commodore in junior high school in the early 80s. Those were the best times to be into computers and programming. The Commodore 64 was a great machine with sprite graphics, sound, and 38911 Basic Bytes free.
I had the Commodore dot matrix printer and easy script word processor that my sister used in university. At that time she was about the only one printing her essays. In word processing things like cut and paste were sensational advanced features.
I had a 150 baud modem which cost over $100. The 2400 baud Hayes modem sold for over $1000 at the time.
Commodore brilliantly made their joystick port compatible with the Atari 2600 so it was easy to get controllers from the Atari and use them for gaming. And we spent many hours playing games on the Commodore64. Some of the best were Mule, Archon, Summer Games, 7 Cities of Gold, and on field football.
Monday, December 03, 2007
A choice in the matter
We recently missed our quarterly targets and had to preannounce. As often happens after a miss there was a round of downsizing. I'm fortunate and happy that I got through it OK.
This round was different than other RIFs with this company and other companies I've worked for. The timing was such that the downsizing was done in the late stages of a big development project. As a result the affected individuals will be staying on for a while longer until the big project finishes. Historically during a downsizing people would kind of just disappear like Syme in 1984.
Another thing that was different was that in the reorganization some individuals were offered new roles in the company. However they had the choice to decline the new position and be laid off instead with the same severance and access to unemployment insurance as those who didn't have a choice.
Almost all of the people who had a choice chose to stay on. However two individuals chose to take the severance and leave. Those who chose to leave have some similarities. One guy said that if they tighten up their expenses a little bit then he will be cash flow neutral on his wife's salary. The other guy is married with no children and his wife has a good job.
The people who seem to have a bit of a financial backstop to afford being out of work for potentially a while have chosen to take the severance. I don't believe they have new jobs lined up, they are just going to take their time and explore new career opportunities.
If you can afford it then it makes sense to take the severance if you are at all on the fence about staying. It would suck to decline severance today and then leave voluntarily in say six months and get nothing. Also all things being equal they should be confident they will find a comparable job at comparable pay in a reasonable time. The local tech economy is pretty robust right now. With a financial backstop they can afford to "gamble" that they can find something else quickly and pocket the difference in severance.
This round was different than other RIFs with this company and other companies I've worked for. The timing was such that the downsizing was done in the late stages of a big development project. As a result the affected individuals will be staying on for a while longer until the big project finishes. Historically during a downsizing people would kind of just disappear like Syme in 1984.
Another thing that was different was that in the reorganization some individuals were offered new roles in the company. However they had the choice to decline the new position and be laid off instead with the same severance and access to unemployment insurance as those who didn't have a choice.
Almost all of the people who had a choice chose to stay on. However two individuals chose to take the severance and leave. Those who chose to leave have some similarities. One guy said that if they tighten up their expenses a little bit then he will be cash flow neutral on his wife's salary. The other guy is married with no children and his wife has a good job.
The people who seem to have a bit of a financial backstop to afford being out of work for potentially a while have chosen to take the severance. I don't believe they have new jobs lined up, they are just going to take their time and explore new career opportunities.
If you can afford it then it makes sense to take the severance if you are at all on the fence about staying. It would suck to decline severance today and then leave voluntarily in say six months and get nothing. Also all things being equal they should be confident they will find a comparable job at comparable pay in a reasonable time. The local tech economy is pretty robust right now. With a financial backstop they can afford to "gamble" that they can find something else quickly and pocket the difference in severance.
Subscribe to:
Posts (Atom)