A Minor Tweak
Posted on July 11, 2008
Filed Under rants |
Just another day at work.
Reported a minor bug to a system (interface). Not even a bug, just a minor tweak. I can almost feel that it won’t be entertained before I reported it, but since it is such an eyesore to me, I went ahead and report it. Lo and behold! It was not entertained. <LOL>. It could have been done in 2 minutes, but it doesn’t. I guess an application in .NET is just that hard to modify (even though it doesn’t have anything to do with .NET).
Here’s what I see actions that will happen if the bug is entertained.
- The manager for the bug on the project will assign it to someone (2-3 minutes)
- The assigned will read up on the bug, open up VS, update the revision and find the file (10-15 minutes)
- Finished the bug, commit it into the repository and send a request to access the server to the Network & Server team (5-10 minutes)
- Update it. (5 minutes)
4 + 13 + 9 + 4 = roughly 30 minutes (30 minutes doens’t mean the time spent is continuous, maybe its spent 20 minutes today, 10 minutes tomorrow).
Ok, it might interfere with the assigned’s flow on whatever he’s doing but its tough, working with lots of people, lots of stuff happens around you.
The bug doesn’t even need to be tested. As you can see from the picture, its just a minor tweak. In my previous employment, my boss will be breathing down my neck to get it fix. Right now, right away! Because it doesn’t look good. And I have to agree with him.
This is just a rant, no hard feelings to anyone involved!
Comments
6 Responses to “A Minor Tweak”
Leave a Reply

How about if you help to rectify it? Since it’s HTML/CSS issue, you can download the HTML and CSS files into local drive and help. Or maybe just play with it in Firebug?
I have played it with firebug, hence the blue outline in the picture. Pointed out the table width is small, the radio button and the label is not aligned.
I would fix it, if it didn’t take twice the time it would take me to do it than the person already familiar with it. And I’m sure I would take more time than that.
For starters, no docs, I would have to come over to the person in-charge to ask where the SVN, and even if I could, it is under the care of someone. I can’t just download the source modify it and patch it. I’m sure the repository is password protected because mine is. I would have to inform to create an account to commit the patch. This excuses could go on and on and on..
Oh man..
I had done enough heroic deeds (few years back) that results me in death marching through the night.
Slm, I’m kind of the guy in charge for this. Just want to clarify it here as a self-defense, in case anybody cares
1st, one good reason to not to touch it is, this is a “temporary” app, done in a rush. It will be obsolete soon, so we figured we should invest our precious 20 min for the real app.
2nd, the problem is not caused by the TD, but the LABEL tag. A CSS is applied for all LABEL tags throughout the application, thus one change can affect all. There’s no such thing as “no need to be tested”.
And yes, you can put a style to override, but this particular one uses built-in ASP.NET control. ASP.NET controls are nifty and easy to use, but when it comes to customizing, it can be a pain. That’s why we will move to something more flexible for the real app (still ASP.NET tho).
The label actually renders differently in Firefox 2.0 (the version we have at that time), it only happens in IE7. So it’s a bit annoying that we can’t use Firebug. But FF 3.0 renders it same as IE, seems IE is the right one this time.
Pardon me for not clarifying enough in the bug tracker, my bad. But have a bit of faith to the guy doing the bug triage will ya..
And… What’s that mantra again “How hard can it
be”?
Ok, as you say the app will be absolete soon. Define soon. 2 months? 3 months? In these time frame, how many users will see it?
I am not very familiar with the demographics of the users but from my perspective and maybe others who are familiar with the internet nowadays will see it and think, “This looks terrible” and leave. Giving a bad impression.
Priority is business, severity is technical.
http://geekswithblogs.net/srkprasad/archive/2004/08/20/9961.aspx
In Triages, team will give the Priority of the fix based on the business perspective. They will check “How important is it to the business that we fix the bug?” In most of the times high Severity bug is becomes high Priority bug, but it is not always. There are some cases where high Severity bugs will be low Priority and low Severity bugs will be high Priority.
However I have reported things that I see which is an eyesore and might have an impact based on my very little experience. It is up to the bug manager and their team members to decide. If they do not want to fix it, then fine, I can live with that.
Yes, agree with you on lots of points:
* In most of the times high Severity bug is becomes high Priority bug (and low becomes low).
* It is up to the bug manager and their team members to decide (and there’s no need to resort to a public blog post).
I post this as a reminder for myself and others who might learn from it. Sharing is caring! LoL. However, I do try to tread carefully.