JTonz Jun 19, 2017
An often overlooked aspect of development is understanding the thoughts and opinions of other non-developer team members when completing a story, and importantly understanding what they quantify as being able to mark a task complete.
A recent addition to the average development team, the UI/UX designer is somebody who is often the victim of this lack of understanding; when under a looming deadline, team members that are not as involved with the look and feel of the site will often suggest that "near enough is close enough" for the visual aspects. The need to have the story marked as completed so they can get started on the next task will supersede the view of getting that slice of the system right the first time around.
For those whose whole career is based upon getting a website looking immaculate on each browser, device, and platform, having a button be 5 pixels out of alignment on a single device is akin to you as a developer writing a nasty set of class logic and having to pushed it to production. It works, it does its job, but every time you look at it, you wince; you hope when somebody finds it, particularly if it's your boss, that they don't assume you cut-corners or purposefully wrote lazy code.
Another frequent victim from lack of communication are testers; as an engineer it is easy to feel that testers are doing little more than nit-picky work where they point out every tiny flaw within your work. From the perspective of a tester however, their position within the team is to ensure that the completed task meets the criteria set by the product owner, not reporting bugs; this process is simply a byproduct.
When an API response is incorrect, it is acceptable for a tester to flag it as an issue, should it be treated differently than when the wrong shade of blue is put down on the background, or a button being 5 pixels out of alignment? As an engineer, the API not returning a valid response may seem like a far more significant issue than the background colour being incorrect; for some members of the team however, and even for the stakeholders, it may be the critical to the task, and for a tester, both issues are simply acceptance criteria not yet met.
Understanding your fellow team members, how they work, and what is important to them will lead to a conducive working environment where nobodies concerns are pushed out. Taking the time to understand why something that may seem trivial to you, is of a high priority to others, encourages collaboration within the team, and will generate the type of communication that ensures tasks are completed where all relevant parties are happy.