Outsourcing or hire new programmers?

John Gonzales

When it comes time that you need extra programming staff, what are your experiences with outsourcing or hiring additional programmers? One of my biggest concerns about outsourcing are receiving compiled code that we can't easily modify or troubleshoot on site. Of course hiring additional programmers tends to come with large overhead as they relate to personnel expenses. I'm curious what others do when you need extra programming help, and do all/most independent programmers tend to send compiled code and not actual .axs/source code? I know there are many independent programmers here in addition to dealers, so I look forward to everyone's comments.
Thanks!

-- John

ipssheldon

Independents can be a good fit

I think that depends on who you hire as an independent. Anyone that hires an indpendent programmer should confirm with that person or company that they will send you their source code. I, for one, regularly provide my source code to the installing dealer, sometimes while the project is on-going (i.e. before I get paid). I feel that I am an extension of the dealer's in-house staff and therefore, the code belongs to the dealer. There is a risk on my part that the dealer will take my code and install it elsewhere without my involvement, but I feel that if I am providing a quality service to that dealer, then he will come back for repeat business. If he only wants me to write a program so that he can take it and run with it, then he's probably not the kind of customer that I want to do business with any way. I build relationships with my dealers so that it is win-win. In that way, they have no concerns about the source code and I have no concerns in giving it to them. However, I do know that there are independents who don't work that way.

The benefit to out-sourcing is that you may find that one month you are overwhelmed and need the extra staff. But other months you may not. If you hire someone in-house, can you always keep them busy as your business grows or do they end up filling time in between projects. If you have enough programming to keep someone busy full-time, then it probably would make more sense to hire the extra staff. But even then, if you are growing that fast, will that programmer be up to speed on day 1? And even if he is, how much time will it take as you continue growing before he is also overwhelmed. Independents can fill in the gaps between these different scenarios without over-burdening your in-house personnel, so they can do what they are good at.

Independents also have the benefit of amassing libraries of modules that we can use over and over again, while an in-house programmer may not have as extensive a background. Since I write code for both AMX and their friendly competitor, I regularly will move code from one to the other. In that way, I know how a device will work even before AMX releases their own block of code, in some cases. Will an in-house programmer have that same experience?

There certainly is no single right approach. You need to consider what fits your business module best and the types of installations that you are likely to provide. Good luck with whichever approach you follow.

Just my two cents as an independent.

Sheldon Samuels
IPS Resources LLC
www.ipsresources.com

DHawthorne

I've only been in that position once, and I outsourced the job. It had some serious issues, that I had to tell the company we hired how to fix. It looked very much to me that all they did was plug in AMX provided modules, including the uI modules ... their big mistake, however, was zero-ing out unused feedback channels. Zero is still a channel, so the master was getting absolutley flooded with updates to channel zero, in mainline; for example, the on state and off state were both set to zero and did not actually exist on the panel, yet every pass to mainline sent an on and off to that channel, because whatever state the receiver was in, it got set one way, but the opposite feedback was being sent to the same channel - off then on, every pass of mainline. It brought the home network down, it was so bad.

It has a raft of niggly little issues to this day, and they will not release the source, so I'm looking at re-wiriting the entire thing. I'll not go that route again. At least I got a very slick panel design out of the deal. They couldn't protect that; I won't viloate the license by re-using the design, but I can continue to use it for this customer, so I don't feel what we paid them was a complete waste.

Thomas Hayes

I out sourced 1 project mainly because I couldn't keep up with everything that I had to do. Lucky for me he is one of the best AMX/other programmers in the field and only lives a few hours away from here. This same project had been on going for several years with different programmers that would take it to the next level but never quite finished it. I finally took it over and finished most of the remaining programming and had the out sourced programmer get the video conf system program side of it up and working. With that said, my work duties now concern AMX more and less of everything else.

pdabrowski

DHawthorne wrote:

their big mistake, however, was zero-ing out unused feedback channels.

and those of us who have visited the dark side know exactly where this programming method came from

ipssheldon

I imagine that anyone who has a bad experience will keep that bad taste in their mouth for quite some time. But I would ask that you be careful not to black ball a segment of our industry or to lump all independents together because of one bad installation. That's like saying that you aren't going to let a mechanic work on your car because one mechanic left a gasket loose or that you'll never let anyone else paint your house because the last painter that you hired broke a lamp or spilled some paint. While anyone can have a bad experience with any sub-contractor that you might hire, there are probably hundreds of very successful independent programmers out there for both AMX and ohters that provide very polished products on a daily basis. There are very good and some not so good contractors in every segment of our industry or any industry.

Would you want a home owner that got a bad taste from one of your competitors to tell all of his or her friends to never hire an AV contractor because they are all horrible to work with? If they did, we'd all be out of work.

I would wager a guess that for everyone who might post a message about a bad experience from out-sourcing, others could, if they were brave enough, post just as many stories about problems caused by their own in-house programmers that were simply inexperienced and ended up walking out before a project was completed and that some or all of those same companies found that out-sourcing with experienced independents has worked out very well.

Hiring people (whether in-house or not) is probably one of the toughest part of any companies efforts, especially for smaller companies, like many AV shops. You simply need to find what fits your business model best and then find the right people or person and back it up with a clear contract.

Just my thoughts.

Sheldon Samuels
IPS Resources LLC

champ

You should make a contract which is very particular with the exact extent of providing source code, and charge accordingly.

Using in house programmers you can get away with pointing in the direction of the job and saying "just make it work" because they have a fair idea of what the company usually provides for customers and you can send them back any time you want to make changes. When outsourcing you must provide the programmer with a much more detailed scope than in house because that's all they will do and you cannot guarantee they will be available to return a month later when something goes wrong.

The programmer cannot provide every line of source code if they have used third party compiled modules.
Generally I would suggest source code consists of the code that ties it all together and not the device modules.

If the programmer is forced to provide source code and is worried about the customer using it in other installs then there are things that can be done to make it difficult for them like removing all comments and using cryptic variable names.

Registration codes can be used (as AMX does) which can be removed (because the source is provided) but the customer has to know a little programming to do it themselves.

A programmer can also make code that will only work on one master.

If this doesn't sound fair then put it in the contract and remember that this is business.

John Gonzales

These are some important viewpoints that are being brought up. I appreciate the feedback. Personally, I view receiving compiled code without the source as inefficient. Inevitably during installation there are going to be changes that need to be made on-site based on customer preferences, and the way the client likes to use things. It's nice to be able to take a few minutes to knock it out and test it right then and there. Plus if there's any troubleshooting or even something as simple as a configuration/input change it seems like that would be more difficult as well. In the situations where you needed to troubleshoot with an outsourced programmer, how has that worked out?

Sheldon - your points are well taken, and your philosophy is respectable as well. We like to take projects on a similar basis, where you're comfortable with the client and there's a mutual trust. Fortunately, we've been in a position where we've been able to pick and choose our clients. I'm quick to walk away from those potential clients that you just don't feel right about.

champ wrote:

When outsourcing you must provide the programmer with a much more detailed scope than in house ...

Also a good point. One thing I've found when you team up with other companies that do the same thing you do, is that it forces you to be very efficient and detailed when you're working with them. If there's a lot of sloppiness in the operation it makes things very difficult for the other people to do their job well. Plus everyone has a different way of doing things. It's always a good reality check when you work with others, because it gives you an idea of how efficient your operations are (or aren't).

--John