Assalamualaikum everyone, and good afternoon. A couple of days ago, Abhiram informed me that the client would like to change the pricing structure of cruisealleppey. Personally I would not want to do so, as this is considered a new phase of the project and I’m not going to continue so due to my lack of time. Abhiram then asked me on what will be challenge on implementing the changes and here are my email to him. I personally love to put this in my blog as it feels like an article I would like to re-read in the future. So here it is.
The first thing to take into account is that this will require change of database table fields, and depending on scenario, it will need another table. Now, by changing the database this much, one thing for sure, the database need to be reset especially the booking table , houseboat table and associated table.
Now, regarding the code, the cruisealleppey system can be grouped into three distinct software, the main UI, superadmin backend and vendorbackend. Vendorbackend is responsible for both agent and vendor interface, so we can say that it is basically two interface. Each group of these four have pages which directly work with the bookings. Notably the add booking page which exist on all interface, main ui, superadmin interface, vendorbackend vendor interface and vendorbackend agent interface. The vendorbackend vendor and agent interface has edit booking page, also need to be changed. Also, each interface has page to view the booking details. Superadmin has view booking details, customer can view their booking through the main UI, vendor can check booking information and agent can also check booking information. Another four page to modify. Also, the reports generations such as invoice and voucher may be changed to accommodate for the room price also.
That is the code that interact directly with the bookings. We will also need to modify pages related to houseboats, which in short (if I explain it, it will be about the same as the above paragraph) is 3 (add, edit, view) multiplied by 4 for all four interface (main ui, superadmin, vendor, agent). Bare in mind, all three software follow the highly recommended web architecture, the MVC (model view controller) pattern. Therefore, each page works with at least 3 file (excluding web framework), some which are shared between pages. In this system, the model is shared between all three software, but still, controllers and views need to be altered separately. Any changes to the design such as the price calculation algorithm is implimented in the models. So the models file also need to be changed.
Magnitude of ‘changes’ required for each for each of these file depends greatly on the particular scenario. Here I propose two contrasting scenario. First, each houseboat has a ‘price per room’ field. This is the simplest form of room prices. When the customer book, they will need to be presented with the number of room they want to rent. The downside is obvious, there will be no distinction for each room, and thus every room has its own price, and to the system (and thus the price for the customer), there are no different between rooms. The other contrast of the change is details for each room is recorded individually. Therefore, the customer can choose which particular room in a boat to book. The vendor can then assign different price for different room which may have different feature and description and also price. The downside is, this require quite a significant change in the technical side. It will need addtional two table, and a much more complex form for every page which require it. This is a very big changes.
Of course, when we look at it, any change on the booking system small or large will result in a large number of changes. This is because this whole cruise alleppey system is about houseboat booking and thus booking is its core business. Changing the core design is basically changing the whole code. It is well, known that in software development, changing the requirement after the building phase can result in a much larger cost (time and money) then changing the requirement at the design phase or project initiation phase. Sometime can be in order of hundreds time greater if compared between initiation phase and building phase. Part of the cost penalty can be explained by the fact that some of the code is build for the old requirement and some of this old code may be left out when modifying the code, thus breaking the system, incurring more time and cost to test and debug it. Thoroughly checking the code for these kind of old incompatibility will also require more time and money. In short, any way, it will cost more time and money.