Project Woes

Well, as you may know from the previous entries, we were due to enter performance testing for a project I have been designing and working on. Unfortunately, what was once a nice and harmonious relationship with the client has now turned a bit sour as we did not enter UAT (User acceptance testing) by the due date. Initially we missed by one day with some known problems in the system that we were working to fix. Unfortunately, the client has used this as leverage to put the pressure on and now we are backtracking to get everything requested and have been  falling further behind (we are now almost a week behind). Performance testing has been shelved for the time being not only because we were behind, but also due to infrastructure and other issues beyond our direct control. So I can't report to you how wonderfully stable and resilient our application is at hundreds of concurrent users :(

It has been -extremely- stressfull and all of the developers and testers are doing extremely long hours and whipping out work at a very fast pace. Without the use of .Net in this instance, I have absolutely no doubt that we would be in an extremely dire position in terms of meeting deadlines,  not too mention we have been able to build a very fast and complex application in a short period of time. However, even the best technology in the world (which I consider .Net to be), cannot help a project that is affected by a number of other governing factors such as estimates that are far too small, reliance on external groups/divisions that fail to meet obligations, very demanding clients and a host of others.

During all the hassle, it has become evident though, that the application is fast (given the huge amount of data involved in some requests), stable and very resilient. One example of this happended purely by chance where a tester was using the system and was in the middle of a process (was on about page 4 of 9). The tester went away from their desk, and in the meantime, I was compiling a new build of the development system with which the tester was using. I had performed a recompile, updated the web server with new DLL's, unregistered the COM+ packages on the app server, updated the DLL's on the app server (remoting part and the COM+ packages) and re-registered the COM+ packages. The tester returned to their desk and continued to work with the application without any loss of information or state, and no loss of productivity, apart from a minor slowdown as the new "build" was linked/compiled/loaded into the newly created appDomains on the web and app server. The tester was totally unaware of the process and things continued smoothly.

So there are some positives out of all this confusion. I am still very keen on performance testing as this is integral in meeting obligations, especially contractually where the client expects the application to be able to handle a particular load now, and the projected loads in the future.

As usual, I will keep you posted....

 

1 Comment

  • Tell me about it...


    I've been in a situation more than one where the customer used every trick in the book in order to get more out of the spec(mising one day of shipping was cause for some *big* feature requests). Sometimes politics play a much bigger role than anything else...


    that's life...

Comments have been disabled for this content.