SAS

I like to read ComputerWorld Canada, especially since I get it for free. Every few weeks or so they have an article where they mention SAS. They always seem to have something good to say about them.

Like this recent article about software quality where they use SAS as a positive example of a software company where quality is a priority. Go to ITWorldCanada, enter code 050562 in the quick link, regrettably there's a one-time free registration, then a couple more clicks to the article.

Based on the ComputerWorld Canada articles, it seems like SAS would be a great place to work as a developer: focus on quality led by the CEO, privately held so less of the quarterly shenanigans, hiring during a down period because there was good talent floating around after the dot com bust. They seem to show that you can do software "right" and still be successful.

If I was single and more free to relocate I think I'd want to apply to work there.

Oracle PL/SQL function to get current time in UTC

This snippet is an Oracle PL/SQL function that returns the current timestamp in the UTC time zone. It takes advantage of the EXTRACT Oracle built in returning its result in UTC.

FUNCTION getUTCDate RETURN DATE
AS
  utcYear NUMBER(4);
  utcMonth NUMBER(2);
  utcDay NUMBER(2);
  utcHour NUMBER(2);
  utcMinute NUMBER(2);
  utcSecond NUMBER(2);
  dateString VARCHAR2(30);
  ts TIMESTAMP WITH TIME ZONE;
BEGIN
  ts := SYSTIMESTAMP;
  utcYear := EXTRACT(YEAR FROM ts);
  utcMonth := EXTRACT(MONTH FROM ts);
  utcDay := EXTRACT(DAY FROM ts);
  utcHour := EXTRACT(HOUR FROM ts);
  utcMinute := EXTRACT(MINUTE FROM ts);
  utcSecond := TRUNC(EXTRACT(SECOND FROM ts));
  --
  dateString := TO_CHAR(utcYear) || ':' ||
                TO_CHAR(utcMonth) || ':' ||
                TO_CHAR(utcDay) || ':' ||
                TO_CHAR(utcHour) || ':' ||
                TO_CHAR(utcMinute) || ':' ||
                TO_CHAR(utcSecond);
  RETURN TO_DATE(dateString, 'yyyy:mm:dd:hh24:mi:ss');
END getUTCDate;


The source of your source code

In the recent death march project, I was responsible a large block of inherited code. I don't mean inherited in the object oriented sense. I mean that the code was written by a different office and transferred to our office for use in the project. The intention was that by reusing the original code we could save time against building the module ourselves and help to meet the project schedule.

We would be using the inherited code using a slightly different workflow than the original deployment. Also we were switching the environment from Windows server to Solaris. Since it's Java it didn't need to be modified for platform.

Unfortunately in testing there were a some problems in the inherited code. I had to pull some all-nighters to fix some issues. hint: with servlet you need to be really careful about thread safety. hint2: well placed source comments can greatly assist someone who is not the original developer who may be maintaining your code in the future.

So it goes. Hard experience gained. Going forward we now have a track record from that office and if a future situation like this arises then can know what to expect and can better plan for how to deal with it.

It may be that every line of code you write is a liability. However every line of code you inherit from outside sources is a risk. In general, deal with widely used sources that have a good reputation like Apache. Whether internal from your organization or external from the Internet, be careful of code from previously unused sources. Be aware of the risk that the code will not perform as expected. Integrate it early, to allow the most time for testing and to deal with problems which may occur.

Tech support dilemma

A former co-worker once described tech support from a large, well-known software vendor like this: "I found it was better to stand in front of a mirror and describe the problem to myself than to try to get help from XYZ support."

Why is tech support generally bad? The problem may be that once people get to a point where they can be effective at it, then they are at a point where they can be better used elsewhere. Suppose individual X does tech support for a large, complex software product; say a GIS system.

X is good at it, with deep understanding of the underlying specifications, full knowledge of the intricacies and glitches of the product in several functional areas, ability to quickly read customers (generally incorrect) source code and fix problems, communicates well with customers, etc.

What then becomes of X? Probably X will be transferred out of tech support into the consulting, testing or programming groups. In the consulting group the XYZ company can charge more for X's skills. In testing or programming X can bring a greater good than in tech support. In support you can basically help one person at a time and a fixed limited number overall. In the programming or test teams, you advance the product, which benefits everyone who uses the product. Thus more people benefit from X's efforts which should be more profitable to XYZ corp.

X's employer could decide to keep X in tech support because she is very good at it and her customers are happy. However this probably won't last because X can take her skills to a promotion out of tech support at a different company. So if XYZ doesn't promote X out of tech support then another company will.

So this may be why tech support is often bad. Once people get good at it they can be reassigned to more profitable areas. Also because of the cost and learning curve around big, complex software systems, it is better to keep around those tech support who aren't very good because turnover is expensive and the new replacements you bring in generally won't be better than those they are replacing.