Nothing very much, I felt as if I have only been doing one thing. Am 100% sick of it.
Cow-selling Notes CR for AiFalm.
Life wasn't too bad after I returned from my holiday. At the turn of the year, my PM informed me that I would be involved in a major CR. It was scheduled to go live on April's Fools Day, so time was tight and we would have to start work immediately although the specifications were not finalized yet. Knowing our customer No Hope Group's pattern very well after all these years of
The truth was, from users' perspective, WE were going to be the ones running in the opposite direction of the conveyor belt that was rolling us towards the screeching saw.
The team consisted of me, R as the TL, J as the QC and a newcomer from country C, S as another developer. Apart from coping with deadline, still need to 带新人! Good luck to us!
Since I was the more senior of the 2 developers, I was handed the tougher pie. On top of that, I still had to write API while S developed the screen. Shit! That's ultimate bad news for a trial and error programmer who never knows whether her code is correct until she sees the output on screen! And I was going to add on to the most complicated and 恐怖 screen. 祝我好运...
As usual, the specifications were not very specific. While coding, it was evident that the screen was not very user-friendly. There were secret functions (Easter eggs?) waiting for the developer and user to discover. For example, there were + - buttons for adding items to a list. According to the specifications, update to the list item will be supported. However, there was no mention of how to go about updating. So the developer would have to make an educated guess. Code in the way that the user would most likely perform the task intuitively (they might not even realize that it wasn't mentioned in the specifications) and not too hard to code.. In a way, it's ”not following the specifications”. Risky as the user might throw a tantrum instead.
My solution was to make the user highlight the row first. Make the changes and click on + to confirm. Now a button has dual functions, behaving as add/update, hinging on whether a row is selected. O and if you select, modify and accidentally select another row, your changes will be GONE. Haha can start anticipating bugs already. Don't care let the users discover themselves.
That's just one of the numerous landmines waiting to blow up in our faces. Curiously, the CR was first brought up nearly 1 year ago. So long already, still haven't finalize.
SIT was soon after CNY, so some of my holiday was spent catching up at home. Some weekends too. Some very late nights on weekdays.
The users finally signed off the specifications, not before the PM issued threats and them wanting to add more requirements. No problem, quality suffer only.
S is not a bad coder, in fact he likes programming (!!). He just needed some guidance on AiFalm's standards. He claimed to have not done J2EE before, but he caught on very quickly. But love for coding can be a double-edged sword. He proposed new ways of doing things that sounded great, but sorry, cannot, because no time for him to experiment. I think that's why you can't make your hobby your job because there exists so many ways to kill your interest....
His weaknesses? Weak command of English has to be the first. I think he and our dear Indian TL had a hard time understanding each other. Interpreter required. J had to sit beside him to guide him word by word. No choice, send his version to users sure kena complain. Sometimes, practically all his documentations had to be rewritten. O well, invest time and hope he will improve.
Intuitive choice of variable names like obj1, obj2 that look very cool on textbooks. Seriously, does he even remember them himself? The epic - S was tasked with exploring how to resolve an unpredictable Javascript error in my file. He spent some time and announced it was done. We didn't have time for code review, so we took his word for it and deployed to SIT. Unfortunately, the Javascript error still existed. I don't blame him, since it wasn't reproducible consistently. It probably just didn't happen when he was testing.
But I was still curious about what he had done. Omg, he had revamped the code till I couldn't recognize it anymore. The Javascript was converted to Java scriptlet with the obj1-style cryptic variable and method names. Did I mention before that I hated computing textbooks because they love to write like that and I couldn't understand at all? There were unnecessary method calls, like Method A -> Method B (which does nothing except call Method C) -> Method C. Worse still, I found a broken code! *palm face*
Super careless. Tell him things to note, but later still forget. Tell him about a bug in a part of the file and ask him to fix all occurrences, in the end only fix the one we told him. Warned him of potential bugs, but later still created those very bugs. Asked him to add new functionality, but removed another in the process. Merge code still can miss out things although I have introduced CompareIt to him. No choice, got to complain to PM to get her to counsel him.
It didn't help that J was going through a family crisis + study stress. 乖乖 code, create less bugs...
The users were the hounds out for blood. They need a refresher course to remind them the purpose of UAT. They are supposed to test the functionality based on that document with their digital go-ahead. It is NOT a requirement gathering session. That screen they were clicking on was NOT a mock-up. As always, they complained of poor usability, so it's a design fault on our part. So bad that they didn't even want to start testing. We should be able to read their minds and conjure the perfect layout containing exactly all the information they would like to see.
Right. So why didn't they feedback earlier? It's because they wouldn't know until they tried their hands on it, they reasoned.
With people like these, I honestly think a few rounds of mock-up testing would do us all good. Just that the users have to pay for the additional effort. Which they wouldn't. Hellcare always ”no budget” one.
Like always, the users started asking for enhancements, which had to be ready by the next UAT, on top of the bug fixes. A few from each user, multiplied by 7 institutions, that's a lot. And it's all for free. I know we were not going to get a fatter bonus by making the users pay for them, but it's to teach them a lesson and hopefully result in more realistic deadlines for us developers in future. Suka suka sign off first because they didn't want to always have to make all their friends agree with what each of them wanted before putting down the requirement in black and white, later then try to squeeze things in later during UAT. That is a 贱招 they have pulled off time and time again. I have observed that it's actually an express lane where wants get converted to reality many days faster. That is NOT the way!
Of course, we have to bear some responsibility for pampering those users in the first place. Every CR also want ”goodwill” discount in the quotation. Then wring mandays out of us by the above ploy. Weak PM?
Result? The screen where 80% of the action was, was beyond recognition. Even the users noticed. There was simply no time to update the specifications. We only had our memories, issue ID commented in the codes and release documents, which were most at risk of going missing. Do it when this thing was over? By then, we would have a new hot potato in our hands!
Judging from prior CRs, nothing was going to get updated. Good luck to whoever's doing production investigations next time.
And so users were loading us with so many enhancements that we didn't have time for proper coding and testing. The side effect was bugs lor. They still had the cheek to complain so many bugs! Why, those were bugs on their enhancements mah, they asked for it!
Resulting Workflow
1) Conduct requirement gathering. Arranging meeting(s) with at least 7 people working at all different places and schedules are probably necessary.
2) Draft the specifications and send to users for review. Allow n days for them to procrastinate.
3) Discuss the feedback during another meeting.
4) Repeat #2 and #3 until nobody has anymore feedback, or until the developers have to OT every night given the current schedule, whichever comes first.
5) Ask users to sign off the specifications. Meanwhile, developers start work while PM prepares the threat email. Wait n days.
6) Send the threat email. Users respond because either they weren't thinking or didn't want to agonize themselves with #2 - #5.
7) CR completes development and SIT in a mad rush. Years shaved off the team's life expectancies.
8) During each day of UAT1, users present the cool ideas they were secretly brewing, which usually get the nod within 1 day because the team only had max 2 days to let the idea finish development and SIT. No time for all users' consensus. Maybe some missed the email, so they weren't aware there would be such a change, but too bad. Team entertains thoughts of quiting, but decided against it since CR would be over by the end of the notice.
9) Repeat #8 for UAT2, which is supposed to be the final UAT.
10) Last minute arrange for a special UAT3 for bugs outstanding from UAT2. A few users still try to squeeze more things, but get rejected.
11) E, feeling entitled, threatened that users on the ground will reject the CR altogether upon rollout as the system is unusable without his proposed enhancement. PM told him to go fly kite. Way to go! Want something perfect? Delay lor! We don't care!
After going live, it's the usual business of fixing bugs reported. Say we never test thoroughly lah, miss so many scenarios... You users also don't know all what! In just one screen, there are endless permutations of actions. It may sound like excuses, but realistically, it is impossible to test thoroughly. Not with the puny sum the users were willing to shell out anyway.
Nightmare was not over yet. There's an outstanding deliverable that deserves a post on its own.
No comments:
Post a Comment