06/04: The cold war of inability continues..
I am trying to figure out why we are listening to Jefe at all regarding how CB is handled from now and into the future. Really.. she makes random sweeping changes to straight forward fixes to address things the rest of the system can't handle.
Okay.. follow me on this one. We have similar data in two different databases. There is an instance where if a user creates a cost code in database A, doesn't click the "refresh" on the budget screen, and then the cost code list in database B doesn't know there is something new from database A. The users type the new cost code number on the fly in our budget screen. The system treats it as a new cost code on *that* side.. gives it a default type (the user over looked keeping it the same).. then saves. A synch process is kicked off, and the original type information in the database A is over written.. hell breaks loose.
Sticks is working on the fix. Wonderful. He "finds" the solution (though that was written by me in the work request), and I suggest the solution is if we save in the new cost code screen refresh the list of cost codes in the budget screen. Bam! Easy cheesey..
Except.. EXCEPT... jefe gets involved...
She decides my solution is wrong (sort of)... and then tacks on this whole bunch of crap because she is worried about multiple people in the same project on the same version doing changes. Ah.. wait.. hold up there buckaroo. You are *now* worried about concurrency of data? That was an expected "don't worry about" issue because of the way you and DK designed the system.
No matter how much I said "no no no this is out of the scope of the solution" she wheezed and coughed and I eventually decided I had more important things to do. No where else in the system do we address concurrency, but oh noes here we make our feeble stand on ONLY THIS FUCKING POINT.
God.. this just highlights how well she can "manage" a project.
Then DK in this morning's standup smelled the extra work and scope creep... sat there.. seethed for a bit... then decided he wasn't going to fight jefe for this. DK expressed concerns I mentioned above, and finally just demanded we have documentation because this will make the system a bit more unmanageable and folks maintaining it in the future will have zero idea why we did this because it was stupid.
FMJ.
Okay.. follow me on this one. We have similar data in two different databases. There is an instance where if a user creates a cost code in database A, doesn't click the "refresh" on the budget screen, and then the cost code list in database B doesn't know there is something new from database A. The users type the new cost code number on the fly in our budget screen. The system treats it as a new cost code on *that* side.. gives it a default type (the user over looked keeping it the same).. then saves. A synch process is kicked off, and the original type information in the database A is over written.. hell breaks loose.
Sticks is working on the fix. Wonderful. He "finds" the solution (though that was written by me in the work request), and I suggest the solution is if we save in the new cost code screen refresh the list of cost codes in the budget screen. Bam! Easy cheesey..
Except.. EXCEPT... jefe gets involved...
She decides my solution is wrong (sort of)... and then tacks on this whole bunch of crap because she is worried about multiple people in the same project on the same version doing changes. Ah.. wait.. hold up there buckaroo. You are *now* worried about concurrency of data? That was an expected "don't worry about" issue because of the way you and DK designed the system.
No matter how much I said "no no no this is out of the scope of the solution" she wheezed and coughed and I eventually decided I had more important things to do. No where else in the system do we address concurrency, but oh noes here we make our feeble stand on ONLY THIS FUCKING POINT.
God.. this just highlights how well she can "manage" a project.
Then DK in this morning's standup smelled the extra work and scope creep... sat there.. seethed for a bit... then decided he wasn't going to fight jefe for this. DK expressed concerns I mentioned above, and finally just demanded we have documentation because this will make the system a bit more unmanageable and folks maintaining it in the future will have zero idea why we did this because it was stupid.
FMJ.
Wangnet.org RSS Feed