How to Work with Developers
Background and Audience
I am a developer by trade. I do lots of work on the web with things like PHP and MySQL. Through a random act of chance, I am also one of the backend developers for the design portal site Newstoday. Specifically, I wrote the code that powers the PV-AN discussion board. The rest of the (excellent) code was provided by Mike Buzzard. I donate code and time to the development of this site because I'm fascinated by graphic design and its culture. This article was not solicited by Newstoday or the Quorporation.
This article is intended primarily for graphic designers who happen to be the types that typically read sites such as Newstoday. The reason that I'm writing it is that writing the PV-AN was one of the best little projects I've ever done, thanks in no small part to the ways that I interacted with the folks at the Quorporation (who will be referred to from here on as the QBN.) They did an excellent job in terms of getting me the information I needed, and that made my job really quite easy. I started coding on a Friday afternoon and the board was in Beta by Monday morning. As I recall, it went live on Wednesday, so the whole cycle was less than a week of development.
What I am aiming to do here is to try and explain what they did right, so that you can work in a similar way with your developers, and thus get some good work done with less effort.
Point One: Similar Applications
The first thing that the QBN did of course was to get me on the phone (I'm in LA, they were in NY at the time) and talk me through what they were looking for. But they did something else that a lot of designers forget about. They pointed me to another application currently working on the web with similar functionality.
So why is this so useful for us developers? It's because if we can see something that approximates what we're shooting for then we can quickly get some idea of how much work / effort / code is going to be required. It does NOT matter whether or not the similar thing you show us was written in the same language that we'll be using. Nor does it matter if we can see any of the code that is being used for the similar thing. For example, the thing they showed me was, as far as I could tell, written completely in actionscript using Flash. This is a radically different environment than the LAMP platform I had at my disposal. But it made sure we were on the same page regarding the scope of the project.
At this point you may be saying, "but what I want to do is so original that there's nothing quite like it out there." Fine. Good for you. Then what you should do is look for other applications that contain pieces of the functionality you're shooting for and show those to your developer. Anything helps here. If there's really nothing that foots even part of the bill, then fair enough. But half an hour of looking around on your part might save your developer two days, so I'd recommend doing it.
The issue of "the scope of the application" means a great deal to us in terms of how we set up things like data structures and database tables. If we don't get it right at the beginning then we waste a lot of time later on rewriting things. Help us out here.
Point Two: ALL of the Comps
Before the QBN ever even picked up the phone to talk to me, they had done all of the comps for the new application and had coded those comps into working HTML.
Let me restate that. They had done ALL of the comps, and had created ALL of the pages I was going to be working with as functional HTML.
I am making a big deal out of this because on the whole, designers do a lousy job at this particular thing. Typically, this manifests itself when there's some form that needs to be filled out and submitted. The designer comps and codes the page where the form lives, but NOT the page that the form gets submitted to. The designer usually forgets the page that comes up if the user hits "Cancel" also.
This is actually a really big deal. Forms are harder for a designer to comp and code than the "Thanks for submitting your data" page. However, in general, the bulk of the programming application code that we create goes on that second page. That's where we spend all of our time.
If that page is missing, then generally the developer will try and design a page that's whatever he or she thinks you wanted. I'm not even going to go into the purely aesthetic problems that can arise here. In the best case scenario, the developer does in fact think (functionally speaking) of everything you were hoping for and does the programming for the page. You see it and are of course appalled. After you fix the "design" for the page that the developer created, he has to take all his code and put it into your new page. This is an enormous time waster. In a worse case scenario, the developer has overlooked or didn't understand something that you wanted to happen. In this case, you have to design a mock up page for him and then he has to write new code to go on it. This is an even bigger time waster.
Every time the user has anything to click on, whether it be a link, button, image or whatever, the web site is going to do something. You need to know what that something is. If it requires a new page of some kind, then you need to design that page and code it into clean, easy to read HTML before the developer has to start working on it. Make sure that the developer does not have to spend time cleaning up your HTML or javascript. This will break his programming stride and slow him down.
If you do this correctly then you should be able to create a mock up of your entire application. Meaning that you can click everwhere the user will be able to, and the appropriate pages come up with dummy data. This is exactly what the QBN folks did, and it made my life really easy because I could see exactly what they wanted. Always remember that most delays occur as a result of the developer not understanding what you were trying to do, not his inability to write the code to make a certain thing happen.
Point Three: The Feedback Loop
After about two good days of coding, I sent the QBN a URL for the functioning beta. But note that it was still a beta at this point. There were still several issues that needed to be addressed before we could take the application live, and those were issues that I was going to have to deal with in PHP.
The important thing that happened at this point was that I got feedback immediately, meaning within a few hours. This is very different than two days later, or even the next day.
As a developer, when you are in the midst of writing an application, you are typically keeping track of an incredible number of interrelated things. There are variables and function names and database schemas and any number of other things swimming around in our heads. If we stop thinking about all of these things actively for two days then there's a substantial amount of startup time that we have to go through when we start back in just to figure out where we are. Again, this is wasted time.
On that first day of beta testing, we spent about half an hour on the phone actively tying down loose ends and cleaning things up. If they had waited two days to talk to me, that half hour might have taken me an entire day. The point is, you need to be available to your developer when he has things to show you. Asking him, "when do you need me to look at something" is absolutely fair game, but be sure you're there when he calls for you.
Point Four: The Big Thanks
Last but not least is the way the QBN folks treated me once things were done. Suffice to say that they showed me a tremendous amount of respect both as a person and as a programmer. This means more to geeks than you might think.
You are (probably) a designer. Your job is to make creative and beautiful images that are used in a functional way for something. Joe Average can see those images, identify with them at least somewhat, and say, "Hey, that looks cool. Nice job."
The job of a developer is much less sexy. We type for a living. Joe Average can't relate to what we're doing at all. In fact, he probably just thinks of us as "those guys who make stuff work." You would be amazed how rarely we hear "nice job," much less, "Hey, you rock. Thank you so much for doing such good work on this." As a result, respect from our peers is a very big deal to us. A developer who feels like you respect what he's doing for you is going to work a lot harder than one who isn't sure.
In Conclusion
To wrap things up, here's a short test you can give yourself to see if your new super project is ready for your developer to take a crack at it.
- Have you found any similar application(s) that he can look at to get his bearings?
- Can you clearly describe the functionality that you are looking for?
- Have you comped and coded ALL of the pages that he is going to need to touch?
- Are you available to provide feedback when your developer asks for it?
If the answer to all of these questions is yes, then hopefully you are in good shape. And be sure to let your programming allstar know that he's an important part of what you're trying to get done. Best of luck.