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.