Back in 2006, Steve worked as a developer at mid-sized financial services firm. Like many organizations with central IT operations, departments within Steve’s company had the option to “buy” application development services from IT, or use an outside vendor for their business software needs, provided that the vendor’s software met IT’s security and technical requirements.

Generally, getting IT’s approval was easy: the purchaser just needed to set up a meeting between the vendor and an “integration services” developer on Steve’s team, and then wait a few days for approval. But every now and then – such as when the HR department hired GlobalComp to build a web portal – things get a bit tricky.

The GlobalComp Review

After the GlobalComp sales rep gave his spiel about how wonderful and innovative their web portal technology was, Steve opened with a softball question. “Is it secure?”

“Of course it’s secure,” the rep said, “we at GlobalComp take security very seriously. In fact, our pages are delivered over Secure Socket Lay—”

“Wait a sec,” Steve, who had been playing around with the web portal during the presentation, cut him off. “I think I just broke into your admin console.”

Red-faced in embarrassment, the GlobalComp rep stumbled through an apology. It was clear that the developers had never anticipated someone typing ' OR ''=' in the password field, and Steve thought it’d be a good idea to do a code review to see what else they had missed. The rep hesitantly agreed and set up another meeting.

A Code Tour

Before Steve was permitted to even talk to a developer at GlobalComp, they had him sign a lengthy Non-Disclosure Agreement. As an added security measure, Steve could only review the code while the immaculately-dressed Dave, GlobalComp’s lead developer, watched him. “You’d be surprised,” Dave said in a serious tone, “there are a lot people who would steal our software ideas.”

Steve’s first port of call was login.asp. But it wasn’t the security snafus or the Microsoft FrontPage meta-tags that caught his eye. Not only were they using Access, but they had come up with a rather interesting way of caching huge amounts (400K+) of user-specific information. They used the ASP Session object.

<%
set conn=Server.CreateObject("ADODB.Connection")
conn.Provider="Microsoft.Jet.OLEDB.4.0"
conn.Open "c:\inetpub\wwwroot\database.mdb"
set rs = Server.CreateObject("ADODB.recordset")
rs.Open "SELECT * FROM Users WHERE Username = '" _
    & Username & "' AND Password = '" & Password & "'", conn
do until rs.EOF
session(“USERNAME”) = rs.Fields(“username”).value
session(“COMPANY”) = rs.Fields(“company”).value
session(“LOCATION”) = rs.Fields(“location”).value
session(“ADDRESS1”) = rs.Fields(“address1”).value
session(“ADDRESS2”) = rs.Fields(“address2”).value
session(“ADDRESS3”) = rs.Fields(“address3”).value
session(“ADDRESS4”) = rs.Fields(“address4”).value
session("HTML_BLOCK_1") = rs.Fields("html1").value
…180 columns later…
session(“YET_ANOTHER_FIELD”) = Rs.Fields(“yet_another_field”).value
Rs.MoveNext
loop
rs.close
conn.close
%>

“I can’t help but notice that this is in ASP,” Steve said to Dave. “I’m curious: why not .NET? Do you have a lot of ASP libraries that you’re reusing?”

“It’s 2006,” Dave snapped back, “not 2015. Everyone knows that .NET hasn’t really taken off yet. It’s slow, difficult to code, and very buggy. Maybe in a few years we’ll consider it, but until then, ASP is far more quicker and powerful.”

Steve quizzically raised an eyebrow, “all right. But can you elaborate on what you’re doing with the session over here?”

Dave smiled. “There are many clever things we developed to optimize the performance of the product. This is just one example.” v“For optimization,” Steve commented, “wouldn’t it have made sense to go with SQL Server? This portal is meant to be used by thousands of users across the country. Do you think Access is up to the job?”

“What’s wrong with Access?” Dave defensively questioned. “When I was at Accenture, we used it all the time?”

“Ummm,” Steve responded, “you’re telling me that Accenture routinely passes over databases like Oracle and SQL Server, and chooses instead to deploy their solutions using Microsoft Access?”

“Yep,” Dave nodded, “they certainly do!”

The Final Verdict

After spending a couple hours with Dave, Steve had learned more than enough to write his review report. “In light of the numerous performance, security, and data-integrity issues,” the executive summary read, “we do not approve GlobalComp’s web portal software for use in our production environments.”

It was the first time that that Steve, or anyone else in his department, had ever given a non-approval for vendor software. They felt relieved that they had successfully acted as the gatekeeper of bad software.

This was also the first time that Steve learned the consequence of rejecting a vendor. The HR department huffed, puffed, and angrily protested to the CTO. The CTO then overrode the rejection and GlobalComp’s software was purchased anyway. C’est la vie.

 

Slow, Difficult to Code, and Buggy was originally published in Alex's DevDisasters column in the May, 2009 issue of Visual Studio Magazine. VSM is a free magazine for software architects, senior developers and development managers that includes practical, proven, unbiased how-to articles readers can put to use immediately.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!