"Emergency" programming

Had a “situation” today where some developers (new to .Net) had coded a 2 tier application on our dev servers, moved it into our UAT (User Acceptance test) environment and it wouldn't work. This was a simple 3 page app that simply saved some info in a database but it was designed/created with only 2 tiers in mind, and the UAT and PROD environment are 3 tiers. The DEV servers are not really 3 tier due to hardware purchase restrictions so all their testing before UAT worked fine.

Today comes, the app goes onto UAT, and simply does not work and cannot find the SQL server (web server no direct access to the SQL server). The programmer was on a course and someone else was standing in (very little .Net experience) in case there were probs.

Well panic set in as the app would not work. They give me a call and off I go, cutting code as fast as possible to separate out this app into 3 tiers. To make matters worse, it was coded in the VB.NET, and I am a C# only kind of guy. I haven't coded like this for a very long time and it was actually quite invigorating. Fingers flying, code pumping, I felt like a machine (I was being plyed with copious amounts of coffee tho...). About 3 hours later, the app was separated out into 3 separate assemblies, remoting was put in place so that the front end would remote to the DAL layer on the app server, which would perform the update, and deployed into UAT. Was it elegant...no way, but it worked, and got the app into UAT for the business to start playing.

Funnily enough, the course the programmers were on is a .Net course and when they come back, we can start the education process about what should and shouldn't be done to prevent this situation.

Anyway, enough of the fast and furious, back to the placid world of sensible well designed systems....

2 Comments

  • The first question, I would think, should be how did a project whose architecture was clearly at odds with you companies design philosophy (2 vs. 3 tier) get as far as UAT without anyone noticing?

  • Thats a good question. In my opinion it was the following :-

    a) It was so small an app, 3 very light pages and so its simplicity was taken too far.

    b) the programmer really didn't have much .Net experience at all (and head meagre ASP classic experience)

    c) just bad design and process.

    The development environment was setup to be 3 tier BUT it also had SQL installed on the App server and so their 'dev' tests got away with it.

    It really comes down to lack of experience and design abilities, and bad testing practice. The individuals concerned were *very* red faced when they came to me, so hopefully its enough of an education to prevent further "outbreaks".

    Mind you, you'd be suprised at the "quality" of some applications in some large orgs (ours and our major clients) but thats another story.

Comments have been disabled for this content.