12 Tips To Help You Communicate With Your Developers

This could be your developer!

I Don’t usually blog just to reproduce another thing I already saw, hense the slowness in new post. But I keep going back to this one.. It could be because I haven’t slept in two days or maybe I keep going back because it’s perfect…

The article was here: http://blogs.sitepoint.com/12-tips-for-better-developer-communication/
I’ll Feel bad for reprinting it all, but since it doesn’t exist anymore…. :

As an internet business owner you’ll need to face your developers, so basically you have to learn to compare on your email management like mailchimp vs aweber, the two best alternatives. You can also avail for a business loan that will surely helps a lot when it comes to your business (click for info). Yes, it’s scary — they probably look odd and speak a weird language. But you can’t avoid it. Here are my 12 tips to help you communicate with your development team.

1. Know Your Requirements…
How can you explain your requirements if you don’t know what they are? Developers are often faced with vague, wishy-washy briefs such as “it needs to be just like Facebook, only — er — like, different”.

A good developer will immediately begin to analyze your idea. They’ll ask questions. They’ll pose “what-if” scenarios. No one will expect you to have all the answers, but you should be able to discuss the majority of problems. If you can’t, you haven’t thought the project through. It’ll fail.

2. …and Document Them
Putting your requirements on paper may not be fun, but it’s necessary. Interface sketches and flowcharts will help you identify functionality, understand the technicalities and explain issues.

Consider hiring a systems analyst if you can’t do this yourself. They’ll ask identical questions, though. You can also use databases for your business as it makes it easier to maintain and share data. For more information visit Couchbase.

3. Don’t Use Pseudo Code
If you’re not a programmer, please, please don’t attempt to write pseudo code — it won’t help. You’ll almost certainly over-complicate the easy stuff and gloss over the complexities. Your developer will need to reverse engineer your ‘code’ to determine what you actually wanted to achieve.

Pseudo code is useful when developers discuss algorithms with each other. There are few other reasons to use it.

4. Agile Programming is Not an Excuse for Poor Planning
Don’t think that rapid, agile software development excuses requirements analysis. It may reduce some of the up-front planning, but you’ll still need to make just as many decisions — if not more.

5. Be Clear and Decisive
Programmers make thousands of decisions on your behalf. However, they will inevitably have questions during the development process and failing to providing a definitive answer will halt progress.

As good manager, you’ll take responsibility, make a prompt decision, stick with it, and face the consequences if it’s wrong. Bad managers are unavailable, avoid answering the question, seek opinions from 57 other (disinterested) colleagues, then blame the developer for delays or bad decisions.

6. Stay Ahead of Your Developers
Good programming teams will have a development plan — components and features will be implemented in order. Understand that plan and prepare accordingly:
know what decisions need to be made prior to implementation
prepare dummy data or test cases
organize the production of content, graphics, videos or other media.

7. Avoid Scope Changes
Changing scope can destroy a project and put a deadline at risk. You may have seen a cool feature elsewhere, but it doesn’t need to be implemented immediately.
By all means, have an informal discussion with your developer. State it’s something you’re considering for a later version — don’t distract them from the agreed tasks or demand immediate attention.

8. Don’t Assume Anything
One of the worst statements made by non-developers is: “Hey, we should implement feature X. It’s easy, right — it’ll only take a few hours.”
It might take a few minutes. It might take months. It might be impractical. It might be technically impossible. You don’t know — if you did, you wouldn’t require a developer to implement it for you.

9. Set Realistic Deadlines
Like anyone, developers work best when they have an agreed deadline. However, those deadlines should be set by the developer themselves or someone with programming abilities and in-depth technical knowledge of the system.  Setting an arbitrary or unrealistic deadline will result in a bug-ridden monstrosity which takes far longer to fix.

10. Alter Your Schedule When Necessary
Application development is complex. Development estimates are just that — estimates. Programmers will encounter unforeseen problems and changes to the project scope (no matter how hard you try to avoid them).

The schedule will inevitably change as the project progresses. Do not be afraid to modify the completion date accordingly.

11. Test Your Own Application
Don’t rely on your developers or other people to test your application. It’s your vision: test it yourself at every opportunity.

That said, be aware you may be running unfinished code and check progress against the development schedule. Don’t send emails ranting about feature Y not working when that code hasn’t been started.

12. Stay Involved and Keep Communicating
Most people lose interest in their own projects as time goes on. If you can’t remain enthusiastic, don’t expect it from others.

Contact your developers on a regular basis. You don’t necessarily need to organize formal progress meetings — just show your face and ask how things are going.

That said, avoid pestering them. Your project won’t be completed quicker if you call your developer every 10 minutes to ask “are we there yet?” Let your developer do their job.

Ok maybe that is all of it but it is awesome, and you should read all of Craig Buckler’s other stuff…

::Awaiting DMCA takedown notices::