Refuse single-used solutions

I can find a correlation between ecology rules and software development. The way we think and work, implements potential solutions for tough problems.

If we care about the environment, about people, we’d probably be more mindful at work. We’ll look for improvements and make our surrounding a better place.

Refuse (verb) – derived from Zero-waste philosophy – means to limit waste in your life – no matter if it’s about plastic waste or time waste in your project. By refusing unnecessary or harmful work – you can easily save time and came up with new brilliant ideas for development or testing.


When an eco – freak goes to the super market – he looks not only for good quality of food, but also for non-plastic containers to reuse them for something else in the future. I think that  the same rule should be applied in development. Single – used solutions in the code, in testing, unnecessary work done as a shortcut to satisfy our customer’s demands are the things that often kick people’s back in the future.

Once, I had a chance to take part in the project, where a rush was a day-to-day routine. I don’t think this is an unique situation in an IT world 😀 Anyway, in that project, our Project Manager never said no to the customer. In addition, the customer started to be greedy, because he was allowed to act this way. He wanted constant changes, “improvements”, made phone calls to my team members in the evenings and during the weekends, knowing that we don’t support the product in those hours.

You’d say – their fault – they shouldn’t have allowed the customer to do so. Agree, but there are some people on this planet, who have more difficulties to say NO than I do 😉

We ended up with massive over-hours, frustrated team and the unhappy customer changing his mind twice a day.

He paid for our time, sure he did, but we paid for that effort as well – with people. My friends quit the job and we don’t remember this work as something that we could be proud of. The development was not easy, but constant pressure and rush made it even harder. As the team wanted proper solutions and the Project Manager always kept saying “We don’t have a budget for it”, we were in constant fight.

Developers were forced to skip unit testing and any other kind of testing, so you can imagine the results. Constant hot-fixes in production.

For me, a single-used solution would be not only a shortcut in the code, but also each piece of documentation, test session, power point presentation or any other work done, that has had consumed your time. Valid time, that could have been dedicated for testing and improving quality of the product.

Today I am a bit more experienced than I was during the project, I’ve mentioned, so probably I would fight a bit stronger for my standard. Sadly, back then, I was not able to win every battle.

What’s the conclusion?

When a manager comes to you and asks for doing development fast instead of proper – remember that this is nothing else but a technical debt –
a single-used solution that you don’t want to have.

Discuss, propose, think, but when you agree on a shortcut – for example skipping performance testing or postponing some exploratory sessions due to lack of time – be aware of the consequences in the future. You’ll save some time now, but you’ll be in the real trouble soon.

I would always think of my application as something precious and brilliant, not a piece of trash. You should do so as well.

That’s why, today, I refuse single-used solutions. That’s why I always tend to refuse tasks that I reckon as unnecessary or harmful to my project and time use. I believe that our job is always to assess and discuss possible actions with the team and a manager and making wise choices. That’s why we have the ability to talk 🙂

Our quality duty is not to accept blindly each job we receive to do. For me – refusing means taking responsibility for the project and overall success.

In case of any comments – write down below or stalk me on Twitter.

Test team will help you out

Test Team

Hi Boys and Girls,

Being close to the test community at Test Warez Conference, on which I am at the moment, made me think about my team and how do we do things at New Voice Media.
I believe it is worth to spread and inspire you to introduce good practices into your test / scrum teams.

Next week I’ll provide you with wider summary of Test Warez – today I want to focus on one aspect that came to my mind yesterday during the discussion panel run by
Łukasz Pietrucha about planning your tests.

We’ve started with lightweight talk about ISTQB’ish approach to formal documentation and planning across organisations but end up with vivid discussion and sharing good practices and personal project-related experiences (not necessarily related to panel’s subject 🙂 ). It made me think that planning your tests and organising testing in your organisations, in general, is extremely context-related. You might think that one, structured, recommended by ISTQB idea should work, but sometimes, to be honest, it is just useless.

I went back to my roots as a software tester.

One of my very first sources of knowledge about software testing in general was Polish . It is technical, teaches you how to start with Selenium and gives updates about software testing in general – very thought through source of knowledge (For some reason I was convinced that it is run by a girl…. but never mind, just leave it 🙂 – sorry Wiktor! ).
Wiktor Żołnowski – the author – wrote a few words about himself on that blog. However, I’ve read it just a week or two ago. Wiktor wrote ‘It was ‘Agile’ – people and interactions over processes and tools. Then I’ve acknowledged that all things which I knew about testing ans so-called quality processes promoted by different organisations, had little value. Software can be crafted just better.‘ – and I consider it as a quote close to my heart. I still keep thinking about it, that’s why I decided to write today’s post.
Now, at New Voice Media, I can tell the same thing. There was always a missing part in my teams / projects/ organisations, even with their structured processes and diverse working environments, and I don’t speak about faking the agile style of work only – what I mean is – craftsmanship and team spirit (what a cliche).
It suites me better – it may not suit you at all, so don’t feel offended, Dear Reader 🙂


As some of you probably know, at New Voice Media we – the DevOps team – work  in Scrum or Scrumban. This is the first time, where I an able to see theory in practice and it works good for the organisation. We have testers and developers in our team, but we try to widen our responsibilities to enable all team members to learn and improve their skills.

Apart from separated feature teams – we also try to gather in community of interests, Sound ‘Spotify’ish’ 🙂 Maybe. On the other hand, it helps. We try to share knowledge across teams and locations (some of us work in Poland and some in the UK) to avoid silos of knowledge


– it means we meet, talk and help one another out. It also means, that when somebody gets sick, has some emergency or has too many tasks to do at once – other testers may (and will!) help. We use different communication tools, chatters, video conferences, Wiki spaces and so on, but first of all – WE WANT to share and WE WANT to learn. It is not the organisation, who makes us do it – it’s us who do it, because it just helps.

I am not sure if that would be an approach for entire corporation – but for small departments – maybe? Would it work in a software house? I don’t know – but at leas you may try it. I know at leas one software house, that has it’s own community of interests and it works great for them. 😉 When you feel the energy and willingness to do something – you can definitely progress at things.

You cannot build (good) your software alone these days, so it is good to have a team which would help you out. Just in case 🙂

As always, you can comment down below or stalk me on Twitter.