June, 2008

On the way to Green IT

Green IT — you’ve read and heard a lot about it recently.  Green (whatever) is the color of the day, week - indeed future.

However, I can’t help but think about all the trees we were going to save by having our computers do all the work for us, and then present results without paper!  Remember the paperless office?  Talk about the paperless society?  …and wouldn’t paperless be a good green initiative?  The paperless office sounded like a good idea at the time, but I venture to say that for most companies efforts to be paperless have gone stagnant - and why is that?

Could it be that perhaps it just doesn’t work?  Could it be that people still want to read or skim over printed pages rather than fuss with a mouse, or read something on a screen limited in its display, and positioned (normally) very differently than say when one reads a book or newspaper?  Have you ever seen someone curled up comfortably in their easy chair reading a computer?  I for one have not!

While I believe we have made great strides in some areas toward minimizing paper use with programs such as on-line libraries of scanned business documents, B2B invoicing, data warehousing and “Business Intelligence - given the increase in data now available because of our faster, more powerful computers I submit that perhaps at best we’re holding our own.  The additional computing power and data analysis has meant mroe computers, which of course means more energy — so we now add in virtualization of said servers - and the cycle starts again.  First we had a prolific growth in physical servers, now it’s virtualized servers - and software wanting to run on its own server spurs more growth. 

Of course there’s also the other green - the long green (aka US $).  We want to do all this “greening” without spending the long green.  Most “green” initiatives don’t save money in the short term, and in the economy of today investment in the long term is limited due to short funds.

Finally there’s the last “green” I’ll refer to — that of the “green” with envy kind of green, also known in a previous era as “keeping up with the Jones’s”.  The Jones’s have something that you perceive as good - so you want it!  So what if it uses up more resources.  While there is a lot at stake for us as a global society by “going green”, I’m seeing much talk, but little action.  Shifting from one resource drain (such as power consumption) to another (such as serving up twice as much paper in printed documents) hardly seems green to me.

Work-Life Balance - No Measure of Cost

An article which recently caught my eye entitled “5 signs your people don’t have work-life balance” triggered my interest once again in blogging about this topic.  (See my earlier post). 

One doesn’t have to look far to find someone in their life whose work-life balance is, putting it nicely, far out of proportion - usually with the “life” area suffering from lack of attention.  I must admit that I have struggled with this all of my life.  My natural tendency has always been to put work at the top of my “todo” list (…that is IF I even bothered to make a list!).  In my earlier years there was no question about where my priority was - work, work, work - and coming in a distant forth and beyond everything else.

Fortunately now, for those around me, I have a far better balance between my work and “the rest of my life”.  The resulting change in my well-being has been significant - but there were many lessons I needed to learn before reaching some semblence of balance.  (Like the trauma of a failed business and a stressed marriage to start with).   

There is a high cost associated with Work-Life Imbalance - both to employee AND employer.  For an individual such as an independent software developer - it can be huge!  I have never seen any indications that burn-out, health issues or relational problems has ever helped boost productivity!  Regardless of ones occupational position, the maintenance of work-life balance is critical for employers to recognize and encourage.

It’s NOT easy to achieve however!

Useful Tools of the Trade

A few days ago I blogged about how I was playing detective with a clients computer system, struggling with performance issues.  It has been an interesting few days since that blog, and I have discovered much, and learned along the way.

One thing that I learned about is a nifty utility offered by Microsoft which can aid in the analysis of exactly what’s going on with your Windows 2003 Server.  The utility is called Server Performance Advisor.  The utility is particularly helpful for presentation of data which is collected by the multitude of logs kept as part of normal server operations.  It also provides additional information and combines it in a much more understandable manner than just reviewing raw log data.

Starting with a system overview, it can also provide information about other common services provided by the server, like IIS, DNS, Active Directory and others.  It includes useful help!  Depending upon the selection of services the utlility collects data for either 100 or 300 seconds, and then creates analysis of the data. 

If you have a Windows Server 2003 and are not familiar with this tool I’d recommend it highly.  Follow the link to Server Performance Advisor for more information.

My search for answers this week also took me to an article on Computerworld outlining 10 Great Free Network Tools.  Since the analysis of my performance issue indicated that the issue was not network related I did not follow-up with any of these network tools, but I pass the link on for what its worth.  Hopefully it can help someone out.

Developer, Business Consultant or Detective?

I wrote a couple of days ago about how I thought that we independent developers had to be partially detective, and indeed not just developers, but pretty much in any IT position that we may hold.  My last post really was somewhat of an example where the developer was acting more like a business consultant than developer.  He had identified a process issue, and the prospect wasn’t open to the “business consultant” service he was getting from the developer.  (From the owners view, there was nothing wrong with his business (process), it was a computer application problem!).

Another example of a developer becoming business consultant came to my attention yesterday.  It seems that the developer was asked to come out and evaluate the clients application to ensure that it was doing what it was supposed to, and also to ensure that there were no “workarounds” that could be used by dishonest employees to “skim” inventory.  It seems that there had been major issues with generic inventory shortages, and the company management suspected possible theft.

The developer went on-site and performed an exhaustive evaluation of the application and the processes in place and had found nothing out of the ordinary or unexpected.  The developer was wearing his “detective” hat at that point. 

Now, while waiting for management to become available to report his findings, the developer (detective) became aware of something — the phone had rung, and the counter person took an order, pulled a few items from inventory.  He then excused himself to the developer saying he had to bring these items out to the shop.  The developer noticed that he had done nothing with the inventory system, and upon the employees return began to question him about what he had just witnessed.

The company stocked a series of tools which were of standard sizes, but that could then be slightly modified by a secondary process to in effect provide a “custom” item.  Upon further conversation with the employee it was established that it was a common practice to take items out to the shop to be “customized”, and they were then sold as a “special order” item.  “Special Order” items were not inventoried. 

At this point the “detective” became the ”business consultant”.  Records of the “special order” sales indicated that the suspected “losses” of inventory were in fact due to the movement (without any record keeping) of the items to be turned into the non-inventory special order items.  Records showed that the missing inventory was completely accounted for after reviewing the special order sales - there was no theft issue.  Rather it was a business process issue.

That this situation was noticed was truly due to the skill of the developer as detective and business consultant.  It should also be noted that Lady Luck played her part in that since management wasn’t available for the developers “final report” he witnessed what he did that ended up identifying the issue at hand.  It all worked out!

Just another day as an independent application developer!

A Business Process NOT to be Duplicated

When an independent application software developer first meets with a prospective new client it becomes very much a meeting where each party is evaluating the other.  For the developer it becomes questions of “Is this an organization I can work with?  Can I provide what they are looking for?  Can they pay me?  Do I want to do the proposed work for this organization?”.  For the prospective client the questions become “Can I get what I want from this developer?  Is the talent there to provide the service?  Can I afford the service?  Can I work with this developer?  Do I want to work with this developer?”  All good questions - left generally unspoken.

In speaking with a fellow developer today I was reminded of this by a story he told of one such interview where he decided that he was NOT interested in doing work for the prospective organization — and the reason?  Basically it came down to the prospect being firmly entrenched in a business practice that was just plain poor.  The application in question was an inventory application - the problem to be solved was to have a system that kept inventory straight.  The “real” issue, quickly identified for the prospect was their practice of transferring inventory from store to store.  They used hand-written packing lists for the transfers.

There were 2 locations, each keeping their own separate inventory system.  Each properly received inventory, and inventory was in fact properly relieved by the sales function.  The system wasn’t used at all for the transfer of goods from one location to another — no surprise that inventory was off!  Since the system for each store was independent of the other, neither system “knew” of the movement of goods to the other location.  So, you had a system where goods were received properly, but not properly relieved at the location shipping the goods!

My developer friend thought it best to stay away from this potentially difficult situation, and suggested that the prospect find a developer who was willing to do the work as desired.  The moral of this story?  Not all business processes deserve to be duplicated.  In this case, the issue was not the computer application that was the problem, but rather how it was being used. 

The story also illustrates very well one of the situations that I always try to become aware of at a clients site when I’m there - “What are they doing manually that could easily be in an application?  Why isn’t it?”  The manual packing list is in my book a BIG red flag!  It signals stop, look, and be cautious. 

P.S.  My friend later found out that this company’s “new” inventory system didn’t work any better - at least until the business process was changed.

Application Performance and Other Investigative Opportunities

Sometimes I feel more like I’m a detective than programmer/analyst.  Fact is, I believe, that there has to be at least a little bit of detective in every IT person who has the opportunity to evaluate software applications and their sometimes strange behaviors.

As an example of what I mean, I share with you an opportunity I’ve been presented that has surely become a mystery worthy of any good detective - or perhaps a sick mind :-).  Picture this, an application that runs flawlessly and with acceptable speed on a minimally configured server when moved to a new “high-end” server slows down to borderline acceptable performance - clearly and noticeably slower than the old one.  Both systems use RAID 5, both are running MS Server 2003 SBS.  Main difference between new and old is that new uses more powerful chips, faster drives, 4 times the RAM and gigabit network connectivity - none of which cause me to suspect that it should run slower than the old.

The issue was called to my attention after the company “network” guys had all but thrown up their hands and said basically “…it must be the application…”.  It seems very hard to believe that it would be anything other than configuration of “something” on the new server.

As yet the issue remains unsolved - but I use it to highlight one of the great challenges that we in the IT field are presented with .  One need not look beyond the next IT person you talk with to find the next “detective” story or unsolved mystery.  We are faced with them constantly.  We need software and hardware tools, knowledge bases and lots of experience to investigate and solve such issues.  Issues which cross various specialties such as security, networking, programming, application testing and design require us to be “detective” - to ask the right persons the right questions - to find the right tool to identify the cause of the problem, as well as to recognize opportunities to “check into”.

“Lots of luck” also helps!

The Technology Career - Demands and Observations

I read with dismay and a good deal of reflection a recent article entitled “Why women quit Technology Careers” and comments posted to the article by an Anonymous (presumeably female) reader.  This article caught my attention on numerous levels — the first being that somehow through my years I have become a champion for women in their jobs - be it technology or other.  I’ve seen too many very capable women move on because their work was somehow devalued, considered somehow to be less than their male counterparts.

Secondly the article made some references to work-life balance.  The article states that “…in tech, the average workweek is 71 hours…”.  In my book this is just unacceptable - not that I haven’t done it of course!  However, it still was not acceptable.  I remember picking up the phrase from someone that said “…we work to live, we don’t live to work…”.  I’ve always worked long hours, but I’ve also chosen work that I love to do.  Enjoying one’s work in and of itself I believe provides a level of work-life balance. 

That being said, I believe that in technology anyone, male or female, who leans toward a more “normal” work-life balance leaves themselves open for criticism and all too often become devalued in their workplace.  For example, I remember how a worker at a vendor of mine was viewed after he took “maternity” leave to be with his wife and new baby.   “Mr. Mom” lost significant respect among his fellow workers for his choice, while managing to keep his job after all the time off. 

I really believe that when all is said and done the reason why tech people leave their field often has little to do with hours, but rather has to do with how they are perceived and treated in their workplace.  If they feel valued, if they are not isolated, if they are trusted, if they like what they do — they stick around.

Specifications and Assumptions

We all know what it means to assume — but sometimes our assumptions are so completely hidden from us that we don’t even know when we are assuming.

I had an iinteresting conversation with another developer last week that illustrates this point (…and a few others that I’ve blogged about also).  It seems that my developer friend had been involved in a project for another developer who had created an apparently extensive (read as complete) almost 80 page specification regarding what the application was to accomplish, and how.  Required tables and fields had been defined, as had been the associated indexs for the tables.  (Personally, by the time I would have developed such a document I could have had a significant portion of the program created - but that is another story!). 

In the development process all appeared to be proceeding as desired — and then the customer began testing.  It seems that with one of the tables the documented indexes reflected a configuration which would allow duplicate child records - not what was desired - but what the spec allowed.  An assumption was made on the part of the developer writing the code that since the index allowed for duplicates, then duplicates must be desired and programmed to allow them (…all the while knowing that it was not usual).

This one instance indicates a problem that all developers face.  In my experience, it seems that no matter how detailed the spec, there always seems to be some underlying assumptions being made - and they make for keeping our jobs interesting.

Beta Testing - A True Story

On a visit to my chiropractor today I heard a story that I found simply amazing to believe, yet I have to believe it as I was witness to some of the “events” a few years ago - and I remember them well!

It seems that some 6-8 years back my chiropractor (always on the lookout for a “good” deal) was in need of software to handle her business - appointment scheduling, billing - the “usual” stuff for a small practice.  I remember this period as I had been shaking my head on more than one occasion as her employee struggled with the system that was being used.  I also remember her excitement that she had ordered a new system that was really going to be much better than what she was using - and she couldn’t wait until it got installed so that she could address some of the “issues” she’d had with her existing system.

Well, making a long story short, let’s just say that it was a LONG time before improvements were noted by this loyal patient of hers.  She struggled seemingly at every turn - reports didn’t work properly, things didn’t balance - just an apparently endless array of “issues” with this new system that was supposed to solve so many of her problems.  “User friendly” was not how she described her new system at the time.

Interestingly enough, today after I commented about “…good thing your computer system is user friendly…”  (her new office person was struggling with some entry is what prompted my remark) — she asked me if I remembered all the problems she used to have with the system?  (I acknowledged that I indeed did!).  At that point in time she told me “…I really didn’t understand what being a beta tester really meant!  They gave me deep discounts!…”

Indeed they should have given her the software for free from my perspective — her beta testing was more like an alpha site - only she was running live!  I chose not to ask her if she would buy into a beta testing again.

However, what I took away from this today was that if deeply discounted pricing is provided to a customer in return for being a beta test site — the developer had better convey VERY clearly to the customer just what it means to be a beta test site for them.  It seems that in this case the expectations were not clear - the result appears to have been that the 5 years of high employee turnover, retraining, and resulting frustrations and inefficiencies probably cost a great deal more than paying for a proven product would have been.

Of course, I could be wrong!

Application Expectations

I had an opportunity to witness once again the user frustration when software doesn’t perform according to expectation - in this case - the expectation unfulfilled was intuitiveness.

The scenario involved plugging in a Windows XP laptop into a network with no DHCP. (Networks I work with are all small enough that there really is no need for DHCP - and there are advantages to using a fixed IP scheme). In this case the simplicity desired was that by creating an alternate IP configuration the laptop (whose primary configuration was expecting DHCP provided IP address) would just use the alternate since no DHCP was available. Of course, it didn’t work.

In order to get the laptop onto the network we had to change the primary connection to use the “fixed” IP that we wanted — after that there was NO alternate configuration tab. (I wouldn’t have designed it that way!) . It was late evening, we were tired, we just took the easy route to get the laptop onto the internet. However, somehow it seems that we shouldn’t have had to look at help (sometimes not exactly helpful) to find an answer.