Ask Slashdot: How To Work On Source Code Without Having the Source Code?
occamboy writes: Perhaps the ultimate conundrum!
I've taken over a software project in an extremely specialized area that needs remediation in months, so it'll be tough to build an internal team quickly enough. The good news is that there are outside software engineering groups that have exactly the right experience and good reputations. The bad news is that my management is worried about letting source code out of the building. Seems to me that unless I convince the suits otherwise, my options are to:
1) have all contractors work on our premises — a pain for everyone, and they might not want to do it at all
2) have them remote in to virtual desktops running on our premises — much of our software is sub-millisecond-response real-time systems on headless hardware, so they'll need to at least run executables locally, and giving access to executables but not sources seems like it will have challenges. And if the desktop environment goes down, more than a dozen people are frozen waiting for a fix. Also, I'd imagine that if a remote person really wanted the sources, they could video the sources as they scrolls by.
I'll bet there are n better ways to do this, and I'm hoping that there are some smart Slashdotters who'll let me know what they are; please help!
I've taken over a software project in an extremely specialized area that needs remediation in months, so it'll be tough to build an internal team quickly enough. The good news is that there are outside software engineering groups that have exactly the right experience and good reputations. The bad news is that my management is worried about letting source code out of the building. Seems to me that unless I convince the suits otherwise, my options are to:
1) have all contractors work on our premises — a pain for everyone, and they might not want to do it at all
2) have them remote in to virtual desktops running on our premises — much of our software is sub-millisecond-response real-time systems on headless hardware, so they'll need to at least run executables locally, and giving access to executables but not sources seems like it will have challenges. And if the desktop environment goes down, more than a dozen people are frozen waiting for a fix. Also, I'd imagine that if a remote person really wanted the sources, they could video the sources as they scrolls by.
I'll bet there are n better ways to do this, and I'm hoping that there are some smart Slashdotters who'll let me know what they are; please help!
An NDA works and makes for Target to sue if the code gets out.
I'll bill you at triple my usual rate to pretend to have fixed your code, and you continue to pretend I could have done so without seeing your code.
If you quadruple my rate, I won't even admit to ever have done so.
I think it sounds perfectly equitable.
More seriously, that is what contracts are for. If you can't write a contract and hire people you can trust, you can't accomplish this task. At the end of the day, they'll see your code, and it will enter their brain.
As has been pointed out elsewhere, this is what NDAs with big penalties are for.
Lost at C:>. Found at C.
Speaking as a contractor, I'll work on site if you insist. You're the boss. Provide me with equipment and coffee, and I'll suck it up.
We're whores. We want your money. We don't care if your demands are stupid, as long as we can meet them.
You can do the onsite thing, but you are right in that you will limit the groups which may be interested, and also you may need to pay more as the group may include the cost of hotel stays, food, etc in their quote for doing the work. So you can limit your potential personnel and it can cost more.
If you do the remote thing, they don't have to log into virtual desktops, they can log into real hardware just as well if performance is an issue.
Also, "I need you to fix my source code but you can't see it" ... that's kind of a paradox.
And regarding your source code, set up a NDA. If the group you contract with is a quality group with a good reputation, this shouldn't be a problem. Actually I hate to break it to your management, but unless you are doing an air gap/search of employees entering a special lab where they have no means of getting the code off (floppies, USB keys, etc), your source code has likely left the building one way or another, for good or ill.
You can also tell your management that if they want to do this all internally, etc that the timeline needs to be extended. They are giving you legitimately contradictory constraints. Not that this is uncommon (constraints conflict all the time), but you need to know where the flexbility is.
" so it'll be tough to build an internal team quickly enough "
This smells of failure. Contractors aren't going to get up to speed any faster than internal resources (sans technology specifics like expertise in a language). Our management tried the same thing: hire contractors for a short term (less than 3 months), hurry up scenario. Except it took a month to interview and get the contractors on site. Much of the 3 months of contractors time was spent to get their environments setup, work with IT to configure permissions and the contractors themselves to learn the complex product enough to contribute. Not to mention the loss of focus of the internal team assisting the the contractors.
I would spend more effort coming up with a realistic plan that has a chance at success rather than trying to meet a date that is not going to be met. Build a plan that includes a mix of internal an external resources. I would include time to hire contractors (remembering that background checks take time) plus all of the other activities that will consume time away from producing the finished product.
I've always said English was my second language. Had Romeo and Juliet been written in C, I might have understood it.
Post a job ad, with a caveat in the description that developers can't see the code they are supposed to work on. Report back when you don't get any results. Have some conversations with recruiters and candidates, and document the WTF reactions while you're at it. It may also be worth getting different quotes from the team you wanted to hire: one at a rate with reasonable accommodations that allow them to do their jobs, and another where they will have to deal with endless BS because management doesn't trust anyone. The truth of the matter is that someone really, really wants to target your company, they will. An employee could steal something. You could be hacked. A very determined assailant, given enough time and resources, will get to you. There are tradeoffs made to account for this possibility, while allowing enough latitude for people to do their jobs. It's the same with this group of contractors. If they really, really wanted to steal from you, then they could, and no amount of legal procedure would stop them. If they have built up a good reputation, then they probably won't do this. At the end of the day, this gets down to managing the fear level of your superiors, and it may mean letting something go undone until they come around to letting go a little bit.
You cannot physically enforce security of code sources you are allowing people to see - unless you are going to have them work entirely naked, under constant physical observation, with full body cavity searches every time they enter or leave the workroom.
Hire someone trustworthy, pay them well, and have them work on-site. That is the path to success. Anything else is almost guaranteed to create the situation you're trying to avoid; paranoia breeds dissent and distrust breeds subterfuge.
You cannot simultaneously keep something secret and share it.
This question really doesn't make sense... How do you have a highly-valuable source code repository and simultaneously require external developers to modify/maintain it? How was the code developed initially? Did you have contractors develop it initially, and then have some kind of falling out? Did you have a mass walkout of your staff?
Maybe the cost to have people work on-site is worth it, maybe not. Management said they wanted to keep the code on-site, and management wants to manage costs. Management can decide whether working on-site is important enough to them that they want to spend the additional money, after you tell them how much it will cost them.
So estimate the costs for each option, then let management decide - do they want to spend three times as much to have people on-site, given that there is little to no benefit? Are they happy with remote desktop, given the costs? Let management decide their own priorities.
node.js doesn't block so it's faster than c. And since it's javascript, you can find programmers anywhere. Like that homeless guy holding a "callback(){ return food; }" sign. Underneath the stench is a 10x webscale javascript ninja that can rewrite your code in es6 javascript.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.