Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
A Dilbert's way on submitting enhancement requests (cubic-m.blogspot.com)
23 points by adib on April 2, 2011 | hide | past | favorite | 12 comments


| One of the things that I notice is that bugs that are raised usually gets fixed only if there is a business impact.

Isn't that a good thing? If you're running a business, it doesn't make a whole lot of sense to spend development effort on things that don't have a materially positive impact.

| As always work needs to be prioritized [...]

Yes, and typically, bugs that can be worked around or don't block anything have fairly low priority. Again, that seems like a good thing.

It seems very counterproductive (and borderline malignant) to engineer a strategy for manipulating the development team into fixing problems that, ostensibly, don't have much impact on the business.


> Isn't that a good thing?

For the business? Yes. For the user? ... No - not at all. For the user it means that minor tweaks allowing marketing to work smoothly take priority over actual bugs in the service. But guess which generates more customers?

The worst are the "not often found" bugs which don't impact the base service so they stay around forever. My "favourite" is Lloyds' internet banking which randomly skips a couple of days on exported .csv files. I think it was a "known issue" 1.5 years ago, making the feature useless really. Yet it's still there, there's no warning about it either.


Just like the bosses who get to put the bug fixes on their resume, now the author of this piece can put his efforts on his.

You aren't suggesting that he sacrifice his own self-interest for the sake of some company, are you?


Call me crazy, but I for one would prefer my resume to reflect my honesty and directness in the workplace, rather than my subtle skill of manipulation. But maybe that's just because I'm not a lawyer :)


Honestly, me too. But that's a personal sacrificial choice I'm making.

I just find it repugnant when people morally criticize the business activities of workers while simultaneously giving a HUGE SWEEPING pass to the management class in general.

As long as our society finds it accepted, expected, and encouraged for executives to be purely self-interested schemers, then it must be accepted, expected, and encouraged for other job descriptions in society to hold the same motivation.

Moral condemnation of one group of people, while giving a pass to another group, is awful. All it does is empower sociopaths.


What about non-critical bugs that, in the grand scheme of things, cost many man-hours on a regular basis to avoid or work around? In that case, it seems the investment of a handful of developer hours would be worthwhile, and yet still hard to push through.

Honestly, if your development team makes software for internal use and internal use only, isn't their primary function by definition to improve productivity of the rest of the company?


If your development team makes software for internal use and internal use only, isn't their primary function by definition to improve productivity of the rest of the company?

I think that needs a to be ammended to …to cost effectively improve productivity… That are lots of ways to spend X to save X/1000 500 times over. As an example…

While opening a new checking account for a new LLC I watched the poor banker enter my SSN 6 times[1]. Each time she went to a new "page" she had to enter the SSN which she had written on her desk blotter calendar. Then at the end the computer refused to open the account because it wanted an EIN instead of an SSN.[2]

There are at least three[3] problems there that slow down employees, annoy them, and led to compromised customer security. None of them are show stoppers or direct money losses and I doubt any will ever be fixed.

A wrinkle here is that it is banking software, and those handful of developer hours might also come with hundreds of hours of compliance, verification, and legal work.

[1] She typoed a digit the first time and actually hit another customer's SSN. That had to be about a 1/100 or less chance. Being a smallish town that caused confusing because it was a woman other than my wife.

[2] It was already after closing time by then, so they worked on it the next day and appeased the computer somehow. Probably an override code from someone able to take responsibility.

[3] Let's count…

• Application flow requires a SSN repeatedly to accomplish a simple task.

• Employees are writing down customer SSNs in visible locations on their desks. (If you'd ever needed to reset your online password with these guys you would faint now.)

• After seeing the SSN repeatedly it is only at the last stage that the application validates the SSN for the actual purpose of reporting tax information rather than its use as a database key.

• Bonus item: I couldn't see the screen, but she typed several times more characters than I gave her as information. That's just disrespectful of users.


I don't think you're contradicting humbledrone here, just pointing out that there are various ways to assess business impact. I suspect the OPs real complaint was that issues don't get fixed unless they have an immediate business impact. Otherwise, I think I'd agree with the observation that issues with no business impact aren't worth fixing from the company's standpoint.


I work for an investment bank that has a Singapore dev team that has a bit of a reputation for totally ignoring any bugs from the US. Our solution was to fly there, walk over to the guy that needed to fix a bug (that was open for a year), and not leave until it was fixed. After a year of conversing via email, this got the bug fixed in about 30 seconds! ("Oh yeah, that's implemented! Let me fire up the dev server for you!")

I think the problem is that the official internal language is English, but people outside the US and the UK are not necessarily as proficient in English as they are their native language. Combined with the fact that most people can't write comprehensibly, and there is a huge communication barrier.


That's a rather obnoxious way of forcing your own sense of priorities on others. Sounds like what's missing is a weekly sync up call between the devs and the product owners to review the issue queue and sort it in order of priority.


A lot of development work is aimed at streamlining people's work processes. These are not make-or-break issues, but the hours of wasted time add up when your UI forces you to navigate through multiple screens needlessly. In that sense there is always a business justification: you are increasing the efficiency of your employees on the job.


We call this "Tester Driven Development", feature requests via the bug tracking system :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: