Bits and bobs

In my previous post I talked about the database, and some of the hardships we encountered during this project. Now I would like to go through the application layer and describe some of the critical areas which hurt us druring and after the development. Web UI Architecture I think there is a beautie in simplisity which is offten mistaken for lack of experience of expertise. I think this was the key driver for much of the core designs used in this application. Our initial requirement document stated, the site must be built using web parts, and it described in great detail how each of the web parts interact with each other. However, no thought was given to how this would be used by the end users, how was this going to solve the business problem, how was it going to be utilised to benefit the end user? Only once most of the application was built was a thought given to the end users, and how this architecture would work. It became clear the solution was Technology driven rather then busines...

I recently finished up on a project which has seen some troubled times. I think it is very important to stop and think about what did work, and what didn't work after a project is finished (or near finished), and get some pen to paper so that the memories do not fade (along with key learning's ). Starting right from core of the application, the database. Right from the onset, the client was driving the database design. We put up a few questions and concerns, but as the client was very insistent that we use this design as it was the same design used for another similar project, our hands were tied. In retrospect, this was a critical mistake, we really should have done some analysis on the types of issues we could have and explained to the client what our concerns were on a factual basis. I have never seen this before, but if the database is over normalised it can get quite complicated, and bit you very hard when you start look at performance. Logical Model Vs Physical Model...