Couple of days ago I have unpleasant situation which I would like to
share here. But first let me briefly describe context. I work with
application that is developed since 2014, in
git shortlog there are
plenty of dev names. It is quite mature application, it has good and
bad piece of code. Well known flow based on pull request is used there
from the beginning and every change need to pass peer review
process. Seems natural. Couple days ago small pull request with not so
big change was created by other team member (not working with this app
often). The change was simple: add one new field to class responsible
to serialize object, so called serializer. Pull request was short, one
line added into
UserSerializer, unit test was also adjusted. Process
of getting approvals was quick and smooth. Then merge and deploy to
staging environment … and API response doesn’t include new
field. What did go wrong? It was not cached response. It was not
failed staging deploy. It is much, much simpler. Developer changed bad
class and didn’t check locally if new field is included in API
Such situation makes me wonder if developer still focus on his
assignment or just wanted to code something and deploy it. Like
& forget. I understand that this change might look like simple and
easy trivial task, but like reality shows there is still space for
mistake. Better to minimize it as soon as possible. There is also
other side of the coin. I, as developer, would be ashamed passing
something that does not work at all or has some obvious mistakes. Such
things also doesn’t build up trust between developers, testers and
team member overall.
Such disregarding even small tasks can have big negative impact and generate waste. Because developer didn’t check his change on local development environment:
- he had to do this work for the second time
- he had to do work that was not planned (revert first change)
- there was two pull requests and other devs need to check it
- there was second deploy
As you see there is many waste in such small shortcut like don’t testing change on locale development environment.
There is couple of things that can be done to avoid such miss understandings.
- If it is hard to start app under development you can place detailed
READMEfile describing how to start application, what are requirement etc. I can also go more fashionable way and use docker compose
- Described failure could be noticed during peer review process. But small without clear description what author wanted to achieve it is hard to judge if this change is good enough to pass review process.
- Run your code locally. I mean not only test suite. Just use your change before you pass it to review or to quality assurance.
So simple steps can make big impact an your work. Yet still so many teams and project does not follow them.