{"id":457,"date":"2021-01-31T20:51:17","date_gmt":"2021-01-31T20:51:17","guid":{"rendered":"https:\/\/new1.blog.oqtacore.com\/?p=457"},"modified":"2022-11-23T12:05:27","modified_gmt":"2022-11-23T12:05:27","slug":"how-to-communicate-with-a-software-developer","status":"publish","type":"post","link":"https:\/\/oqtacore.com\/blog\/how-to-communicate-with-a-software-developer\/","title":{"rendered":"6 great tips to communicate with a software developer well"},"content":{"rendered":"

To communicate with a software developer is not a very useful, but not a common skill. Not everybody understands the specific of software development and can understand if the software developer is trying to trick you or does the best they can. When you are making your startup, you don’t have to only communicate with users<\/a>, but also with software developers.<\/span><\/p>\n

<\/span>Is it important to communicate with a software developer?<\/span><\/h2>\n

If you are ordering work from a software developer, or maybe a software development team, you need to follow some rules to achieve great results.<\/span><\/p>\n

These rules might seem too rough, but one always has to prepare for the worst to achieve the best outcomes.<\/span><\/p>\n

We at Oqtacore have tens of years of combined software development experience,\u00a0and know some things that might not have sense at the first glance, but after you get a feel of what software development is like, after you start communicating with other software developers and writing your own code, you will understand that every statement in this article is written in blood (metaphorically, of course! No real blood was used to write this article).<\/span><\/p>\n

Disclaimer: I have years of working as a developer for someone, and of work with developers as a customer. And since blaming a software developer usually means being a victim (which we try to avoid), the hints will usually mean “write better specs” or “don’t blame the developer”.<\/span><\/p>\n

<\/span>The software specification document always has flaws<\/span><\/span><\/h2>\n

It is unavoidable to have white spaces in your specification. You might think of everything in your UI design and implementation details, draw every screen with every minuscule detail, but then during implementation, you will understand that you forgot that your users can have very long names, and your well-thought design cannot accommodate them, and you have to redraw many screens on which you spent so much time.<\/span><\/p>\n

Or maybe you wanted to give users the ability to remove chats. Sounds easy, right? Just add a button that deletes the chat.\u00a0<\/span><\/p>\n

And then the developer comes back with annoying questions – is it possible at all for those users to reconnect? Will they see the previous history when reconnecting? Can they see the history of a deleted chat without reconnecting? How does the law work in your country for the data in the deleted chats? What happens if one of the users deletes their account?<\/span><\/p>\n

These are just examples of two small features. Usually, the issues are much more complex and happen between multiple modules. This is unavoidable and causes trouble during development.<\/span><\/p>\n

<\/span>Shit can happen even if the software developer did everything right<\/span><\/span><\/h2>\n

It is possible that you will find out somewhere in the middle of development that WebRTC technology used for video calls works great everywhere, except for iPhone, because of iOS 14 that came out 3 months after the start of the project. The developer correctly assessed the capabilities, but couldn’t expect such a change to happen.<\/span><\/p>\n

You always have to have time for plan B. Never celebrate too early. Some large products go down and hundreds of highly paid specialists lose their jobs because Instagram or Facebook close their APIs.<\/span><\/p>\n

<\/span>Multiply the developer’s deadline by 3<\/span><\/span><\/h2>\n

Yes, by 3. There is a lot of research on the internet. I recommend carefully reading this one<\/a>, for example<\/span><\/p>\n

Software Developers are not special people, but their work is very unpredictable in nature. A painter or a designer cannot have too many unpredictable situations, except for having electricity shutdown. But a software developer constantly hits different problems that are real and have zero relation to procrastination.<\/span><\/p>\n

How to deal with it:\u00a0<\/span><\/strong>always multiply the developer’s deadline by 3. You don’t have to pay triple but never rely on getting the result earlier to avoid trouble.<\/span><\/p>\n

\"communicate

A software developer can set a self-imposed deadline, but research shows that self-imposed deadlines are easily broken. When you communicate with the software developer, set a looser deadline, but do it on your own. It will force the developer to take it more seriously.<\/p><\/div>\n

<\/span>Try not to give a specific tech stack, but explain the needs<\/span><\/span><\/h2>\n

If you are not a professional software developer, I would recommend to keep from giving some specific tech stack ideas when you communicate with a software developer. Even when I start working with some technology that I don’t have hands-on experience with, I prefer listening to the developer.\u00a0<\/span><\/p>\n

The reason is that technology develops really quickly and it is impossible to catch up for a single person. Even we software developers have to admit that we can’t know everything and have to rely on someone else.\u00a0<\/span>How to deal with it:<\/span><\/strong>\u00a0you might have friends or colleagues that have used Angular, React, PHP, or some other technology. But if you do not have software development skills, I really recommend finding a good person by reviews or recommendations and then telling the needs and relying on the developer to find the right tech stack. Trust here is a very important factor.<\/span><\/p>\n

<\/span>If something takes too long and the developer really tries to do it, it’s not always their fault<\/span><\/span><\/h2>\n

This might be REALLY counter-intuitive, but as a CTO I know – if a developer does not manage to do something on time, only in half of cases it is related to bad attitude or laziness. Oftentimes the reason is that some technology really works badly for the occasion and requires a lot of additional effort, or changing the technology.\u00a0<\/span><\/p>\n

How to deal with it:<\/span><\/strong>\u00a0I would recommend paying by project instead of paying by time, at least for the first few months. This way the developer will have no motivation to break deadlines. After you get a feel of the developer’s speed and attitude, you can choose to continue with hourly or by-project payments.<\/span><\/p>\n

<\/span>Software Developer is not capable of improving your idea<\/span><\/span><\/h2>\n

When writing the spec, you might think that the developer might do some things without your explanation. You can think that wording “we also send voice messages” is enough, but in reality, the developer might have never used voice messages (they hate voice messages), and doesn’t even know how they should behave when being recorded. For example, that can be replayed before being sent. Or that the message should show audio length (it might be obvious for you, but not for a person that hates voice messages).<\/span><\/p>\n

This is a single example, but I can come up with dozens of similar examples. Usually, such misunderstandings are based on the fact that we keep in mind some software products that have similar functionality but fail to name them, and we expect the developer to just rip off the functionality that they have never seen.<\/span><\/p>\n

How to deal with it:<\/span><\/strong> I created a simple rule for me – the software developer gets you wrong always when this is possible. Try to make the specification document failure-proof. It is impossible, as perfection is unreachable, but it’s really worth trying. Try to communicate with a software developer as much as possible to make sure that your ideas are perceived correctly.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

To communicate with a software developer is not a very useful, but not a common skill. Not everybody understands the specific of software development and can understand if the software developer is trying to trick you or does the best they can. When you are making your startup, you don’t have to only communicate with […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_mo_disable_npp":"","yasr_overall_rating":0,"yasr_post_is_review":"","yasr_auto_insert_disabled":"","yasr_review_type":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-457","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"acf":{"image":467},"yasr_visitor_votes":{"number_of_votes":0,"sum_votes":0,"stars_attributes":{"read_only":false,"span_bottom":false}},"_links":{"self":[{"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/posts\/457","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/comments?post=457"}],"version-history":[{"count":10,"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/posts\/457\/revisions"}],"predecessor-version":[{"id":952,"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/posts\/457\/revisions\/952"}],"wp:attachment":[{"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/media?parent=457"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/categories?post=457"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/oqtacore.com\/blog\/wp-json\/wp\/v2\/tags?post=457"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}