Disclaimer: I am a GUI guy by trade.  I’ve worked in user interfaces since I was 6.  Yes, I wrote code in BASIC back in junior high, but it was never “fun”.  I like to just fire the thing up, look at it, tweak it, and run it.  Code has to be remembered, researched, and formatted.  It’s picky.  It doesn’t like to be “just written”.  Brackets have to be flawless.  Case matters.  So many things to think about.

Yes, I’m familiar with and can read/write (mostly) .NET, JavaScript, VBScript, HTML, etc.  Yes, I know IDEs are designed to make some of that easier (but only if you have 95% of correct already). But I only like doing it to extend an application that’s deficient.

I don’t picture myself sitting and writing code all day, every day.  Just isn’t my thing, I’m not nearly good enough at it because I don’t have the patience.

Now, to the point.  I understand the value of writing code.  But I take the path that code should improve upon a thing, not be a thing, unless you have no other option.  Many websites these days are actually rendering from a script.  I can’t stand that.  I use the NoScript plug-in religiously, and of course these pages don’t load at all.  

Used to be that standard HTML was good enough for most everyone, and even throwing CSS in there is fine; scripts were more for “rich” or active content that wasn’t required for accessibility or readability.  HTML and CSS are, for the most part, safe and not likely to harm an operating system.  VBScript is not.  JavaScript is not.  If all you’re doing is showing a news page, why do you need a script to just display text?

I have the same gripes with ECM implementations.  Many that I come across all say they want a Java/.NET developer, and right away I know they’re just going to write some custom application.  But then I see they own LiveLink or FileNet or Documentum or OnBase or Stellent or something else, and I question why the custom application is needed.  I ask further, and all they’re really doing is writing some tool to view documents.  Their reason: “<<<insert vendor here>>>’s application is ugly.”

I miss the days when companies just wanted things to work.  They were not so preoccupied with internal only user applications.  I don’t know, maybe I’m the only one who clearly remembers how horrible and childish Windows 95/98 looked, with Clippy nagging you at every turn.  Nobody cared; all that mattered was that it allowed users to launch their apps and get things done.

Say a company wants to automate their invoice generation and archival system.  They would like to automatically retrieve stream data from their accounting software, dump it into their content management system, generate PDF invoices, and make them available to vendors via a custom web interface.  Straight forward, right?  But there are many ways to do this.  ‘

Some might just crack open Visual Studio or some other IDE and start writing code.  Some might lean towards SharePoint.  There’s nothing wrong with choice, and it really does boil down to how much a company wants to invest for the end product.

Normally, a company should follow a few generic steps to getting that system up and running.  Some of these steps may not apply, depending on the size of the company, but they all assume the company is going to build it in-house rather than outsource.

Draft high level requirements and expectations.  Are all invoices to be archived, or only a subset?  What is the selection criteria?  What is the SLA for invoices being available?  What is the transition plan from the current application to the new?  What is the “finish line” (i.e. success criteria)?

Determine the players.  Who is ultimately the final approver for what gets done?  Who will refine the requirements?  Who is responsible for development, QA (if applicable), deployment, and support?  

Determine the approach.  Will it be done in phases (i.e. electronic archival first phase, electronic presentment second phase, etc.) or all at once?  What is the timeline for delivery, and how does it match up to the approach?

Step 2 is where things start getting cloudy, because there’s always a bias.  Say your developers are 100% SharePoint guys and gals; the first suggestion will always be SharePoint for the solution.  That’s fine, but is that truly the best solution based on what the success criteria demands?  Yes, SharePoint can present data as an external interface, customized according to business design specifications.  But can it take backend stream data, parse and format it, apply an overlay, convert to PDF, and index it without user intervention?

(The answer is “Yes, with external tools and lots of code.”)

Compare that against other systems such as FileNet, which is significantly more expensive than SharePoint, but contains every component necessary to meet the stated objective.  Suppose that our mythical company owns both SharePoint and FileNet, but FileNet has thus far been only used for back office activities.  Additionally, the company does not have significant FileNet developer expertise in-house; most of what’s built came with the system when it was first set up.

Don't force things

There are many schools of thought with this; I’ll share mine.  I’m a firm believer in “right tool for the job”, rather than “square peg in a round hole” with respect to meeting business objectives.  In other words, if I have a tool that can do everything I want despite it not being friendly looking or easy to use, I’ll prefer it rather than trying to force my preferred application to do something it wasn’t designed to do.

Often, customers will apply their own bias for or against a given application based on what they know and are comfortable with, rather than selecting the best tool for the job.  If I have a high speed scanner with Kofax VRS, I’m going to prefer it over a multifunction device that happens to have scan capabilities if they’re in the exact same location.  

I wouldn’t print and manually fax a document through a multifunction device if I have RightFax with email-to-fax capability (before anyone jumps on me, know that in the response to “I need to sign it!!!”, FoxIt Reader allows you to stamp a signature bitmap on any document for free).  The list goes on and on.

So our mythical company may have meetings to discuss the right option for building the new portal, and almost instantly, everyone will go through a groupthink phase after Developer A chimes in with full confidence that SharePoint can do 100% of the work.  Yay, us! It’ll only take 4 months to deployment. 

But then the lone FileNet developer, who was only invited to the meeting because his manager happened to call in sick, chimes in to ask, “but FileNet can already do all of that, and just give the data to SharePoint as a front end, with little to no code needed, in about 1 month...”  

Immediately, all other heads turn to glare at this upstart that dares question the value of writing code to build amazing apps.  How dare he suggest that we use out-of-the-box functionality when we can CODE ANYTHING!?

“But...isn’t the point to save money and time, rather than spend more of it building something from scratch when we already have the tools to do it?”

It’s at this point the FileNet developer has effectively done one of two things: blacklisted himself from future discussions, or raised awareness about a tool nobody realized was available.  While the former is more prevalent, let’s be optimistic and assume the latter.  

It goes down to the need to code, versus the desire to code.  Coding takes time - a lot of time.  If there’s an application already available to do the job within an hour or so, does it make sense to write code for a month simply because you are used to coding everything?  Or is it a control issue, where you want control over 100% of the experience?  Have you questioned the underlying reason for wanting that level of control or feeling it to be necessary?  Most important, have you considered the support?

Support is so often overlooked it’s silly.  When a custom built application is presented, it depends on extensive documentation from the analyst and developers to make sure that support personnel have everything they need to keep the users happy.  Often there are defects that get missed in the first round of QA (imagine that) and are eventually uncovered by the users.  These get logged as tickets, researched and corrected, and often documentation needs to be updated.  

Who is on tap to keep documentation current when these changes happen?  More importantly, how are the tickets managed and visible to all parties to make sure that everyone is aware of the types of problems users are experiencing?

The most important question: Are the problems users are experiencing a side effect of the control issue I talked about before?

In an out-of-the-box application situation, especially if the application in question is used by thousands of users on a regular basis and has been in existence for a good period of time, true defects have already been fleshed out and corrected.  Most of what is identified is preferential to the client, the user, or the IT staff and not a problem of the application.  Delivery of functionality is faster, because the company is not tethered to a development lifecycle.  

Time and place

So when and why would I use code?  As I said, when I have no choice.  Say I wanted to display data from my line of business (LOB) application in text on a Web page after authenticating a user.  Disregarding the fact that very few LOB applications support customer facing portals, there are security implications to it that can only be overcome with code.  The authentication layer also must be developed, and for any stored data, database development is necessary.  There are out-of-the-box customer portals available, but they are often generic and not capable of transactional data exchange. Another example would be where a bridge between two systems is necessary.  A good example of this is with online colleges that use hosted email; they will write custom code to call the hosted solution API to display information back to the student.  

Could the student just log into the hosted environment?  Yes, but if the hosted environment is using a shared security credential, custom code is required to handle the handshake properly (the student would not be able to give the credential directly).

It’s all subjective though, and certainly everyone has their own opinion about it.  Mine is this: with ECM in particular, consider whether you absolutely need to write code to get the job done.  Take the time to investigate the tool and decide if you can achieve your objectives with what you’ve already got.

Marcus Christian is a Senior Consulting Software Engineer at Blue Slate, a business process management and technology solutions firm headquartered in Albany, NY. Contact him at Marcus.Christian@outlook.com