Wow I haven't been blogging for so long. First, I was so free that nothing was happening in my life. Then life became so happening that I didn't have time at all. Yup, rushing project again. This time, it's something that has been signed off almost exactly 1yr ago, coded, but users found the program didn't suit their needs, so here we go. I wonder if any project in this world has gone smoothly with zero hiccups at all, EVER.
My blundersYup, there's some contribution from me, resulting in a mad rush. Didn't follow the specifications exactly. Sometimes when coding, I put in some logic from previous projects unwittingly. Or left out something. Luckily easily rectified. Only resulted in some time wasted, but it's still time wasted.
Too faithful to the specsThe system is browser-based, so everything is in HTML. Previously, our spreadsheet is coded such that the spreadsheet header and body are in different table tags, so if the data to wider than allowed by the column width, the header and body of the spreadsheet will go out of alignment.
+----+--------+------+----------+|Name| NRIC | Plan | Cost |+----+--------+------+----------+|ABC |S1234567D|MacDonald Plan|7|+------+------------+---------+-+|DEF |S9876543D|Meh Plan |2|+----+---------+--------------+-+It looks terribly ugly and unreadable. It's also a waste of the developer's time to try to align it because it is mission-impossible when the standard resolution for this application is 1024x768. In short, not enough space on the screen for long data. The only pro about it is that on loading the screen when no data is populated in the spreadsheet, there is a white background to delimit the boundary of the spreadsheet.
So some genius (I mean it, not being sarcastic at all) came up with a new layout that solved the above-mentioned problems once and for all. The only con is that on loading the screen when no data is populated in the spreadsheet, there is NO white background to delimit the boundary of the spreadsheet. Last year, the whole team was instructed to use this new layout for future new developments.
But I find that people have the problem with that cosmetic difference on load, despite the overwhelming cosmetic (and usability) improvement once data is loaded. Comments from our very own internal QC (L again, who tried to promote me
quack science) for this project (and also asked before by another QC for another CR).
L: Why is there no white background?
Me: I am using the new layout.
L: What? There's no white background. It should have.
Me: No, the new layout is like that.
(Maybe can, but I don't have time for that)L: You should follow the specs!
Me: But we were told to use the new layout. Otherwise the alignment will go out.
L: But the specs said it should be like this.
Me: The user wants the OLD layout?
L: Yes! Follow the specs!
Me: Ok...
Of course I was unconvinced. How can anybody actually prefer the inferior layout over the new? I wasn't in the mood and position to argue with L over that. She has more experience with those bunch of users, surely I can't know them better than her? So I decided to give her what she wanted first to get her off my back and I could move on to more pressing issues. Of course I made a backup of my beautiful file first. They WILL want this :) Didn't try to hard to align the old layout properly. As I had said, it's mission-impossible.
After the files were migrated to SIT, I warned L that the alignment was out and there was nothing I could do about it. Indeed, it was so awful and she decided the users would not accept it and consulted the PM. A discussion between them ensued and when it quietened, the PM came to talk to me.
PM: Hi Sotong, can I talk to you?
Me: Sure!
PM: The screen is out of alignment, you know that?
Me: Yes I know, but there is nothing I can do with this current layout.
PM: You know right, our users use our application to dispense drugs. They look at it day in day out, and it is very frustrating if they cannot see things clearly. It can cause them to make mistakes if they mistake one column for another. For example, screen XXX, last time the users made so much noise because of the misalignment.
Me: Yes I agree.
(Funny, how come suddenly tell me this story?)PM: Actually you know what to do right? Just last week you suggested to use that new spreadsheet in the mockup I asked you to do.
Me: I know, I did it that way at first, but L asked me to change.
PM: The other screen you gave looks ok, because the data is not so wide. But this one ah, cannot you know?
Me: (Confused!)Wait, you are saying if alignment will not be out, we should use the old spreadsheet? Only when it is out, we use the new one?
PM: No, it may look ok now, but what if there is long data in the future? It will go out again.
Me: (Trying to look helpless. I suspected L didn't tell the PM the whole story, if not, why would the PM be telling me all these?) But L asked me to do this way.
PM: I will go talk to L. But you understand right?
Me: O... so always use the new spreadsheet lah?
PM: Yes!
Me: Ok! I will change.
PM: Will it take a long time?
Me: 5min only, I just have to revert to my backup.
(Flashes a grin)PM: Next time you have such doubts, you can come talk to me.
Me: Ok.
(But I still prefer to let them fight things out without me)I don't blame L, it's only her job.
Played by machinesAlways kena funny problems, but this time is the worst.
Lousy Websphere Application Developer (WSAD) couldn't detect my new EJBs. Took several rebuilds and restarts of my pc, which are very time-consuming.
Then WSAD even missed compilation errors, can you believe it! I had compilation errors that went undetected throughout my whole development period, only to surface in SIT as runtime error.
Then after that file with undetected compilation errors was corrected, while compiling the files for deployment to SIT, somehow that same cursed file kept being compiled with the old version, meaning still with the compilation errors (and undetected somemore, sheesh). Not just once, but many tries! Even the TL was stumped. So much time wasted here. And it's my file! People who don't understand must have thought I am so damn lousy, boohoohoo.
Then there's a point in the program where it called a method it's not supposed to call, resulting in runtime error. In any case, it shouldn't go there, but it did. Nobody knows why. Fortunately, it was solved by redeploying once only. But the bad news is, it's my file again. SO MANY BLOODY UNEXPLAINED ERRORS, SO BLOODY SUAY.
If you don't know what I'm talking about even with programming background, it's because it simply doesn't make sense at all. Really 被玩到死死.
Last minute structure change to a main table... after I have completed a screen to display data from that screen. Meaning I had to recode it with more complex logic. From the easiest screen (just select and spit out all), it became the toughest, most time-consuming and... more to come below.
Other areas impacted are small, not a problem.
Investigating a bug... only to find that it's not youAn existing screen was enhanced by the TL for this CR. While testing for him, I discovered some info will disappear and later reappear. I was tasked with the debugging (he had other things to do). Had to merge our files to make sure it's the latest, recompile them, which took up like 2 or 3hrs in all. And frantically chasing this mysterious case among unfamiliar codes, methods calling classes calling classes calling methods.... to find that the offending code is in a file untouched by the CR i.e existing bug. Since it's 1)not affecting the CR, 2)been there since Day 1 3)and the users don't have a problem with it, we don't have a problem with it either :)
By then, whole afternoon gone. OT again.
Last minute requirement change1 week before the UAT, we were to give the users a demo of the CR. They were done at 7pm and were happy with it. Their departing gift: to change the display logic for the easiest-turned-toughest screen. The original logic was to display all. But now, they wanted it such that when they searched by criteria A, it should display effective records. But if there are only past records, it should show all.
Sounds easy? NO LOR, when the screen is about searching and displaying records, and you want to change the way it works, we are talking about a major revamp.
Remember the time now? I must complete it by end of next day to make it for the next deployment so that eventually the users can have it by UAT.
F-U-C-K-I-N-G S-H-I-T
This is not the only change requested. There's 2 others, but much easier compared to this so I won't complain about them.
2 days later, the users requested to come to see the changes they wanted "because it's hard to visualize". They found the F-U-C-K-I-N-G S-H-I-T change so cool that they wanted to apply it to 2 other search criteria as well!!!!!!!!!!! And PM said ok! DUE THE NEXT MORNING!!!!!!!!! To be in time for deployment again.
BLOODY HELL THEY THINK IT'S SOME DRAG AND DROP COMPONENT IS IT??? 40% revamp!!! It's 5.30pm by the way.
Should have been a CR lor! Never do impact analysis and anyhow ok!
...It's not you, but still have to fixDuring UAT, users found a bug in an existing screen and they had a problem with it. Asked to fix :( Really weird cause, but very easy to fix.
紧张刺激的UATIf you need some excitement in your life, you really should have UAT. If any hiccups occurred, it MUST be your fault and you will scramble to clear your name by frantically investigating. To increase the excitement, the UAT environment is located in a different level of the building which is not so convenient for me, or accessed via VPN, for which you have to compete with the rest of the office for access. Person conducting the UAT will keep pestering for updates because "users are waiting".
Luckily nothing bad for me, yay!
I need to go out.