

A Dilbert's way on submitting enhancement requests - adib
http://cubic-m.blogspot.com/2009/09/dilbert-way-on-submitting-enhancement.html

======
humbledrone
| _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.

~~~
sliverstorm
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?

~~~
jws
_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.

------
jrockway
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.

------
snorkel
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.

------
atlantic
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.

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

