I don’t like to hire people. I’m rehabbing my house, and I’m much happier doing the work myself. I put down the tile floor in the kitchen and installed all the cabinets. I refinished the woodwork and doors. I installed the overhead lighting. Rebuilt the back stairs and porch railing. Painted everything. Tore down a wall. (Yes, I’m cool, I know.)
I didn’t refinish the hardwood floors though, because they’re really old and I knew I’d sand a hole right into the basement if I tried to do it myself. I didn’t replace the plumbing, because I’d have burned the house down trying to sweat the copper joints with a propane torch. I didn’t replace the furnace because I’d have blown the house up screwing with the gas line. I could have read up on all that and watched videos on the internet, but I figured the expense of failure was greater than the expense of hiring an expert to do the job.
The same reality applied to our XML project. I could have read XML for Morons and tried to cobble together a DTD or schema from our content modeling results. It would have taken forever and the final product would have been pretty bad. (Yes, I’m lame, I know.) And while we had people who might have been able to tackle this task, they had to do the jobs they were hired for in the first place, and couldn’t exactly drop everything to work on this project. Thus, the vendor.
I’ve discovered some facts about dealing with vendors. The most important is that you need to have a working knowledge of what you’re hiring them for in order to know whether they know what they’re doing. So I did read the real-world equivalent of XML for Morons, and lots of other books and articles, and attended conferences and talked to people and on and on. I might not be able to do the programming, but I can at least explain what I want to someone who can. And I can evaluate whether they’re delivering what I asked for.
Another interesting thing about working with vendors is the working relationship you have with them. At first, I was under the impression that we were paying them to do exactly what we told them to do. This is a terrible idea! Assuming they do know what they’re doing and you trust them, you should always be willing to listen to their suggestions. Make a point of telling them that you expect them to suggest improvements to your plan. Remember, if you knew how to do this stuff, you wouldn’t have hired a vendor. Ideally, they know stuff you don’t and their input will improve the project.
The vendor we chose to turn our content model ideas into actual computer files did a great job challenging our assumptions and suggesting alternatives. We spent lots of time explaining what our products are, how they’re built, and how they’re used and reused. We went into excruciating detail and they listened and became proficient in all our weirdness. They didn’t try to repackage our ideas into a mold they were already familiar with. They were our partners in development. I’d say that’s the ideal working relationship with a vendor. They also bought us dinner whenever somebody was on-site, which is nice.
We had a different vendor working on the content management aspect of the project (which we’ll get to in later posts). I think the doubt started when we presented the project to them, and without blinking, they told us sure, no problem, we can do that. No questions, no comments, just a big hollow yes and let’s get the contract signed. It never felt like a partnership. We’d explain something, they’d go off somewhere, and later would present the solution. We laid out our assumptions and ideas, and they worked to meet the assumptions and implement the ideas. Problem: We Don’t Know How To Do This. So why weren’t they telling us our assumptions and ideas were anything from “slightly off” to “physically impossible”? They bent over backwards to make the software bend over backwards to do whatever crazy thing we asked them to do. We wanted to build an XML publishing system and ended up on our way to building The Homer. Doh!
Eventually we realized that it wasn’t working out, so we switched to another vendor and even hired some in-house programmers specifically for the project. They had to unravel the madness left by the previous vendor, but it all worked out for the most part. This was an expensive lesson though. And we’re still dealing with some of the consequences.
Filed under: XML |