There is one mistake software developers everywhere constantly make. And it has nothing to do with coding, or agile workflow, or system architecture.
The truly worst mistake that all software developers make is to make assumptions which lead to time-consuming and unnecessary miscommunications.
Improve your product development workflow by avoiding these common assumptions. After all, you know what they say happens when you assume…
1) Assuming All People Think the Same Way That You Do.
News flash, folks! Nobody can read your mind. No other developer, designer, or client is going to think about a process exactly the same way that you do. That’s why, when you’re making choices about how to approach a project, it’s important to communicate clearly your line of thinking. Make sure everyone is on the same page, and leave room for others to share their point of view. The point of collaborating is to mix up multiple thought processes to achieve an end result that no individual could have come up with on their own. But successful collaboration is only possible if everyone speaks, shares their opinion, and is open to conflicting responses.
2) Assuming That Everyone Prefers the Same Languages/Structure.
Especially when working with agile teams, it’s essential that lines of communication are open about the structure of both the software you create and how you go about the development processes. What may seem obvious to you in terms of product architecture may be a completely new concept to someone you are working with. The most important reminder is to over-communicate. Always explain, discuss, and clarify more than you think is necessary to get the job done. Otherwise, you’ll likely end up redoing work because everyone wasn’t on the same page.
3) Assuming That Everyone Has the Same Knowledge/Understanding of Development.
This is a particular dangerous assumption when working with the client or while facilitating beta testing. Not everyone lives and breathes coding every day. You’ll constantly be working with people with different levels of development literacy. A good rule of thumb is to ask open-ended questions to gauge a client’s understanding of basic processes and terminology. Let them tell you how much you need to explain or whether you can use common shorthand as you would when working with another engineer.
Remember—people never want to feel stupid. If you assume they know something that they don’t, they may play along and open the door for big miscommunications. On the other hand, if you start every conversation over-explaining—clarifying even the most basic terminology—you risk offending a client by being condescending. Create a positive, productive rapport with a friendly and open-ended approach.
4) Assuming That People Care as Much (or as little) as You Do About a Project.
Keep in mind that your clients or colleagues may be working on multiple projects at a time. Just because something is your passion project doesn’t mean everyone you’re working with feels the same way. Of course, all team members should be expected to meet reasonable deadlines and put their share of effort into a project. But everyone has their own priorities. You might be enthusiastic to put late-night hours into a project or work every weekend, but your fellow engineer with a wife and three kids might feel differently. Clarify expectations and set a reasonable schedule from the beginning of the project so that all team members know the requirements and can share their own limitations.
5) Assuming That Everyone is Working on Your Schedule.
It’s essential that developers and designers alike respect one another’s time by scheduling opportunities for collaboration in advance, giving all team members ample time to prepare. Even in a startup environment, it’s not fair to expect others to drop everything and provide immediate answers just because you’ve had a breakthrough in the middle of the night. Make sure everyone is on the same page about deadlines, meetings, and plans for upcoming sprints. The development process needs structure to account for everyone’s schedule.
6) Assuming that Tasks/Projects Will Be Easy or Take Little Time.
(HINT: Always overestimate!!!)
This is probably the worst of the worst mistakes software developers make. There is nothing more frustrating than missing a client deadline because you didn’t allow enough time for a project. When it comes to scheduling, the best practice is always to under-promise and over-deliver on deadlines. When you’re asked how long a particular task will take, never give the best case scenario answer. Always, always overestimate. After all, how often does the best case scenario actually happen?
In general, the best way to overcome the assumption problem is to constantly over communicate. Especially early on in a collaboration relationship, asked more questions than seem necessary, share more information than seems necessary, and be overly detailed in your planning processes. As time passes, relationships do become more casual and second nature. But until you’ve established a track record with colleagues and clients, save yourself a lot of headache and never, ever assume.