You are the Technology You Use

June 24, 2006 at 3:39 am 1 comment

I think one of the ongoing challenges of being a software developer is the blurred lines between your product and the technologies that compliment or are used by your product. That blurry border can often impact the impression of your work.

Complimentary Technologies
With QualTrax, a feature of the Document Control module is that it doesn't restrict what kind of file format you use– it will accept and control all kinds of documents.  Because of that flexibility we don't provide our own proprietary editor.  Instead we rely on the applications that are already targeted and fine-tuned for that file format, the same applications the users are already accustomed to working with.  For example, the engineering department can continue to use AutoCAD to update their DWG files.  Human Resources may utilize Microsoft Word or Microsoft FrontPage to maintain their Employee Manual.  Meanwhile other departments can continue to use Visio or ABC Flowcharter to upkeep their process maps. 


Well, a downside of that flexibility is often when a user experiences an issue in their editing application (Microsoft Word for example) — they don't draw a distinction between that application and QualTrax.  From their perspective, all they know is they are having trouble doing what they need to do.  Their struggle may just be a usage question like "How do I make this 'X of Y pages' bigger in the header of my Word document?" or it could be something that is directly related to a change or bug in the editing application.  A good (though old) example would be the Office 2000 release.   In that initial release, suddenly any Office 2000 document opened within Internet Explorer triggered a password prompt.  It was a Microsoft bug and it was rectified by Microsoft in Office 2000 Service Release 1.  Nonetheless, it was easy for a customer to get annoyed and think, "QualTrax is always asking me for a password." 

Third Party Controls
The waters are even muddier when it comes to the third-party controls you integrate into your software.  Unfortunately, I recently ran into an example with the RichTextBox control.  For this particular project, we were modifying a pre-existing web application to create a similar version for a different use.  In the original application, the RichTextBox control was a perfect fit and did its job well.  No complaints.  But when we went to deploy the new application, we had a series of complications. 

  1. First, the new web server was using ASP.NET 2.0.  ASP.NET 2.0 shipped with a new security feature, allowing Trust Levels to be set on a by-application basis.  The RichTextBox control required a Full Trust Level, but the web server being used was locked down to only permit Medium. 
  2. After we got over that hurdle, persistent popup messages were reminding us to purchase the component. 
  3. Once the purchase was made, the customer reported a series of issues with using the control.  It turns out in the original application, the requirements of the component were pretty standard– bolding and formatting text, maybe the occasional italic here and there.  The new customer was using tables heavily and through that usage, revealed difficulties. 
  4. You couldn't size tables by percentages; you had to use pixel count. 
  5. It wasn't intuitive how to resize the individual table cells. 
  6. Originally there was confusion as to how to align the text in a table cell (though that does appear to work well). 
  7. Further compounding the other issues, the RichTextBox control wasn't always refreshing its view.  That meant a user could be resizing a table cell, but not see the changes applied to the screen and therefore did not have adequate feedback to know they were successful.

Rich Text Box

Now don't get me wrong, there were other hiccups with the system.  But they were few and far between– a vast majority of the issues and frustrations arose from that one control.

Unfortunately, the customer's keen eye is not likely to isolate the control as the culprit.  It is the system that is deemed buggy.  Even though I, the developer, know the root cause, "buggy" is a label that still stings.  In the customer mind, there is no separation between the controls you use and the system.

Best Practices Thus Far
In the RichTextBox example, I can be smug and think about how I did not pick that control (I can report "buggy" still hurts though!).  But for the controls we are empowered to pick, it's extremely important when evaluating them to keep in mind that their performance and reputation directly affects yours.

At QualTrax, we pay significant note to the controls we include.  In fact, we have a dedicated Evaluating and Purchasing Third Party Controls procedure (falls under ISO 9000:2000 7.4.1 Purchasing Process) outlining our decision criteria.  We, of course, look at the threading model, the cost and the scalability of the component.  A couple of additional items we consider include:

  • Pre-Installation Requirements – What other components and software does this component need?  How will that effect QualTrax's Pre-Installation System Requirements.  Our customers work over a variety of databases, platforms and languages.  We by no means want to alienate a customer by adding a control that means they can no longer use a feature.
  • Deployment – How hard will it be to deploy the new component in the QualTrax CD Install?  Are there any specific permission needs?  It's been our experience that IT Administrators aren't quite thrilled with notion of the anonymous web access user being an administrative account.  If that's something the control requires, it is certainly going to drop in our favor. 
  • Responsiveness of the Support Team – This is key.  We've already established customer perception is tricky.  If an issue arises with the component, it's going to be deemed a "QualTrax" issue.  In the event that happens and we have to rely on the support team of the vendor, how effective and fast is that team?  If it takes the vendor three weeks (not to mention a lot of prodding) to get an answer to us, imagine the response time we'd have to our customers.  Once during an evaluation period, I had to email a vendor's support staff a question.  By the time that company sent back their first response to me a week later, the content of their answer made no difference.  I already knew they weren't the vendor for us.

In addition to those considerations, any component we implement in the software goes through a detailed feature-specific testing process on our varied platforms and with the same rigor we give our FDA 21 CFR Part 11 testing.  When we replaced SAFileUp with aspSmartUpload (for pricing considerations, not performance), the test script covered a variety of browsers including Safari, Internet Explorer, Netscape and FireFox.  The test script even specifically called for the download of files that had Japanese characters in the title.

Test Script

Leveraging Advantage Through Support
Despite one's best efforts in component and technology selection, with all the different customers, their different configurations, their different permission sets, their different usages and different levels of expertise, a question or an issue is eventually going to arise.

Although the difference between our application and other applications is very clear to us, it is our practice in QualTrax to assist with everything we can.  We are aware of and sensitive to the customer's perception and that's what we act on.  If it turns out to be a situation that needs to be expedited up to Microsoft, Adobe, Oracle or some other organization, we will help the customer in that effort as well– participating in conference calls or serving to "translate" the nature of the problem.

And suddenly the blurry line of what's yours and what's not can become an advantage.  From the customer's vantage point, you're not fixing Word or Internet Explorer or Visio or SQL Server or AutoCAD; you're fixing the problem.  Even if you are troubleshooting an outside technology– if you solve the customer's issue – you are just as much of a hero as you would be if you corrected your own code.

And what's the customer perception when it's all said and done?  That your team is the place to go for a resolution. 

I have an example for that as well!  About a year ago, one of our customers made an update to his server that broke all his web-based applications, including QualTrax.  Out of all the vendors, he called us first.  He said he knew we would be the ones who would fix the problem quickly.  His faith was well placed that day – we didn't let him down!

So in the customer's mind, you are indeed the technology you use. 

But how you choose to handle those perceptions… could very well trump all.

Entry filed under: 7.4.1 Purchasing Process, ASP.NET, Document Control, FDA 21 CFR Part 11, ISO 9000, Office 2000, QualTrax, RichTextBox, Software Support, Web Development.

Real Life Recapitulation? Counting Crows -> Jeremy Turner

1 Comment Add your own

  • 1. TGAW » Programming and Project Runway  |  August 17, 2006 at 12:13 am

    […] Materials With the Rolling 53, my Visual Studio 2003 Development Environment with ASP.NET and HTML syntax was sufficient.  However, in other situations, I may be shopping around for suitable materials (aka third party components).  In that case, I would certainly be keeping in mind that just like the Project Runway designers, the materials I chose would reflect the quality of the final product.  I would be judged on my material and my choices– I would be the technology I use. […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

Flickr Photos

3D Printed Products


%d bloggers like this: