Is that bug really important ?

Of course a bug is important and should be dealt with, shouldn't it ? Every bug is important and affects the global quality of a product.

Just one second... for whom is that bug important ? (And by the way, is it really a bug, or a user complaining about a product he doesn't understand ? More on this in a later post).

Bug are important, but that importance lays on different axis: the customer's, the manager's, the developer's, the marketer's (add your own).
To put things shortly, different interests will collide on how important that bug is.

And there will be a great confusion and a lot of tension around that issue shortly, repeatedly. Even the tools designed to help with bugs will not help most of the time: very few tools take this conflict of interest into account. To make things worse the default reporting value for a bug is by default "high". Guess what priority all bugs get.

This situation obviously ends up generating a lot of tensions all over. Developers are frustrated being told that a spelling mistake gets a high priority over a major refactoring which will not get done, while marketing is frantic about having corrupt data about the users, said users not understanding why it takes more than a month for a bug (simple, obvious !) to get fixed. And the management tries to fix things by spending longer hours in meetings and making everyone work longer hours "to get people to work right".

The real issue with handling known bugs is about setting the priorities right.

And that means at least to things: evaluating what the different priorities are for each axis, and balancing them. It's not an easy task.

Is that very abusive user being just... abusive ? Is that technical bug creating a crash, but for a very rare use case ? Is it slowly corrupting data in a non-recoverable way ? Is that bug a spelling mistake on welcome screen ? Is the bug reported by a check-signing customer ? And so on...

At the end of the day, a developer will have to fix the bug.
Being able to say for the assigners "hey, we know this is crap for you", and then, but "please fix it right now" really helps to get the developers going.

Avoiding bug reporting tools which do not allow you to use at least two different axis is a very good first step. Being able to say "hey this is futile", but, then,  "it's important for our paying users" will make developers laugh at first, that's for sure. it will introduce a very important concept to all though: there are different priorities, and those need to be evaluted.

It will also be a kind reminder to developer that software is meant for final users.
Things will get more easily done. And according to a consistent set of priorities understood and agreed by all.

Platform sizing 101

Today at work introducing a new database and application server were on the menu.

This was happening totally against my better judgement, but, somewhere, somehow, I came across an article on management which said "get things done, don't fuss too much how", and it's indeed probably a better way: we are getting things done in the spirit I had, let's just don't mind about the fussy details, things are evolving, and we're avoiding speeding up against a wall.
Enough about politics, to the real stuff now.

Sizing. We have n users. The literature around, I was told, says that the application server can handle n/2 users. Straightforward answer: we need two instances. Right. Wrong ?

Yes, that's the wrong answer. We care about user experience: if one server dies, or, more mundanely, one server is off for an update, the whole load goes to... well, that one server which can actually handle n/2 users. Oops.

Right, there's one way management likes, but users (and workers don't): take your service off and work at odd hours.

Or just setup three servers.

And there's a goodie along the way of that alternative scenario: when your load increases, you get more time to add another one before user experience deteriorates.