Our success is our measure.

Since a few days our bugbashing servers were failing. Being a full-fledged professional company we decided to approach this problem from different directions, namely:

• We only removed pesky testers who intentionally subverted our bashing. Bad users! How dare you use our application in this way! It does not matter if the application allows you to crash the server, you should not do it.
• We tracked down and removed automated tests - only 100% organic, real free-range users can bugbash our application!
• We added a few things here and there to closely monitor our brave bashists if they do it properly, without overloading the system. Of course this logging slowed application a bit, but in a few months we'll remove the loggers and our app will receive a speed boost.
• Finally, after we discovered the number of users our app can support we manned those positions with appropriate personel of pure hearts and no vile intent, and ordered them to bash.

Having followed the instructions above we managed to accomplish the bugbashing successfully, which we promptly announced. Soon after the success acquired many parents and emails with congratulations from the above came, as the success has many parents. After all, this is the success of all of us, and it reflects the quality and dedication of our work.

How to anticipate unexpected.

Every year is a good year here: my company presents its product on an international fair receiving A+ notes from prospective buyers. And every year we face the same situation: an unexpected blocker occurs, and the fair is either comming in a few hours/days or it is already happening. How do we fix that?
    There is a way: expect blockers around time fair occurs. Strangely enough it seems to work. One could see a simpler solution, but we are not the primitive ones to reach for the low hanging fruit of preparing a fair installation with a suitable advance to click through multiple presentation scenarios.
    However, this year is different: an installation was created as late as always and some dangerous settings were changed by people who would not touch them if they knew what the settings do in the 1st place. Thanks to that cummulation of circumstances all the extras that our presenters wanted to show crashed miserably way before it used to, leaving them with nobody to blame but themselves and nothing to show but our actual, not-so-flashy application.
    This year is a better year: our application will show little to no errors on the fair, and it's thanks to our dear presenters who dared to go where no sould has gone before and change what no man should change. It is thanks to their bravery that our devs do not have to work overtime this week. I applaud you wherever you are.

How to put out fires.

Devs were restless lately. I sometimes feel like a gravekeeper in a spooky movie: devs sit around behind their desks perfectly calm, but I know that they are stirring inside and they can raise any time. I think that their rumblings, supported by a few resignations, have reached some top management, because the latter dacided to pay us a visit to answer questions and calm people down.
    The Q&A session was awesome. Remember your school? If they ask you about an elephant, but all you know is about earthworm start with "elephant's trunk is a lot like an earthworm". The same was here. I guess that devs noticed the deception... but our guests noticed them being noticed and engaged us in an integrative meal to soothe the wounds. After all, nothing soothes a hurt soul better that ye olde frogetMeNow liquid. Finally: the next day our guests could not arrive to work. What a sacrifice.
    So, what's the recipe to calm disappointed staff? The following, it seems:

1. Come to answer questions head on, feel free to misinterpret questions at your will.
2. When 1. is not enough, organize plenty of food.
3. If 2. happens, feel free to skip the work next day.

    Today another guy resigned, so the recipe may need polishing.

A silver lining, there is one in our closet, next to a skeleton.

So a few days ago our company held a bugbash. The system is developed since 6 years. And the bugbash lasted 15 minutes or so. The server could not handle 30 users load.
     What I found interesting is the aftermatch of this event - a bug was created. There was a lot of hate in it. Devs be disappointed about their work being hindered by a lumbering framework we use. And then there are replies from our internal framework dev team. Jolly good ones. Just imagine the star contrast betweed a comment from a dev stating that it is outrageous that an application cannot handle 30 users load, followed by a reply stating that, well, yes, it could not handle it, but thanks to the new networking (some IT technology) stack the server survived a few watch dog (a thing that stops other things if they take too long) interruptions. Or the fact that the bug issued for this problem is only in scope of analyzing it's cause, not actually fixing it. Yup... the bug is a blocker, and fixing may take a lot of time. Using this leeway one can close the bug early.
    To me it looks like the framework team expected this much of an outcome. I am fascinated with the size of the skeleton discovered in their closed. I am enamoured by the way they found a silver lining in our application being useless. I am curious how I will be surprised next time.

Edit: the next week we held another bugbash. Long story short: the application has shown a huge improvement lasting about 15 minutes.