Our very own Steve Zehngut has a presentation up for consideration at SXSW Interactive this year and we’d love to have it chosen.

Steve’s presentation focuses on breaking down the communication barriers that can make working with a developer more difficult than it needs to be. The presentation will cover Interviewing Your Potential Developer, Planning & Project Managment, Using A Version Control System, and Bug Reporting. The session will give the audience a reality check on how to go about working with a developer to get a custom WordPress site (or any digital project) built on time and on budget.

Questions Answered

• What questions should I ask when interviewing a developer?
• What are the communication pitfalls that I should avoid?
• How can clients get involved in project management?
• What is version control and how does it benefit me?
• What is the best way to handle bug reporting?

So, help  Steve out. Click Here To Vote

The post Time To Pick For SXSW – How To Hire And Manage A Developer appeared first on Zeek Interactive.

While there is cognitive recognition of this by most of the clients we work with, this is not a concept that is quickly internalized. In the early phases of many projects, we find that even the most sophisticated and educated of clients find themselves distracted by the lure of pretty graphics way too early in the process. When bidding on projects this is particularly true. A heavy emphasis is placed on visual design and the critical  issues of function, how the site is built, special software requirements, and where and how the site will be hosted often take a back seat.

The most creative aspects of site design are often unable to be seen in the browser.

Creative design is subjective. Whether a site can handle a traffic spike created by a link from a highly influential website, like The Drudge Report is not. The design of the hosting services, the architecture of the content management system, and the way different pieces of software work together to insure that a site stays up and working can and should be as as creative as the visual design.

One of the mistakes we see a lot of clients make is basing the decision about what company should build their site on the look of the visuals in a portfolio. If impressive visual design is not backed up by equally impressive programming skills and system knowledge, your project may look good and not function in a way that supports your business objectives.

Design plays an important role in whether a site will be used properly by those who visit it, this is a fact. Great visual design makes a site simple to navigate and leads the visitor to the pages you want them to spend time on. But it is just one of the factors you should be considering when choosing your site developer.

Here are some other factors you should consider.

• When your developer describes your project, are they leading the technology brainstorming or merely reacting to features that you have requested?
• Are they using a home baked platform to build your website? If so, this may lock you in to working with that developer to make what would be minor changes with someone else.
• What open source platforms is your developer familiar with?
• How involved is your developer in the open source community?
• What kinds of “pet” projects is your developer working on?
• Is your developer showing you multiple possibilities to help achieve your goals?
• Is your developer sought out for their opinions?
• What associations is your developer actively taking part in?
• What conferences do they attend?

Feel free to add to our list in your comments.

The post There’s More To A Creative Website Than Pretty Graphics appeared first on Zeek Interactive.

Bug Reporting

Problems are going to occur. The way your developer handles problems is what sets good developers apart from bad ones. I have never found a website that was 100% bug free; not even the largest websites. Knowing this ahead of time may help you handle problems more rationally.

Do your best to keep emotion and drama out of the situation. When a problem arises, take a deep breath and count to 10. Most emergencies are usually resolved very quickly. What may seem like a major problem to you might actually be a minor technical problem that your developer can fix in 5 minutes.

Your bug reporting procedure should be established during the planning phase of your project. You and your developer should agree on how emergencies are handled as well as non-emergencies. You need to agree first on what constitutes an emergency. Typically on our projects, an emergency is when any part of the site is not accessible by the public. This happens when either a page fails to load or the server is acting slow for some reason. For all other situations, we have our clients submit a ticket to our project management system.

Developers do not like guesswork. When reporting a bug, don’t send an email to your developer with something like “My site isn’t working.” Lack of detail is very frustrating for you developer and the “hunting” time can cost you extra money.

Good bug reporting is an art form that can take some practice to master. To report a bug, you need to give as much detail as possible in a concise document.  Start by giving a brief description of the issue in plain English. Don’t try to analyze any technical issues.

Then, give the exact steps to reproduce the problem. Tell your developer exactly what you were doing at the time the problem occurred. Also, include your operating system, browser version and any virus or firewall software you might be running.

An easy way to send your system details to your developer is http://supportdetails.com. Our customer service people at Real Estate Shows use this site extensively. When a customer reports a problem, they have the customer send an email from that site.

VERY IMPORTANT! When reporting problems, make sure you specify the priority. Be realistic. Is this a mission critical problem? Can it wait a few days? A week? If you don’t regularly specify a priority, your developer should get into the habit of asking the priority.

If your site is inaccessible, check out http://downforeveryoneorjustme.com before contacting your developer. This site will let you know if the problem is limited to just you or if the public is experiencing it as well.

A Few Additional Tips

Brainstorming is a good thing, but there is a fine line between brainstorming and feature creep. As you see your project being built, your mental wheels will start to spin. You will be thinking of additional enhancements to these features. However, if you want them added in your current working phase, be prepared to revise your statement of work. There will be an impact on the schedule and/or budget.

Many developers speak in languages that sometimes I don’t even understand. You will hear them refer to technology using terms and acronyms that will make your head spin. And they will rattle them off like you are supposed to know exactly what they are referring to. When this happens, make Wikipedia and Google your friend. Jot down the terminology and look it up later.

Conclusion

The bottom line is that many of the horror stories that I hear could have been avoided with clear communication. While there are a few bad seeds, I believe that most developers are not maliciously screwing up projects. Several factors may have contributed to projects that went wrong. If you have a developer horror story, I encourage you to look back at what could have been done differently to avoid the problem(s). Learn from it so that you don’t fall into the same trap next time around.

The post How To Speak Geek, Part 4 – Bug Reporting appeared first on Zeek Interactive.

Version Control Is Critical

Version control is critical! In case you missed it, I will say it again. VERSION CONTROL IS CRITICAL!!!

So what the heck is it? Simply put, version control is a system that saves each iteration of your code. The code is stored in a central repository and all code changes pass through that central repository. Multiple developers are able to simultaneously work on the code and the system aggregates the changes. Version control also gives your developer an easy way to quickly “roll back” code to previous versions if something goes wrong. For a more detailed explanation, go to http://en.wikipedia.org/wiki/Version_control.

Your developer needs to implement a workflow where the code has to pass through version control as a way to push changes live to your server. We typically work on all code locally and then push it through version control to a live server. On larger projects, this workflow may include pushing to a staging server first and then to a live server. Either way, the code always passes through version control.

So why is all of this important to you? I am glad you asked. Your version control system protects you if your developer drops the ball. You will always have access to the latest version of the code. If your developer bails, you don’t have to hunt down your code or worse, start over from scratch. You should be able to simply grant access to a new developer.

Three popular version control systems are svn, git and Mercurial. At Zeek, we use git.

It is important that you have access to the code repository for your project. Your developer needs to grant you access if they are hosting the repository. Better yet, host it yourself so that there is no confusion down the road.

There are services that offer inexpensive version control hosting.

• Beanstalk (http://beanstalkapp.com) offers hosting for SVN and git.
• Bit Bucket (http://bitbucket.org) offers hosting for Mercurial hosting.
• Some sites offer free repositories, but your code will typically be public if you use a free system.

Note. If your developer does not currently use a version control system, insist on it. If they refuse to use a version control system, find a new developer.

Up next: Part 4 – Bug Reporting.

The post How To Speak Geek, Part 3 – Version Control appeared first on Zeek Interactive.

Planning

As the old adage goes, “Bad planning on your part doesn’t make it an emergency on mine.” This is exactly what your developer is thinking when you make last minute feature requests that were not in the original work scope.

Planning is about setting expectations. If expectations are spelled out up front, there should be no surprises. This is an ongoing process and expectations will need to be revised as you move forward. Your developer may lack the skills to proactively set expectations, but you can take on this responsibility. The developer will probably thank you for doing so.

The Statement Of Work

The most critical document you need for any size project is a Statement of Work (SOW). The SOW needs to contain a detailed description of the project, the milestones, a timeline and payment terms. Depending on the complexity of the project, your SOW may need to contain specific details about each feature and how that feature is supposed to operate. Include as many specifics as it takes so that little is left to interpretation later.

This is the time to address code ownership. Who owns the code that is generated as a result of the project? Different developers have different points of view on this subject so it is important establish this early. In my work for hire contracts, our clients own the iteration of the code that we develop for their site. This means that we are able to re-use our routines on other projects, but we cannot re-use an entire project elsewhere. If you want to own the code, then you will need to negotiate this in advance and the SOW is a perfect place to do this.

Take your time creating the SOW. Your developer should not write one line of code until this is finalized and agreed upon. When I create an SOW, it typically goes through several drafts. I will submit a draft to my client for their review and then they will make edits and submit it back and so on until we both agree that it is final. You can use Word, Pages or Google Docs for this process. Whatever software you use, make sure you use the “Track Changes” tool so that you can see the progression.

Once the SOW is complete, both parties need to sign a copy of it to signify that they agree. For larger projects, my SOWs get attached as an exhibit to the work for hire contract.

A couple of important notes:

• You can never over-plan! Good planning and documentation reduces the guesswork as your project gets developed. Anything you can do to cut down the margin for error will save you money in the long run.
• Always try to avoid doing anything as a rush. You are always asking for mistakes when rushing.

Project Management Site

Your developer should use a project management tool like Basecamp. This will allow you to track your deliverables and project schedule. The site needs to have a good commenting system so that your conversations around a particular task are centralized in one place.

DO NOT use email or instant messenger to track tasks! These conversations tend to get lost in the shuffle. I have found that important parts of the conversation get lost when someone accidentally forgets to cc the group.

The SOW should become a road map for your project management site. All of the deliverables from the SOW need to be converted to tasks on the site. This can be done by you or the developer. In addition to task tracking, your project management site should be used as a central place to post feature discussions, technical notes and design comps. Your project schedule and major milestones should also be tracked on the site.

At Zeek, we use a site called GoPlan. GoPlan is similar to BaseCamp, but we switched because it has a good bug tracking ticket system built in.

Take an active part in the project management, but be careful not to micro-manage your developer. And when possible, ask your developer to use a screen sharing site like GoToMeeting.com to explain when you don’t understand something their saying. So many communication issues can be solved if a little extra time is taken at those critical moments in the project.

Up next: Part 3 – Version Control

The post How To Speak Geek, Part 2 – Planning & Project Management appeared first on Zeek Interactive.

My session was appropriately scheduled as the last session of the day. The title was “How to Speak Geek – Communicating with a Developer.” The sessions leading up to mine were about WordPress techniques, creating meaningful content, and some primers on how to dive into code. My goal for the session was to give the audience a bit of a reality check on how to go about working with a developer to get a custom WordPress site (or any digital project) built. It was also well received, so I’m turning the content into a series of posts, broken into these parts:

Interviewing Your Potential Developer
Planning & Project Managment
Version Control
Bug Reporting

Much of what I am about to write refers to boutique developers. These are typically smaller shops or freelancers where you will be dealing with the same people that are working directly on your project. Larger firms will typically have a project manager that acts as your point of contact. The project manager is responsible for overseeing the schedule to make sure deliverables are met on time and on budget. However, even some larger firms are guilty of the problems I am about to describe.

I asked the audience to share some of the problems they may have encountered working with a developer in the past. The answers were thrown at me fast and furious. Here are some of the common threads that I jotted down:

• “My developer delivered something that was not exactly what I had in mind. I then had to pay them to change it to match my expectations.”
• “My developer missed the deadline.”
• “My developer has gone AWOL. They refuse to return my phone calls and emails.”
• “My developer does not communicate effectively.”
• “The costs are spiraling out of control with no end in site.”
• “My developer takes suggestions personally.”
• “I found out my developer was outsourcing my project to another resource. They felt dishonest.”
• “My developer does not understand my industry.”
• “My developer does not have the core competencies to complete every aspect of my project.”

While the audience had a good laugh at some of these responses, none of them surprised me. I have heard them all before. The good news is that many of these problems can be avoided up front with proper planning and a bit of leg work on your part (as the client).

Interviewing Your Potential Developer

Developers are a rare breed. At the risk of stereotyping, I have found that hardcore technical people are lousy business people. The best firms that I have worked with in the past have on board technical people as well as business people. Knowing this ahead of time should help you to communicate better with a developer. Be prepared to listen with a different ear. The developer may not offer up details about your future working relationship so ask a lot of questions. Here are some important questions that you should ask when interviewing a developer:

• What is your hourly rate?
• Will my project be billed as hourly or as a flat rate?
• Once my project launches, is there a maintenance fee?
• Where does my project rank with the other projects on your production schedule?
• Do you have the bandwidth to give my project the attention it deserves?
• What is your procedure when something goes wrong?
• What is your process for bug reporting and bug fixes?
• Are you using a project management system, like BaseCamp or GoPlan?
• Who will be my day-to-day point of contact within your firm?
• What kind of turn around time should I expect?
• What version control system are you using?

These questions are best handled in a face-to-face meeting if possible. If a face-to-face is not possible, conduct the interview on a conference call. Avoid handling the interview over email. When you are asking these questions, it is important not just to hear the developer’s answers. Listen to their tone of voice. Study their body language. Are they uncomfortable giving their answers or do they sound confident? Do they speak in “double talk” or do they seem like a straight shooter? This should give you an indication as to how they will handle themselves in a working relationship.

Make no mistake – if you hire a developer, you are entering into a relationship with this person. Take the time to find someone you can trust. If you need to interview a dozen developers until you find the right fit, do it! Finding the right person will save you a lot of headache and money in the long run.

Reality check moment. I am sorry to have to break the news to you, but no one will ever be as passionate about your project as you are. Most developers get off on creating cool technology. It’s a bonus if that can be married with cool content.

Feel free to post any additional questions you might have about interviewing a potential developer in the comments below. Part two in this four part series will cover planning and project management.

The post How To Speak Geek, Part 1 – Interviewing Your Potential Developer appeared first on Zeek Interactive.