This question already has answers here:
How do you protect your software from illegal distribution? [closed]
(22 answers)
Closed 5 years ago.
Besides open-sourcing your project and legislation, are there ways to prevent, or at least minimize the damages of code leaking outside your company/group?
We obviously can't block Internet access (to prevent emailing the code) because programmer's need their references. We also can't block peripheral devices (USB, Firewire, etc.)
The code matters most when it has some proprietary algorithms and in-house developed knowledge (as opposed to regular routine code to draw GUIs, connect to databases, etc.), but some applications (like accounting software and CRMs) are just that: complex collections of routine code that are simple to develop in principle, but will take years to write from scratch. This is where leaked code will come in handy to competitors.
As far as I see it, preventing leakage relies almost entirely on human process. What do you think? What precautions and measures are you taking? And has code leakage affected you before?
You can't stop it getting out. So two solutions - stop people wanting to hurt you, and have legal precautions. To stop people hating you treat them right (saying more is probably off topic for stack overflow).
I'm not a lawyer, but to give yourself legal protection, if you believe in it, patent the ideas, put a copyright notice in the code, and make sure the contracts for your programmers specify carefully intellectual property rights.
But at the end of the day, the answer is run quicker than the competition.
Unless you're working with something highly classified and given that you can't block email and USB devices I guess you aren't there's really not to much damage to be had even if the source code leaks. The thing is, what is the code, or parts of it worth without the knowledge of how it works and the organization around it.
In general the value of "source" is much less than is commonly touted, basicly the source without the people or the organization isn't worth the storage it occupies for a competitor.
Also, you're missing the most likely attack vector, and it's also the one you can't stop no matter what. If someone really really want's to know how you made your magic then they'll try to hire your developers away, and since you can't stop them from having information inside their skull and even if they turn in all their possesions ther knowledge and domain expertise is leaving with them. Basicly employee retention and trust is the only way. Sorry.
I don't know how much actual help this is going to be, but:
Don't p*ss your programmers off. Don't get them in a position where they want to give the source to a competitor. Most places undervalue their developers. Given where you are (SO), I guess you are less likely to. Nothing got to me more than seeing the sales folks out for games of golf - paid, and paid for, by the company - while we had to fight to get pizza once a month.
Really, if your direct competitors got your code today, what would it do? Is your product or vertical market that stagnant that you wouldn't release newer, better versions before they could react? Is there no room for innovation? Most companies overvalue their "proprietary algorithms and in-house developed knowledge". Sure, it may cut some time off, but it's only about 10% of the problem.
If you got all the source for all your competitors products, how much actual use would it be? I'd guess it would set you back months. Not forward. Back.
If you had a clean system, and little external/internal knowledge, how long would it take you to get your own product into a buildable state? How long would it take to drill down into the code and workout what is going on? How much time and money would you waste trying to work something out, rather than spending time and money on how to make your product work better?
I've actually been in the position of having all the source - 1million lines+ of code - to a competitor's product. We did nothing with it - aside from a bit of a poke-around and then delete it, which was more than I was comfortable with - but I would expect that we'd have chewed up months of time just to get to where they were then.
So we nuked it, slapped the id10t who got it (yes, a developer/PM who came over from the other company), and thought about how to make our product kick so much butt that it didn't matter what they did. Much better use of time. Worked well, too. We had differentiators, not just re-hashing the same features in the same way they did them.
Sorry, but there is no way you can stop people getting stuff out, and still be able to actually work. You can stop them wanting to do it, or make it so there is no value to them having it.
We were worried about people decompiling our code too. We stopped worrying when we realised that WE had enough trouble working out what was going on inside 500K+ lines of C#, C++ and HTML code talking to MAPI/Exchange. If someone can decompile it and work it out, then we want to hire them......
BTW, for clarity, and given who I now work for, I should point out this is not my current employer. This was quite a while ago.
The code does not leak out on itself. It takes people to take it. There are obviously some security measures you might use like traffic analysis and lock-down on the repositories so only authorized developers can connect to it.
But by the end of the day your best option is to make sure that no one WANTS to steal from you. Your team has to be happy, they have to be proud to work for your they have to be loyal to the company and to each other. If you have such team it's a simple question of explaining to everyone that the code has to be protected from outsiders. It will not stop a dedicated mole but will prevent accidents.
P.S. And yes, proper clauses in the contracts would not harm as well, at least they will make sure that the developers are AWARE that taking code outside is morally wrong.
Follow these guidelines and it shouldn't matter if the contents of your entire source code repository is posted all over stackoverflow:
http://geocities.com/mdetting/unmaintainable.html
Oh, and show your developers that you don't trust them by blocking access to parts of the source code, scanning outgoing/incoming email etc. That is a surefire way to make them want to stay around... ...nothing improves morale like a bit of mistrust in the workplace.
Another cool way is to tell one half that they are "team a" and name the other half as the untrustworthy "team b". Then reverse it and say the same thing to the "team b" members. Encourage them to keep an eye on the "bad guys" in the other team and to report any signs of illoyalty to you. Sprinkle a few "conflict inducers" (e.g. tell "Joe": 'do you know what Ed says about you behind your back?') etc. Works wonders if you set up the developers against each other and create a few [invented-by-you] conflicts here and there...
(Eh, and no, I don't actually recommend any of the above. Just kidding. But I have seen people use all of the tactics above. And it didn't work.)
Okay, I am going to be a little practical here.
Being nice to everybody and hoping they won't hurt you doesn't work.
Every programmer knows from the day he joins a company that he'll not stay there forever. He will change when he's learned enough to get a better opportunity.
The programmers who write the code believe that they have the ownership to it even if they wrote it on the time they rented out to somebody else. So many of them will usually try to get their hands on the source-code even if they don't intend to hurt anybody.
Once they leave the company and they've carried the source code with them and lost contact with their colleagues, the conscience settles down and goes on a vacation and after a while bits and pieces from the code start showing up everywhere.
That's what I KNOW happens cause I've witnessed it happen to my company.
So what does one do?
Sign a NDA which specifically mentions that they programmer WILL not take copies.
Distribute your product between programmers, and if possible get modules coded individually and integrated by a chief whose responsibility is that all programmers do nt get all the code.
At the time of termination get a written undertaking from the coders that they do not possess any IP of the company and they understand the penalties of violation.
If somebody violates your IP, sue the man! No exceptions. It'll work as an example for the present team.
Do I sound extreme?
I remember this happening to Valve when they were developing HL-2. Interesting link here: http://www.shacknews.com/onearticle.x/28619
Most of the answers are based on Moral and ethical values. I wonder if Google, Facebook etc. just rely on their employees good will. Give me a break, that's totally utopian. Don't be a fool. Be realistic.
YES, it is possible to prevent code leaking:
Using a virtual server hosting virtual machines, programmers can only access locally to these virtual machines (intranet) via Remote Desktop. Repository is managed locally. private keys are required to access the repository. Copy/paste from virtual machine to client is disabled. only copy/paste from client to virtual is allowed.
Companies like facebook do that.
The only way to still code is by taking pictures to the actual code, which is totally not practical and feasible at all, and since there are surveillance cameras everywhere, you will have to go to the bathroom to take those pictures.
I've worked somewhere where there was a real culture of secrecy about this sort of thing (historically there had been a number of times when the company was small where "customers" had, shall we say, abused their access to our product).
While at the top the management were very protective, I see it slightly differently. I think our code, while not entirely irrelevant, isn't as key as you'd expect it to be in a software company.
The reason that we are successful is:
1) The code is essentially the solution to a bunch of problems. If you get our code you get those solutions but we still have the smart people who solved those problems. They understand those problems better than you do and are better able to solve the next set of problems better than you are.
2) Because they really understand the problems (and the solutions) we can do things faster than our competitors which translates to cheaper (or more profitable).
3) Also because of those people and the attitude within the company we've delivered well to our clients and provided good support.
4) And because of that we have a good reputation and reference-able customers.
A small number of companies have code which is genuinely worth keeping secret - proprietary algorithms and that sort of thing - but for a vast majority of us our products are very easily replicable by smart people.
What I'm saying is do the basics - write it into people's contracts that they can't take it, keep it secure and so on - but don't obsess over it. Unless you're in a very specific market it's unlikely to be what's really going to make your business succeed or fail.
The best step starts from reruting guys with strong ethical behaviour.
Various other steps can be taken like all communication being scanned. There are places where email and all information going out is scanned. The desktop/laptop does not have hard-disk or the access is restricted and all work is on network folders, even when working from home, one has to get connected to internet. The offline work gets synchronized. The USB and drives are disconnected.
The other policies are to provide access only on need basis.
These will only slow down and hinder to some extent, but is one is very determined then he would find ways to get around this.
The other way is if the code is really very important, then have the idea copywrite protected legaly.
To be honest it's almost impossible. If I wanted to suggest what a company that would shortly appear on the Daily WTF would do:
Disconnect the "work computer" from the internet, bt because they need internet access for reference buy everyone a wbbook.
Stuff the developers USB slots with epoxy and require that they load/unload everything from a centralised server, which scans all the data that goes through it for code like syntax.
Or you could just trust your employees and make them sign an NDA...
I personally never tested on any real case, but I would suggest using code fragmentation:
basically you split your project in a number of libraries, define interfaces and unit tests for each of them, then you separate SVN repositories so that each group have access to a limited part of your precious source code.
This is also a good practice no matter what and should help if you are outsourcing abroad.
The previous answers all seem to center on building trust and employing ethical people.
Another possibility might be to create your own domain specific language and tools. That will make any leaked code harder to use. It might still be possible to steal useful ideas from it, but it would not be possible to simply compile a competing product unless the whole toolchain is leaked.
Trust your developers. People tend to live up or down to expectations. Treat them well, and remember that loyalty goes both ways. After all, if you can't cut off thumb drives, you can't stop anybody from leaking code, no matter how much you don't trust them.
That being said, find yourself a lawyer with trade secret expertise, probably expertise in other parts of IP law, and ask how to legally safeguard stuff. You do want to make sure that, if a competitor gets your stuff, it's not legal for the competitor to benefit from it.
Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
How do you protect your software from illegal distribution?
Best practice to prevent software copy
Hypothetical situation:
Lets say I have built a software product from the scratch and it does wonderful things. The only problem is that, once someone takes a look at the code, they will understand it very easily and they can easily build it up themselves.
Now, the thing is that I built the code from the scratch 100% and uses a mixture of API calls.
Nobody else is involved in the development of the code.
If I want to sell this product, what is the guarantee that someone much smarter than me will reverse engineer the whole thing and come up with better product?
Right now I am thinking of fragmenting the whole code. Adding lots of redundant code and tonnes of comments.
Is there any software which encrypts the software code, that will make debugging, troubleshooting, and understanding how the code works virtually impossible? and yet runs as usual? so that the developer can have peace of mind?
Very few things in a program are truly novel. Almost everything that you are likely to put into your code, someone else could invent on their own. Generally more easily than they could learn it by reading your code. Reading code is harder than writing it, and most programmers don't really like doing it anyway.
So it's much more likely that they will look at your app and think "I could do that", then "That's cool, I'm gonna read that code and then copy it!". Even if they understand it, you will still own the copyright, you still get to market first.
I recommend that you just forget about it.
once someone takes a look at the
code, they will understand it very
easily and they can easily build it up
themselves.
So don't give anybody the source code.
If I want to sell this product, what
is the guarantee that someone much
smarter than me will reverse engineer
the whole thing and come up with
better product?
(a) So start selling it now and capture the market. Reverse engineering takes time, during which you are capturing market and 'mind-share'. (b) Put a provision in your licence agreement that prohibits reverse-engineering. (c) Make sure everybody who gets the product signs the agreement.
Right now I am thinking of fragmenting
the whole code. Adding lots of
redundant code and tonnes of comments.
That only has a point if you're going to distribute the source code. In which case nobody even needs to reverse-engineer. They have your source code. Don't give it to them.
Is there any software ...
There's lots of software that purports to do this job. However it is a technical solution to a business problem. All software can be reverse-engineered, because at some point or other it all has to be decrypted and de-obfuscated to the point where the CPU will understand it. At that point it is essentially plaintext. So no technical solution is formally speaking possible (short of something like code that executes in a tamper-proof HSM).
I will add that there is another business mechanism you can use to defend against business loss, which is what this is all about: price. Make the price so high that the licensees will value their copy and not permit it to be inspected, or make it so low that reverse-engineering is cost-infeasible; or make it free and make your money on the support contract.
Once you actually have the knowledge and experience to write such a codebase, it will be clear to you that obfuscation is meant to deter casual IP infringement.
Someone who wants to know your code is going to know your code.
If it becomes an issue of monetary loss, the courts are your protection.
That's how it works.
Someone will always be able to understand and work out your code. Heck, if you had 0 way getting to the code, even just using the system is enough for someone to be able to replicate the process.
Example: I take a jug of water and pour it into the cup, while my back is facing to another person. This other person knows that water and gravity are awesome at making things fall into other containers, so they can then work out a process of lifting a jug to let gravity (API call) work in their favour. They mightn't know exact what angle you used in your forearm and any super-sneaky cup-holding techniques you used, but they can replicate the same process and improve on it over time.
tl;dr: You can't protect code.
The thing to do is invent even more wonderful things while the competition is reverse-engineering your current stuff. It's called competing through innovation.
I am not a lawyer
if you are really worried about it, to the point you are willing to invest money in it, dont protect your code (beyond something reasonable like obfuscation or encryption) but rather patent your idea and your art. Then if someone does take it, reverse engineer it and make a better process based of yours, you have legal grounds to get your money.
There are tons of things you will have to do, include proving they took your idea (which isnt easy), but if this is the solution to world hunger and all of humanities problems its the thing to do.
Now for the downside, I will guess, and probably be 90% right that your method is:
Not patentable, for various reasons (I was amazed at the number of already patented ideas, and how difficult it was to identify original art)
Not new, or unique (i.e. there is already established art for it)
Not worth patenting because the expense far outways the benefits
An IP lawyer can tell you for sure, and the expense of a consult is not that much. Overall it will be cheaper to consult with them then to invest a lot of time in hiding code.
Good luck.
Don't even bother. If your code really "does wonderful things" be assured that it'll get hacked. And be it just for curiosity.
There is no 100% way to protect your code from reverse engineering. What language are we talking about? If this is C/C++ then it is pretty hard to reverse engineer, more you could strip it from debugging information etc. But if this is for example Java then even if you obfuscate the code, there are some pretty cool tools (like JAD) that will reveal much of your work anyway.
Despite all of this I think you should try to change your attitude. Big companies pay a lot of money for simple solutions and it seems that nowadays service is the most important thing, not the software (hence the success of open-software based companies). So, if you have a great software don't be scared that someone might steal it, rather think how to sell it good.
Is there any software which encrypts the software code, that will make debugging, troubleshooting, and understanding how the code works virtually impossible? and yet runs as usual? so that the developer can have peace of mind?
This is the totally wrong mindset IMO. What happens if you get hit by a bus? Your company goes bankrupt? All your data gets destroyed in a fire? For every single one of your customers, the value of their investment in your software will drop, and eventually reach zero, because the software can't be developed, or troubleshot, any further without you. I have seen so much money wasted that way, I think it's a horrible business model.
I earn my bread with making software myself so I know the hardships of making a living with it. Still, obfuscation can't be the way to go nowadays. Impose strict license agreements on your customers, scare the hell out of them so they don't even think about redistributing the software, but leave it open.
This is futile. There is always someone smarter than you and therefore they will be able to reverse engineer your obfuscation.
Usually someone smart enough to hack your code and use it in a meaningful way is smart enough to do it on their own, and probably thinks they can do it better than you did, so they won't bother stealing your stuff.
Don't worry about the people who can hack your code but not make meaningful use of it. If you've done a good job, this can only reinforce the quality of the job you've done (think of all the crappy touchscreen phone imitators).
They are going to reverse-engineer your code. Nothing can stop them.. The only thing you can do is make it harder. This ranges from obfuscating code that is inheritely "open" such as PHP and Javascript, all the way down to littering your code with a crap load of self-modification.
In a lot of ways, I think, the thing that makes a piece of software valuable, is not the crazy technological advancement that it provides, but rather the things that we think might think of as being tertiary to the piece of software itself. Like the fact that you'll be there to support it. Or that it's provided as a web service and you'll be there to make sure the server is running. Or that it's a community, and you'll be there to moderate and build the community.
While you may be actually selling code, the value you that your code has isn't intrinsic to the code itself, but rather derives from the features and ecosystem that surrounds your code.
I'm doing some job interviews for the first time for my replacement. I want to know how they would approach a brownfields project, but am not really sure how to phrase the question.
I'd like to know what their attitude is: e.g. throw out and rewrite, use a tool to refactor, step through the code and understand, what books they've read (e.g. "Working Effectively with Legacy Code").
How do you find out how someone takes on brownfields software development?
When interviewing, try to engage in scenario brainstorming or role playing, not definition swapping. In this case try to engage an applicant in telling their story about what they would expect "...when taking over responsibility for the main finance system, which this department and that group use daily for these things, and there are a couple things that are wrong with it today, and oh by the way, there is a upgrade release scheduled for three months from now that will allow direct integration with this new banking partner for 1099 processing". Make the scenario specific and real for your situation, and get them talking.
The important thing is to draw out from them not only what they would do, but almost as importantly, what they know to expect. If your candidate sits across from you and weaves a story about getting up to speed in a couple days and making major changes up through production by next Friday, without asking any of the important questions and impressing you with their effectiveness, doubt their experience (and if you are in a regulated industry or, unfortunately, Big Company, possibly their sanity). If instead they ask good questions about what the environment is like today, what's the review process, who makes the decisions about functionality, is there a testing environment, is the code testable or are there unit tests (gasp) in place, and what happens today if a change needs to get in place by Friday - hey, they've probably been here and done this before.
You of course want to hear how they would make sure existing functionality works and time bombs aren't being set but you also want to hear them making reference to things they would be doing so that this project becomes better, easier to work with, and more fun over time. The activities they specifically are engaging in to turn the inherited legacy project into a rocking world of fun should come through in their storytelling. I mean, they are planning on doing that, right?
Great interviews are conversations and experience sharing and story telling. Draw those stories out, bounce them against the b.s. shield, and go.
This sounds like a great interview question. Why not just ask them
what steps they'd take on inheriting/maintaining/extending a badly written legacy codebase, or how do you determine when a codebase needs to be refactored? Another option would be to give them a medium sized piece of spaghetti code and ask them how they'd extend it.
Lots of good suggestions for answers here.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm dealing with an issue with my current employer that has seriously made me consider seeking employment elsewhere. They are under the impression that 100% of custom development should be eliminated and replaced with COTS products, such as SharePoint. While I realize that this is not a realistic expectation, I've found it impossible to argue my points with the people in management that share these views. Their argument usually involves something along the lines of a feature already existing in SharePoint that covers feature X, therefore there is less risk involved and testing doesn't have to be done against it.
Case in point, we have a situation where a SharePoint list is completely incapable of meeting customer expectations and requirements. Saving this data in a SQL database, however, would easily satisfy the requirements. Any time our development team suggests going outside of the boundaries of SharePoint, however, management goes up in flames about how every line of code adds to the complexity of the project and increases risk. While this is certainly true in some situations, it's not always the case. Their argument, however, is that since SharePoint provides a mechanism for storing data, that we should use it 100% of the time. Regardless of if it meets customer requirements, or not.
I've gotten to the point that I hate coming to work because I'm constantly forced into doing things that I know (with 100% certainty) are not right and that could be made right by doing custom development. It's simply what seems to be an impossible argument where I work, however.
Have any of you experienced a similar situation? If so, what have you done to work through these challenges?
If you don't share the vision of the company and if you can't enlighten them then sure, it is a good time to start looking.
Have you pointed out that there is risk in forcing a "solution" on a client that does not help them or is missing functionality or is unusable?
Perhaps come up with plans to address and mitigate their perceived risks.
You document your concerns and let those above you know them, and then you do as they ask. If it doesn't work, you have documentation that you brought the concerns up. But try to make it work their way, so it doesn't look like you're trying to undermine their plans. They're taking the greater risk, and thus they get the greater responsibility. Try your best to make it work their way, and quit worrying about it.
This may sound bad and may not be the answer you want. There is a little known division in my office called "The Skunk Works." People, on their own accord (usually during lunch breaks or compile time) decide to write little programs that help the company. The fun things about this is the result doesn't "cost" the company anything.
The conversation usually goes like this:
"We need to buy this software" -Boss
"But, we have had that thing for months. John, wrote that back in the day" -Programmer
"?" -Boss
A lot of times the developers see a decision as being bad and just create a parallel process that happens automatically. Then, when the stuff hits the fan and the customers are frustrated, the alternate solution is ALREADY in place.
I have an example of an auto release machine. Developers used to create these custom reports. As our customers increased, the developer's workload increased. The problem was "In order for the customer to get the custom report developer had to be involved." So, while the company was looking into hiring someone to do reports full time or to find ways to have the customers do them, I wrote an auto release machine that looks for report changes and releases them directly to the customer. I also wrote a utility that allows anybody to make changes to the reports that was easier to use than what the developer has. When the Boss made the announcement of trying to find a solution, I told him that it was already in place and that even he could make changes to reports and get them released. Now, everybody can change reports, usually it is management and customer support who make these changes. The fun side is that developers arn't involved anymore.
Just do it. If you're going to quit anyways, might as well try.
Does someone in management own stock in SharePoint? Was the system developed by the CEO's younger brother?
If they are that resilient to change, you should find out the real reason before trying to argue with them. They may claim that there is added complexity, difficulty testing, etc, but if you can counter every argument with one that shows their position, with all due respect, to be misinformed, and they still won't discuss, then you may be arguing the wrong point.
If they are locked into the technology because of a non-technical reason, such as someone once read that SharePoint is the ultimate in any technical situation (and, of course, had no clue what the article was talking about other than SharePoint = good) then you shouldn't bother trying to argue and save your energy. For the job hunt.
Prove it to them. When the requirements ask for a list that can handle 100,000 items with a multi-column sort - write a script that adds 100,000 test items into a sharepoint list and let them try it, preferrably with the "customer" requesting the list watching. :-)
I would definitely get my resume out and into the open if I were you. Not only is the experience that you are currently having frustrating, it can really hurt your career development over the long haul. Just think about it. While you are languishing with your current employer in your current position, other developers are adopting new technologies and expanding their experience.
There is such a thing as ideological differences between developers and what a company's idea of a role for a developer is. If open discussion and candor get you nowhere, you will not be faulted for a lack of effort. Loyalty to a company is a good thing, but the relationship needs to be a two-way street.
Sadly, the will eventually probably come to realize that they are wrong in their assumptions - but you can not wait for that day to come. Sometimes it never comes. In particular (and don't get me wrong, I love SharePoint when it is used for what it is intended for), SharePoint is become the next Access, in that people who read management magazines see enough of it thrown around to call it the messiah.
I find that there is typically no way of 'winning' these debates through talk alone. Many managers form an opinion of a product or solution through reading management oriented articles. See if you can find some counter-articles.
If you can cite examples of things which SharePoint is incapable of doing, and show examples of how you can cost effectively solve these problems through custom development then you are well on your way.
The mistake is to try and make this a conversation about technology, it's not, its about efficiency, cost effectiveness and maintainability - those are the mantras and metrics which will sway non-technical managers into considering alternatives.
If you can put together a proof of concept for some of these issues so much the better, eye candy really helps to sell outside of technical teams.
Finally, good luck :)
I am doing the same thing at my current job, there is no easy way to deal with this kind of situation. All I have been able to do is swallow my arguments, cause they have gotten me no where, and do as required by my management. This off course will go against your basic programmer nature of using the best solution for the task at hand, and maybe getting to build something cool in the process, but since they are the boss it is really your only solution. You could try to site cases, with evidence, where it makes more sense to use custom solutions. But if you boss is anything like mine, it won't get very far before the screaming match begins. The only other solution is dusting off that resume and finding a new job.
I have faced the same kind of challenges right from day one. Management have a natural reluctance to add custom code to the solution. However in most cases it has been posible to explain than the right solution for the customer would include some custom code.
Remember, if you argue that you can include the custom code in the common codebase, then the boss might approve the idea.
I really feel your pain.
If it was me I would use my spare time to collect information that proves my point and document it in a easy to understand way.
If they only understand money, talk money, if they only understand fear (doing "this" because they are scared of "that"), use the fear, finding scary thing for them in "their" solution.
Document every new implementation, the time, money and problem that arises. And document what your solution would be instead.
They probably doesn't see the problem in their solution, because they focus on not having problems in "your" solution.
I have worked in a place where management were not constructive in their approach, not quite as bad as you describe, but bad enough.
There are a couple of options. One is to go ahead and do what needs to be done for the client with the best "value for money" option you can. You will probably have to get the developers together as a team to make this "civil disobedience" work.
A more forceful approach that will really make the shit hit the fan is to go to the client (don't do this if it is an external client or if you wish to keep your job) and lay out what is going to happen to this project if X and Y. This is pretty much telling tales out of school and is going to be bad, but entertaining.
A slightly better way is to go up the chain and get a sponsor who can make shit happen for you. Essentially go behind your boss(es) back. This may work, but it is going to have predictable results for your relationship with your management.
Last and hardest is to identify the person who holds the view that any custom code is bad and engage them in conversation to find out where they got the belief and counter that with examples. Emphasis on conversation as you will have to listen to and understand their underlying concerns (which won't be about custom code per se) and only address them after you gain that persons trust.
I cannot tell you which way of doing things is going to work best because it depends so much on the individuals involved. All I do know is that you cannot change people and in my experience the best way to solve the problem so far has been to leave and work with people who are not so...
how about not calling it custom code. If instead you call it 'anticipated SharePoint user extensions' or something it may soften the misconception surrounding a specific term.
also, as has been said, there may be other hidden from you reasons that management is pushing this agenda. It is probably best to not second guess these too quickly, as many would be valid.
Finally, there are alot of places that need development. it doesnt hurt to look for a better match.
good luck.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've read somewhere (I forget the source, sorry - I think the MS Office developer's blog?), that when you do a survey of users asking them about what features they would like to see in your software/website, they will more often than not say that they want every little thing, whereas collected metrics show that in the end, most people don't use 99% of these features. The general message from the blog post was that you shouldn't ask people what they use, you should track it for yourself.
This leads to an unfortunate chicken-and-egg situation when trying to figure out what new feature to add next. Without the feature already in place, I can't measure how much it's actually being used. With finite (and severely stretched) resources, I also can't afford to add all the features and then remove the unused ones.
How do you find out what will be useful to your users? If a survey is the only option, do you have to structure your questions in certain ways (eg: don't show a list of possible features, since that would be leading them on)?
Contrary to popular belief, you don't ask them. Well, you don't listen to them when they tell you what they want. You watch them while they use what they have right now. If they don't have anything, you listen to them enough to give them a prototype, then you watch them use that. How a person actually uses software tells you a lot more than what they actually say they want. Watch what they do to find out what they really need.
Give them options and the have them arrange them in order of importance. As you said, the users are going to want everything, but this will allow you to tell what they want the most.
You tell them. Then both of you know.
(No, your users won't tell you what they want. That's work. If users wanted more work to do, they wouldn't be looking for software to do their work for them.)
An anecdote from a previous life:
We were planning for a new release and wanted to add some new features to the application. We got the users together and brainstormed what things they wanted to see in the system, placing each "feature" on a yellow sticky on a white board. We then grouped similar requests together and eliminated duplicates or near dups.
We then laid each sticky on a table with a cup in front of it. Each user got 10 pennies to "vote" on the features they wanted. They could put as many pennies in each cup as they wanted, up to all their pennies in one cup if they so desired. We then counted the number of pennies in each cup and chose to implement the top 5 vote getters, in order of votes.
It was surprising to see people that were passionate about a feature while brainstorming and categorizing turn around and not vote for that feature (or vote lightly for it).
Of course, a technique like this will only work if you have ready access to your user base (this was for an enterprise system we developed internally).
You ask them.
(No, you do not know what your users want better than they do. Yes, you will get a lot of stupid answers. Avoid multiple-choice surveys and instead opt for reviewing free-form answers. The information you collect will be invaluable.)
Of course — you could always allow your users to vote on which features they like most...
Users know what they don't want better than they know what they want.
We had brought in a team do do an Oracle eBusiness Suite implementation. They took an interesting approach that had worked very well for them in the past. But it was phenomenal in our environment.
We had cultural issues which meant none of the users were going to stick the necks out to say what they wanted. I had history with the users from the past. Trying to get get requirements out of them was like trying to get blood from a stone. But once you went live the bitching would start.
Anyway the implementation team installed Oracle eBusiness Suite straight out of the box. Give the users the basic training. Then about every 4 weeks for the next 6 months they customized the base installation to accommodate the complaints.
I would recommend against showing them options; as you point out, if it's available, then people will want it just for the sake of having it. Often the users are not aware of the extra costs of developing a particular feature, and just want it because you mentioned the possibility of having it.
The other option is to show a list of all the features you could possibly add, and then attach a price to each one, and then ask users, would it be worth $X to have feature Y, or, how much extra would you be willing to pay for feature Y?
Eat your own dog food
Try to use the application that you write yourself as much as possible. Then you will know how you can improve your application.
According to 37 Signals - Getting Real book, you don't do anything, you don't even record what they want, you just delete mails after one read without any action.
When it comes to implement / fix stuff you'll remember the most important things that your users want from top of your head. Obviously this requires a bit user base.
You need to tie features to cost. Everyone wants features, but not every feature is worth paying for. Ask which features are most important, which would your users be willing to pay for? Develop features based on the priorities supplied by users and stop when they aren't willing to pay for any more. Get the product into their hands as quickly as possible so that you can get real feedback on what doesn't work and what needs to be added. When the users have access to real software, you get much better information. This works best when you are developing specifically for a particular customer. If you don't have access to real customers, consider seeding your product with people (can you say, public beta?) free in order to get better feedback.
Users don't know what features they want. You don't know what features they might be offered. "Features" don't mean anything except as they help them accomplish tasks and achieve goals. And that's where you should start, because they will have a very imperfect understanding how they relate.
There is one thing they know, maybe, much better than you do. And that's how to get their jobs done.
As soon as computer/software concepts and terminology start to leak into the discussion between users and designers, you're off the rails.
So many times users will focus their requirements in terms of what's wrong with, or could be improved about, the software they currently use. Over time, even they lose the distinction between their jobs, and the software they use to do their jobs.
It's a very hard, critically important problem for you to solve this.
The only way to know what the users "really" need is to "be" the user.
Its programming kung fu black belt level.
"Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.
Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot it becomes the teapot. Now, water can flow or it can crash. Be water my friend."
When you be the water/customer, you'll now.
I think Bruce Lee would be a good programmer.
Im very serious. This is the way I work. I cant do things I dont understand, so I have to understand before I do things. When I understand, and my costomers know I understand then I can do a good job. Without understanding there will be missunderstandings. You are the only person who know when you have the correct level of understanding, you are also the person who is responsible to get that knowledge.
The Oracle at Delphi
Pros: accuracy is superb
Cons: if you can interpret the messages, which many people fail to do (often seeing what they want to see). Also requires supplication, which can get messy (contrary to popular opinion, your hecatomb need not be 100 of the same type of livestock).
Psychics
Pros: accurate to a point.
Cons: rare. Prone to mental instability, highly vulnerable to eldritch beings, and might attract unwanted attention from them. Also, it takes experience to sort through the mystery that is the human mind to get to desired information. And sometimes you still need to probe subjects while they're actually doing the thing they need help with, since users lie.
Plant a mole
Pros: New gadgets. New Poisons! Plans within plans within plans. Baby's a freak show. You might learn all sorts of fascinating things in addition to the information you need to help the user.
Cons: Expensive. Chances remain that the agent will turn on you, or fail to learn anything you couldn't learn more simply. If discovered, organization will likely turn or liquidate the asset, which represents a huge investment of resources. Organization might reciprocate.
Guess
Pros: Take a group of people with average to great imaginations and problem solving skills, give them some booze and inspire them with some quotes from Ghostbusters, Big Trouble in Little China, or The Big Lewbowski. Who knows where it will go, but it'll be fun and they might produce something interesting/useful.
Cons: Chances of meeting user's needs are higher than you think, but not that good.
Ask the user
Pros: users feel empowered as part of the process.
cons: until they have to decide on anything, at which point you are on your own. Unless the user is a very experienced user, in which case they probably have a good idea of what the want. There's only like 4 experienced users on the planet though, and nobody ever knows anyone who gets to do a job for them. They may be mythical beasts.
Pretend you care and ask the user (even though you don't really), and then observe them doing whatever key workflow/process/etc is involved and pay attention to what they do.
Pros: you trick the users into thinking their opinion matters, which empowers them but doesn't deliver any other baggage. Since users lie - no purposefully or maliciously mind - you actually get to see them in action and get a better grasp of what the problem is, thus giving you a better foundation for building a solution. Also, you avoid the psychic route, and thus avoid a long and winding road that begins with promise but ends with you and the psychic being eaten by some monstrous, unspeakable thing that is not of this world. Observing the process is like totally Zen, which is good for your Developer Mystique.
Cons: No road trip to the Oracle (which would be EPIC). Spies are much sexier; chicks dig spies. Ghostbusters|Big Trouble in Little China|The Big Lewboski probably aren't involved. Feels more like work than the rest of the options.
Asking users about features will prompt them to talk to you about features.
If you want to find out what users really want then you are talking about understanding their goals and motivations. I've found the easiest way to start doing this is user interviews, not about features but about how users use your product and products like it, why they are using it and how it fits in with their life.
Once you build an understanding of what your users are trying to do with your product and why they want to do it you are in a position to make an informed judgment as to whether the features people requested are what they really need.
Ideally I think your problem is about understanding users rather then just listening to their requests.
This is an old question with a lot of good answers already, but I thought I'd just add a little bit of personal experience for the sake of people who end up here in the future through a search like I did.
If your project does not need to gain an audience as quickly as possible in order to succeed (like a webapp) if it's more of an internal project or product to be sold for a fixed client, or type of client, then I believe your best bet is to go the 37signals way: give your users the absolute minimum they need in order to accomplish the most basic tasks of the most basic cycle of work at first, then listen to what they say it's objectively missing in order for them to do their work properly. Not what they want or would like it to have, but what they really need. And the only way you know for sure what you really need is when you don't have it.
I worked as the designer in the development team of an intranet-based "heart-of-the-company" app that followed that strategy, and the results were wonderful. First week: everyone was pissed. When it was over, 90%+ of approval, and the app was still simple and beautiful. And most of the people who were not entirely satisfied seemed to understand why it couldn't be like they wanted, and the main request of nearly everyone was to, whatever we did, keep the app simple.
Again, if you're working on a product or website that needs to attract people first, that might not be feasible or delay things a lot. But if you have some control or leeway over the userbase, I'd definitely recommend this approach.
You don't ask for features. You ask for problems. Pain points. Find out what they hate about their current solution. Find out what eats in to their time.
When you know what they don't like, then you build the solution to those problems.
When you solve real problems, then you're creating real products that people will gladly give you money for.
But what's also important is respecting them during your research phase. Surveys are still great for doing research, but if you ask them a dozen questions, they will hate you. You need to respect their time and use a survey tool that engages them and leaves a great impression.
It's a proven fact users don't know what they want. What you need to ask them is what is wrong with what there is now - what problems are they having with your software? why aren't they using x feature and y control? why interaction x worked for them while interaction y made them try to gauge their eyes out?
Of course to be able to ask those questions, you need to do some field study and see what features are used, what patterns your users exhibit and analyze that data. That analysis will give you the base for much more specific questions which users are able to answer decisively and accurately.
If you're serious, you videotape them at their work, and then you break down what they are trying to accomplish and how your product can help them. This is part of a whole discipline called usability engineering. A good introduction to technique is Jakob Nielsen's book Usability Engineering. Back before he became a shameless huckster, Jakob was a very good scientist and he learned a lot about cheap ways of figuring out what users need. Especially good if you're on a budget. What impressed me most was using paper prototypes; this is a great way to mock up software you haven't built yet and helps answer your question about what to build next. Until I saw this technique in action I couldn't believe how effective it could be.
P.S. One example of what happens if you just ask people: 90% of the feature requests for Microsoft Office 2007 were for features that were already in Microsoft Office 2003. In that case what users needed were better ways of finding what was already there. I wish I could find where I read about this... sorry not to have a reference.
I'm assuming based on your wording that you are building a product to sell, and not building something to order for a specific client.
In that context, I'd say that you should start by becoming a user yourself and building the features you need in the way that you want it. As you evolve the product, you'll need feedback from other users, but this at least this gets you started and breaks the chicken-egg cycle.
As for measuring actual usage of features, you can set up a discussion forum to get feedback on the features you added... you don't need anything too complicated if you are time-strapped.
I personally like the hands off approach from customers. They give you high level requirements and you provide the implementation. Your software team/company/division are supposed to be the experts. Sure you will make some mistakes, if its horrible the customer will pipe up and you will fix it, but generally having the implementation up to you and your developers is a fun dilemma to solve.
Research, research, research. Learn from others designs, then make your own kickass design. Not easy but then again they don't pay developers the big bucks for nothing.
That's a good question.
If you're building an FPS game, you really need to know for yourself what should be included, because 99% of your users will never contact you to say "I wish your game just had X". An experienced beta-testing team can help here.
If you're writing an accounting application, you need to understand the industry and what users are trying to accomplish when they use your product, and try and focus your feature set around those goals.
If you're writing a custom app for 100 users in one business, you could have a chat to the dozen or so most avid users of the software. They're the ones who know all the forms back-to-front, have discovered all the undocumented shortcut keys, and have also figured out how to circumvent many of your data validation rules.
Imagine you are them
Use Cases.
What will they do with that feature?
It works like this.
People take actions. We build software to help them take actions
In order to take an action a person must make a decision. We build software to help them make decisions.
In order to make a decision to take an action, a person needs information. We build software to collect and present information.
Every feature must be an Action, a Decision or Information. And the connection had better be direct. Information that does not lead to a decision or an action isn't even "nice to have" -- it's junk.
Users say a lot of things. What do they do? What decisions do they make? What information do they need?
Edit
Note that not everyone is good at describing use cases. Some people have no vision and will simply tell you what they do today without understanding how they are creating business (or personal) value. They may not really know what decisions they're supposed to be making, and are vague on the information they need.
Other users know what value they create, and why, and can discuss use cases well. They can envision alternative ways to create value; they can articulate options for their actions. Decisions don't have a lot of alternative implementations (people make decisions, not software) and the information required doesn't change much, either.
Watch them.
Identify bottlenecks in their work
Create something that solves that
bottleneck in an elegant way
Let them use it
Repeat until everyone is happy
Based on the principles:
Users know what they want, but they
don't know what they really need.
You ARE
NEVER going to get it right the
first time.
It seems like a chicken-and-egg problem. Much like computing PageRank. A page's page rank is dependent on the PageRank of other pages linking to that page.
One way of computing PageRank is by iteration.
Iteration is the key!
A. Voting
Gather a biiiig list of features all users want (make them enumerate each feature they want).
Then have them review the list and allow them to vote on features. Say, give em 100 points to distribute on features. They can give more than 1 point to a feature.
B. Analysis
Analyze the business model, List the features that you think is needed.
This is needed because:
users sometimes don't get the big
picture
you have this REALLY great
idea that users won't think of in a
bajillion years.
C. Implement
Analyze list from A and B, merge, remove a few, improve some. Implement.
D. Test
Test it on users. Hear their complaints. Look at
- features they use often
- stuff they get stuck on
- etc etc etc
E. Iterate
Usually, users do not always know what they want and whether they want anything. In our company sales people go to existing and potential customers, show them our product and explain them why they desperately want that.
In my time in university we were taught something called "userp-driven development". Here you really have to go to the customer, observer how people there work, what tools do they use, and try to find out what could facilitate their life. You then create a mock-up, go to the customer again, present it to the users, get their feedback and then proceed to improve your mock-up. When everyone more or less agrees to the course of action, you do implementation, regularly showing the customer what you have trying to get correction feedback as early as possible.
Important is not to talk to the managers who want the product, but to the users who will use the product. Otherwise the whole play will bring you nothing.
P.S. Asking them directly "What do you want?" could be a dangerous question...
Babylon 5 - What do you want?
It's called Market Research.
No, this wasn't a dig at the guy, that's really what it is about. Sure, there's a bunch of techniques that UCD people use in the field to get user requirements, but they are exactly the same tools used by market researchers. Card Sorting, Priority lists and so on are all market research terms.
Anyone visiting a torrent tracker is sure to find droves of "cracked" programs ranging from simple shareware to software suites costing thousands of dollars. It seems that as long as the program does not rely on a remote service (e.g. an MMORPG) that any built-in copy protection or user authentication is useless.
Is it effectively not possible to prevent a cracker from circumventing the copy protection? Why?
No, it's not really possible to prevent it. You can make it extremely difficult - some Starforce versions apparently accomplished that, at the expense of seriously pissing off a number of "users" (victims might be more accurate).
Your code is running on their system and they can do whatever they want with it. Attach a debugger, modify memory, whatever. That's just how it is.
Spore appears to be an elegant example of where draconian efforts in this direction have not only totally failed to prevent it from being shared around P2P networks etc, but has significantly harmed the image of the product and almost certainly the sales.
Also worth noting that users may need to crack copy protection for their own use; I recall playing Diablo on my laptop some years back, which had no internal optical drive. So I dropped in a no-cd crack, and was then entertained for several hours on a long plane flight. Forcing that kind of check, and hence users to work around it is a misfeature of the stupidest kind.
It is impossible to stop it without breaking your product. The proof:
Given: The people you are trying to prevent from hacking/stealing will inevitably be much more technically sophisticated than a large portion of your market.
Given: Your product will be used by some members of the public.
Given: Using your product requires access to it's data on some level.
Therefore, You have to released you encrypt-key/copy protection method/program data to the public in enough of a fashion that the data has been seen in it's useable/unencrypted form.
Therefore, you have in some fashion made your data accessible to pirates.
Therefore, your data will be more easily accessible to the hackers than your legitimate audience.
Therefore, ANYTHING past the most simplistic protection method will end up treating your legitimate audience like pirates and alienating them
Or in short, the way the end user sees it:
Because it's a fixed defense against a thinking opponent.
The military theorists beat this one to death how many millennia ago ?
Copy-protection is like security -- it's impossible to achieve 100% perfection but you can add layers that make it successively more difficult to crack.
Most applications have some point where they ask (themselves), "Is the license valid?" The hacker just needs to find that point and alter the compiled code to return "yes." Alternatively, crackers can use brute-force to try different license keys until one works. There's also social factors -- once one person buys the tool they might post a valid license code on the Internet.
So, code obfuscation makes it more difficult (but not impossible) to find the code to alter. Digital signing of the binaries makes it more difficult to change the code, but still not impossible. Brute-force methods can be combated with long license codes with lots of error-correction bits. Social attacks can be mitigated by requiring a name, email, and phone number that is part of the license code itself. I've used that method to great effect.
Good luck!
Sorry to bust in on an ancient thread, but this is what we do for a living and we're really really good at it. It's all we do. So some of the information here is wrong and I want to set the record straight.
Theoretically uncrackable protection is not only possible it's what we sell. The basic model the major copy protection vendors (including us) follow is to use encryption of the exe and dlls and a secret key to decrypt at runtime.
There are three components:
Very strong encryption: we use AES 128-bit encryption which is effectively immune to a brute force attack. Some day when quantum computers are common it might be possible to break it but it's unreasonable to assume you will crack this strength encryption to copy software as opposed to national secrets.
Secure key storage: if a cracker can get the key to the encryption, you're hosed. The only way to GUARANTEE a key can't be stolen is to store it on a secure device. We use a dongle (it comes in many flavors but the OS always just sees it as a removable flash drive). The dongle stores the key on a smart card chip which is hardened against side channel attacks like DPA. The key generation is tied to multiple factors which are non-deterministic and dynamic so no single key/master crack is possible. The communication between the key storage and the runtime on the computer is also encrypted so a man-in-the-middle attack is thwarted.
Debugger detection: Basically you want to stop a cracker from taking a snapshot of memory (after decryption) and making an executable out of that. Some of the stuff we do to prevent this is secret, but in general we allow for debugger detection and lock the license when a debugger is present (this is an optional setting). We also never completely decrypt the entire program in memory so you can never get all the code by "stealing" memory.
We have a full time cryptologist who can crack just about anybody's protection system. He spends all his time studying how to crack software so we can prevent it. So you don't think this is just a cheap shill for what we do, we're not unique: other companies such as SafeNet and Arxan Technologies can do some very strong protection as well.
A lot of software-only or obfuscation schemes are easy to crack since the cracker can just identify the program entry point and branch around any any license checking or other stuff the ISV has put in to try to prevent piracy. Some people even with dongles will throw up a dialog when the license isn't found--setting a breakpoint on that error will give the cracker a nice place in the assembly code to do a patch. Again, this requires unencrypted machine code to be available--something you don't get if you do strong encryption of the .exe.
One last thing: I think we're unique in that we've had several open contests where we provided a system to people and invited them to crack it. We've had some pretty hefty cash prizes but no one has yet cracked our system. If an ISV takes our system and implements it incorrectly it's no different from putting a great padlock on your front door attached to a cheap hasp with wood screws--easy to circumvent. But if you use our tools as we suggest we believe your software cannot be cracked.
HTH.
The difference between security and copy-protection is that with security, you are protecting an asset from an attacker while allowing access by an authorized user. With copy protection, the attacker and the authorized user are the same person. That makes perfect copy protection impossible.
I think given enough time a would-be cracker can circumvent any copy-protection, even ones using callbacks to remote servers. All it takes is redirecting all outgoing traffic through a box that will filter those requests, and respond with the appropriate messages.
On a long enough timeline, the survival rate of copy protection systems is 0. Everything is reverse-engineerable with enough time and knowledge.
Perhaps you should focus on ways of making your software be more attractive with real, registered, uncracked versions. Superior customer service, perks for registration, etc. reward legitimate users.
Basically history has shown us the most you can buy with copy protection is a little time. Fundamentally since there is data you want someone to see one way, there is a way to get to that data. Since there is a way someone can exploit that way to get to the data.
The only thing that any copy protection or encryption for that matter can do is make it very hard to get at something. If someone is motivated enough there is always the brute force way of getting around things.
But more importantly, in the computer software space we have tons of tools that let us see how things are working, and once you get the method of how the copy protection works then its a very simple matter to get what you want.
The other issue is that copy protection for the most part just frustrates your users who are paying for your software. Take a look at the open source model they don't bother and some folks are making a ton of money encouraging people to copy their software.
"Trying to make bits uncopyable is like trying to make water not wet." -- Bruce Schneier
Copy protection and other forms of digital restrictions management are inherently breakable, because it is not possible to make a stream of bits visible to a computer while simultaneously preventing that computer from copying them. It just can't be done.
As others have pointed out, copy protection only serves to punish legitimate customers. I have no desire to play Spore, but if I did, I'd likely buy it but then install the cracked version because it's actually a better product for its lack of the system-damaging SecuROM or property-depriving activation scheme.
}} Why?
You can buy the most expensive safe in the world, and use it to to protect something. Once you give away the combination to open the safe, you have lost your security.
The same is true for software, if you want people to use your product you must given them the ability to open the proverbial safe and access the contents, obfuscating the method to open the lock doesn't help. You have granted them the ability to open it.
You can either trust your customers/users, or you can waste inordinate amounts of time and resource trying to defeat them instead of providing the features they want to pay for.
It just doesn't pay to bother. Really. If you don't protect your software, and it's good, undoubtedly someone will pirate it. The barrier will be low, of course. But the time you save from not bothering will be time you can invest in your product, marketing, customer relationships, etc., building your customer base for the long term.
If you do spend the time on protecting your product instead of developing it, you'll definitely reduce piracy. But now your competitors may be able to develop features that you didn't have time for, and you may very well end up selling less, even in the short term.
As others point out, you can easily end up frustrating real and legitimate users more than you frustrate the crooks. Always keep your paying users in mind when you develop a circumvention technique.
If your software is wanted, you have no hope against the army of bored 17 year old's. :)
In the case of personal copying/non-commercial copyright infringement, the key factor would appear to be the relationship between the price of the item and the ease of copying it. You can increase the difficulty to copy it, but with diminishing returns as highlighted by some of the previous answers. The other tack to take would be to lower the price until even the effort to download it via bittorrent is more cumbersome than simply buying it.
There are actually many successful examples where an author has found a sweet spot of pricing that has certainly resulted in a large profit for themselves. Trying to chase a 100% unauthorized copy prevention is a lost cause, you only need to get a large group of customers willing to pay instead of downloading illegaly. The very thing that makes pirating softweare inexpensive is also what makes it inexpensive to publish software.
There's an easy way, I'm amazed you haven't said so in the answers above.
Move the copy protection to a secured area (understand your server in your secure lab).
Your server will receive random number from clients (check that the number wasn't used before), encrypt some ever evolving binary code / computation results with clients' number and your private key and send it back.
No hacker can circumvent this since they don't have access to your server code.
What I'm describing is basically webservice other SSL, that's where most company goes nowadays.
Cons: A competitor will develop an offline version of the same featured product during the time you finish your crypto code.
On protections that don't require network:
According to notes floated around it took two years to crack a popular application which used similar scheme as described in John's answer. (custom hardware dongle protection)
Another scheme which doesn't involve a dongle is "expansive protection". I coined this just now, but it works like this: There's an application which saves user data and for which the users can buy expansions and such from 3rd parties. When user loads the data or uses new expansion, the expansions and the saved data contains also code which performs checks. And of course these checks are also protected by checksum checks. It's not as secure on paper as the other scheme but in practise this application has been half-cracked all the time, so that it mostly functions as a trial despite being cracked as the cracks will always miss some checks and have to patch these expansions as well.
The key point is, while these can be cracked, if enough software vendors used such schemes, this would overwork the few people in the warescene who are willing to dedicate themselves to those. If you do the maths, the protections don't have to be even that great, as long as enough vendors used these custom protections that changed constantly, it would simply overwhelm the crackers and the warez scene would end then and there. *
The only reason this hasn't happened is because publishers buy a single protection that they use all over, making it a huge target just like Windows is target for malware, any protection used in more than single app is a bigger target. So everyone needs to be doing their own custom, unique multi-layered expansive protection. The amount of warez releases would drop to maybe dozen releases per year if it takes months to crack a single release by the very best crackers.
Now for some theorycrafting in marketing software:
If you believe that warez provides worthwhile marketing value, then that should be factored in the business plan. This could entail a very very (too) basic lite version that still cost few dollars to ensure it was cracked. Then you'd hook in the users with "limited time upgrade cheaply from the lite version" offers regularly and other upselling tactics. The lite version should really have at most one buy-worthy feature and otherwise be very crippled. The price should probably be <10 $. The full version should probably be twice as much as the upgrade price from the $10 lite pay-demo version. eg. If the full-version is $80, You'd offer upgrades from the lite version to full version for $40 or something that really seems like killer bargain. Of course you'd avoid revealing these bargains to purchasers who went direct for the $80 edition.
It would be critical that the full version shared no similarity in code to the lite version. You'd intend that the lite-version gets warezed and the full-version will either be time intensive to crack or have network dependency in functionality that will be hard to mimic locally. Crackers are probably more specialized in cracking than trying to code up/replicate parts of functionality that the application has on the web server.
* addendum: for apps/games the scene might end in such unlikely and theoretical circumstance, for other things like music/movies and in practise, I'd look at making it cheap for digital dl buyers to get additional collectible physical items or online-only value - many people are collectors of stuff (especially the pirates) and they could be enticed into buying if it gains something desirable enough over just a digital copy.
Beware though - There's something called "the law of rising expectations". Example from games: Ultima 4-6 standard box included a map made of cloth, and Skyrim Collectors edition has a map made of paper. Expectations had risen and some people aren't going to be happy with a paper map. You want to either keep quality of produce or service constant or manage expectations ahead of time. I believe this is critical when considering these value-add things as you want them to be desirably but not increasingly expensive to make and not turn into something that seems so worthless that it defeats the purpose.
This is one occasion where quality software is a bad thing, because if no one whats your software then they will not spend time trying to crack it, on the other hand things like Adobe's Master Collection CS3, were available just days after release.
So the moral of this story is if you don't want someone to steal your software there is one option: don't write anything worth stealing.
I think someone will come up with a dynamic AI way of defeating all the currently standard methods of copy protection; heck, I'd sure love to get paid to work on that problem. Once they get there then new methods will be developed, but it'll slow things down.
The second best way for society to stop theft of software, is to penalize it heavily, and enforce the penalties.
The best way is to reverse the moral decline, and thereby increase the level of integrity in society.
A lost cause if ever I heard one... of course that doesn't mean you shouldn't try.
Personally, I like Penny Arcade's take on it: "A Cyclical Argument With A Literal Strawman"alt text http://sonicloft.net/im/52