"5 hours a day" keeps pressure away

A common question raised by customer-side management:

• How to control software engineers? 
• How I, as a customer who pays huge bags of cash per hour to this hippies, can really know that they are not cheating me watching youtube half a day?

But even if the question is not asked explicitly, does not mean nobody has doubts alike. 

I worked in various environments. Let me review the most common solutions and their pros and cons.

Tester's mental "try ... catch"

Once this blog post http://www.inspiredtester.com/inspired-tester-blog/process-metrics-and-the-impact-of-context (and maybe a little bit of Jerry Weinberg's ideas) inspired me to this thoughts.




People like their "status Quo". They don't like to act. Every their action is forced by change. The change may be in outside, in circumstances; and it may be in themself. Changing the way one acts too is a reaction to different changes one experiences.

Applying this to the Software Testing, an experienced user becomes a tester, when they react not directly to external changes, but to the internal feelings induced by external changes. Establishing some kind of "try - catch" block for distractions in their brain. Instead of (or additionally to) just shouting out loud that "This piece of software does not work!", the tester asks themself: "What causes my such a reaction?" and puts the answer to the Bug Report title.

Agility of "agile"

As for me, currently a "new renaissance" of Agile (with capital "A") followers is going on. With their not getting the spirit of agile manifesto, but just following "best" practices and rules from some guide books, not regarding the reality, context and consequences of their deeds. (It may be connected to the new generation of IT employees stepping on the scene.)

That's why it's great that there appear new posts on this subject, trying to educate people about the difference between "agile" and "Agile".

Here is a post I liked recently from Yegor Bugayenko: 12 Mistakes in Agile Manifesto.

Гнучкість "гнучкості"

Мені здається, зараз відбувається якесь "нове відродження" адептів Agile (з великої літери) - людей, що не розуміють дух agile manifesto, а лише намагаються слідувати книжковим правилам без огляду на дійсність та результати своїх дій. (Це може бути пов’язано із черговою великою хвилею "нових айтішників".)

І от як раз нагодився текст Єгора Бугаєнка: 12 помилок Agile маніфеста (12 Mistakes in Agile Manifesto).

В житті цих помилок, звісно ж, не 12, бо кожен із постулатів Agile Маніфеста може мати безліч неправильних інтерпретацій :-)

Питання на співбесіду

Приймаючи участь у співбесідах, я рідко дотримуюся свого плану, адже, на мою думку, співбесіда має лишатися "спів-" - тобто взаємною - "бесідою" - тобто діалогом рівних людей, що мають якісь спільні інтереси. Найбільше мене тішить, коли на співбесіді я дізнаюся про щось нове й цікаве.

Ось мій особистий список того, що я хочу дізнатися у кандидата, безвідносно його професійного рівня. Просто відповіді провідного "сіньора" будуть більш фундаментальними та розлогими, а молодшого "джуніора" - короткими, наприклад "Не знаю." :-)

"Done" for everyone!

Probably each of us had that dialogue with a developer:

- How is your task? Is it okay?

- Yeah! It's done!

- Where can I test it?

- No, it's not yet covered with unit tests / not passed code review / the last commit is almost there.

(Google points here for this picture: https://hoangluongsjsu.wordpress.com/ )

What is missing here is not exactly "Definition of "Done"", but a substitution of different levels of "Done":

- Personal "Done": "I can do nothing more about it", the task is handed over to another team member."

- Team's "Done": "We have done all we could do internally. Now we can demonstrate the results to a wider audience, but we are still open for changes and suggestions in case of interference with some other team."

- Project's "Done": "We ship it! All your claims and change requests you should send to our legal department."

Working with agile Scrum-like process which states team commitment, we should always put the Team's "Done" to tasks' Acceptance Criteria.

Because putting personal commitments to a task description looks like avoiding responsibility for possible future changes in its scope due to integration issues.

But putting project oriented goals is even worse as they are likely not to be testable at the point, when a particular task is done. That leads to "requirements inflation", when the "key project points" are written everywhere and at the same time are not met anywhere.

Watch your requirements. And keep your task descriptions clear and testable.

Мої просрані релізи

За останні кілька років я брав участь у не менше ніж 100 випусках нового коду у світ. Більшість разів усе було чотко, але реальність іноді  дарувала нам сюрпризи, і зовсім не завжди вони були пов'язані із спеціально навченими індійськими спеціалістами баз і консолей.
Прошу до вашої уваги 3 випадки, що завжди спадають мені на думку при словах "Fucked up release".