Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Perhaps the most obvious way of protecting a company's intellectual property from its own developers seems to be an NDA - Non Disclosure Agreement. Effectiveness of this approach may vary, depending on many factors, and sometimes or somewhere it may not work as expected.
What other approaches, apart from this purely legal one, exist for protecting software code from the people who develop it? Do they exist at all? Does it make sense in practice?
Maybe, for example, Team Edition of Visual Studio already contains some features related to this problem (for example, levels of access to parts of code, depending of role inside a development team or something like that)?
Reference on the topic:
As statistics says, on average, programmers tend to change their job every three - four years.
Try to build a team you can trust.
The first approach is to force programmers to only know interfaces of other components, so that each one can only steal a small part of the whole software. This approach can be borrowed from footwear production. One transnational corporation, to prevent stealing by employees, arranged its factories so that each factory produced only left or only right shoes. You could do the same with your code: some programmers only write lines with odd numbers, and the others--those with even numbers; provided that they can't see the work of each other! That's sometimes referred to as "pair programming".
Some organizations force employees to sign a non-compete agreement. That's the kind of agreement that prevents programmers to work for competitors. This technique is best combined with job postings like "Looking for senior programmer with 5 years of experience in the similar field".
To prevent your programmers from stealing, you can do harm to them as soon as they finish the software. The method proved itself as the most efficient, and has been used for centuries. For example, Russian Tzar Ivan The Terrible burned eyes of the architect that designed a beautiful church at the Red Square, so the one designed remains the most beautiful ever. You can do something like this to your architect. I heard, latest Visual Studio contains some features...
Nowadays, however, it's more humanistic to hire already blind and already dumb people that lost their hands, so that they can't look at your code to memorize it, can't tell anyone about your code and can't type it again. The advantage is that this will help you dealing with labor agency in your country, which watches for balance that your employees are not discriminated.
And yes, this post is a sarcastic joke, which criticizes the idea of any code-stealing-prevention measures. Sorry, couldn't help posting it.
How do you protect a power plant from sabotage by an employee? How do you prevent a boxer from throwing the fight? How do you prevent a brothel from distributing the clap?
Your concern, while valid, is one that can only be properly addressed by personal responsibility and accountability within your team. Any options you employ to secure the code against theft is likely do more harm than good. If you feel a team member is not trustworthy, get rid of them.
If really necessary you can split the application in subapplications.
Each team works in a single application and sees all others as "black boxes". Maybe SOA helps here.
It's highly unlikely that your code is the real intellectual property - that is your company's business knowledge and process.
SVN has the ability to limit different users to different folders, so you could split your code up into seperate libraries, and allow only certain people Read / Write access.
The file for this is under conf\authz
Here is a sample
[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average
[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
[/
# [/foo/bar]
# harry = rw
# &joe = r
# * =
# [repository:/baz/fuz]
# #harry_and_sally = rw
# * = r
Some documentation can be found here
Under 'Per-directory access control'
Either build a team of developers that you can trust, or entirely lock their system down so they can't access the USB ports, the CD drive, or web mail clients. The only thing they could do is work on the code and possibly browse the web. Also only give them access to the code that they are in charge of.
But with all these security measures chances are your developers will hate working with you and quit their job
There's no straightforward way to do this if your code is within the same project (i.e. you want to allow access to some parts of the code and not others). However, if you have seperate projects that require different security levels, it's possible to allow developers to only have code access to certain projects, and then pull builds from a common build server.
Keep in mind that decompiling of frameworks that work against IL like .NET is relatively straightforward, so preventing access to the code files is not necessarily a silver bullet to protect IP.
I know you said aside from the purely legal one, but I'd just like to add that in addition to the legal one you mentioned, there is also the Non-Compete. Basically says that once you leave your job, you won't be able to compete in any way against your former employer. Stealing code is not as appealing if you won't be able to put it to use for a year or two.
You could make them develop a module that would be seperate from the rest of the application. If you had a plugin/module type system going this would suit well. You could release APIs for the developers to develop against and have them integrate with your DLLs and not the source code.
People seem to be very critical of this but there are legitimate reasons for doing this i.e. partnering with a potential competitor if you gave them all your source you would be shooting yourself in the foot.
It might be worthwhile to spend some brain cell activity on the business model you want to follow. If the core value is embodied in the code, the core value can be stolen by stealing the code. If, however, the core value of your business is embodied in a group of employees, some of them engineers, others sales people, yet others customer support people, and when the software is only the net that keeps these peoples business going, then there's no easy way of stealing the value of your business. And if the software does get stolen, the thieves won't be able to make much use of it.
So, in addition to what cherouvim said, build a team that you can not just trust, but a team that is the core value of your business.
Develop your software in modules.
Have one common module that contains objects that pass back and forth, and utility classes that act on those objects.
Have each group build modules on top of that, without much need to know about other modules.
Have one trusted team of developers do the planning of what goes in each module, and have that team also do the integration of all of the modules into the whole.
Also have a lot of trust in whoever runs your version control server. While it's stable, no one developer can do all that much harm; they can't delete everything, for example, and you'll know exactly what they did and when if that ever becomes an issue.
One thing that I can't get my head around is the persistent questioning here, and elsewhere on the web, about disabling OS-based 'features'. People are forever asking how to disable default OS shortcuts (like copy-paste, the Windows key, etc.), or disabling features programmatically.
Surely this is very, very bad practice? To modify a user's operating environment with your program, unless it's specifically targeted at helping the used to modify their own operating environment (which, in the majority of cases I've seen, I highly doubt it). I'd never want a program modifying my bound shortcuts, or changing the default behaviour/feature-set of my environment. Is that a general consensus, or is that just me? It violates virtually every base heuristic and usability/consistency theory I can think of - not least of which, the principle of least astonishment.
The question, then, is this: Is there ever a time (aside from when aiding the user in modifying their environment) when manipulating/changing/disabling features of the operating system, or of the user's general environment, is acceptable practice? Should a program ever attempt to disable the Windows key, copy/paste shortcuts, adjust the Start button text, or anything of a similar vein, without the user's explicit permission, and without the change being fundamentally necessary to the execution of the purpose of the program?
I believe it is perfectly acceptable if you are building an "appliance" for example like the kiosks you find in bookstores. In cases like these it does make sense to disable most of the known shortcuts and features.
No.
For normal applications, where the user expects to be in control and may well be running other apps, this sort of behavior serves only to subvert the user's expectations, may damage native accessibility features of the OS, and will generally lead to frustration.
Even exceptions such as those noted by ocdecio and overslacked, though well-intentioned, may fall into this trap (how many games have you played that would crash leaving important system features disabled, or kiosks that disabled task switching but forgot to disable system notifications...) Whenever possible, developers should look first to the OS itself for support in implementing full-screen, restricted, or kiosk applications.
BTW - marking CW, very subjective.
Meta answer: It may be a good idea if-and-only-if your real reason for doing it so is in the user's interest.
And don't try to lie to the user about doing it for "security". You can count on being publicly named and shamed.
If you are limiting the user for your advantage, and not theirs, you are in dangerous territory, indeed. Crippling my machine without my express permission will get you put forever on the filter-with-extreme-prejudice list...
Yes, I think so, although it's rare and should be very temporary. For example, a DVD player disabling the screen saver, or a presentation, game, or "parent-ware" type app disabling the Windows key.
It's very good advice to avoid doing these things, but there are times when it's appropriate and even necessary.
I've seen apps (including the Windows OS, I think) that disable cut and paste when in a password text box.
I would agree that there are rare reasons, but that is is bad practice in general.
An example of a good divergence from normal interface behaviour is Ctrl-C on a terminal emulator on winblows.
In general, disabling "the normal" O/S interface features is obviously silly. Can you imagine having to search for the brake pedal in a hire car? How safe would feel about driving it off the lot? Having to search for the lights, wipers, indicators, and hand brake is bad enough... The brake pedal should be the one the middle, or the left;-) It Works. Don't Effin Eff With It!
Having said that: Neil Frasers blog systematically destructs many of the "universal tenets" of UI design by evaluating their application to the venerable TI80 programmable caclulator. The phrase "This results in an inferior calculator" somehow branded itself into my brain.
I believe consistency of interface is paramount. For instance, I use a product called SOATest. It's an Eclipse based Java app for testing SOAP (et al.) web-services. It has one very annoying quirk. Ctrl-Insert and Shift-Insert don't work in any of its text areas, but they do work in many (not all) of its text-boxes. If those keys consistently didn't work I would adapt far more readily. I find this little quirk terribly annoying because (to me as a professional programmer) it represents "just plain ole sloppy work".
So... Keiths first rule of UI design: Whatever you do, FFS do it consistently! Your users are smart, they will adapt.
Cheers. Keith.
I find that most of microsoft's new programs are very hard to use.
Microsoft Office 2007 (word especially) I find to be hard to use.
Microsoft IIS 7.0 is a PAIN, I never remember which icon to click on, things are just to cluttered and hard to find.
As a programmer, we have to design according to what people are used too, what exactly is MS telling us to do?
we have to design according to what people are used too
Well that's a slight misconception. You're not wrong that people familiar with something will appreciate the interface remaining familiar, but not all change is bad. You have to weigh the power of the change up against the harm it does to veteran users.
Lets take Office 2007 as an example.
The ribbon interface is a huge departure from the interface Office has used for as long as I can remember but there is sound logic behind it.
User functions are grouped by activity and it's very easy to change which set of functions you're looking at.
They're also contextual so some thing only show up when you're on a table or an image (etc).
These both help keep the clutter down - something really quite useful as these apps grow in feature-sets. Rather than spending hours choosing and customising a set of toolbars, you have access to everything through the tabs.
And Microsoft did this all the right way. They tested the interface on lots and lots of real people. They listened to see what worked and what they should fix or drop. They also kept some legacy keyboard shortcuts for seasoned pros.
The redesign effort was targeted at making life easier on beginner and intermediate -level users. Mission accomplished. The problem you're having is overcoming your familiarity but I can't be more helpful than say: It'll happen in time, but you'll manage it in the end.
Look, I'm just a simple caveman, scared by your post-modern architectures and vroom vroom machines go honk. I'm used to the simple life of the paleolithic era; charcoal cave paintings and bone-based technology. I can't make heads or tails of your fancy ribbon UIs and pointy-clicky icons. That's why I'm never upgrading from DOS. The old ways were always the best, and learning new ones bad like fire.
Well, Microsoft has to balance this. On one side, users scream for new features and change-for-change's sake in a lot of MS software. On the other, lack of backwards compatibility (including subjective UI compatibility) is a deal breaker. Really no way to win there.
That said, I don't think we need to design according to what people are used to; neither does Microsoft. Change will never happen if we just do what has always been done before. IIS is not developed for programmers; it's developed for IT people. And the new interface serves them well. Likewise, Office is designed for office drones, not programmers, and the new Office is very discoverable for that particular group.
I think they take a while to get used to, but I do like them. (Althought I will fully admit I am a mac person and I like the mac UI a lot better).
The biggest thing I've seen about the UI that is difficult is the fact that it is so much different from previous versions (I'm talking about the current version of Office). That seems to be where most of the rub is.
The rule I was taught about UI design is that things need to be familiar to the user (that's really is what makes it "intuitive"). MS broke that rule ......but from a business perspective they are allowed a little leeway when doing this simply because they control so much of the market share. Ultimately, they know that a radical change won't cause a loss of much market share because for most people and businesses there isn't a real viable alternative. (I know there is open office, but migrating a mid to large office to it will cost as much money or more as it will to just continue using the same product).
Do we have to design according to what people are used to, yes we kinda do. Does this mean we have to make it look like what MS is doing now, not necessarily. What we have to do is create a design the users can relate to. They have to be able to make a jump of logic from what they know already to using the products we create. If not, they most likely won't use the application unless they are absolutely forced to.
User interface and user experience are totally separate concepts. (Simon Guest; User Interface Blog.)
Microsoft did quite a bit of research in the raw usability of Office 2007, and found that while there is a learning curve for people like yourself, or me, who are experts in the tool, newer users and non-experts experienced much greater discoverability of more advanced features, and wound up using more of the application's features and power. Yes, there is a learning curve if you knew Office 2003 inside-out (which, frankly, few of us really did).
Now I'm not making apologies -- Microsoft's UIs haven't always been easy to use, and sometimes they fail miserably. (Personally I think not standardizing all of their office products on the Ribbon is a classic example -- there's a large context switch in my brain when I open Project or Visio, compared to when I open Word.)
As for what developers are "supposed" to do: Bear in mind that the ribbon isn't ideal for every scenario. If you're using it as a glorified, prettified toolbar, it's being used incorrectly. It's designed to help you organize literally hundreds (if not thousands) of commands in a way that makes them discoverable to your end user. It's supposed to reinforce the traditional experience of discovering the abilities of your application in a safe way (see any edition of About Face), when the depth of your application is too great to function within menus.
Aside from that, bear in mind that we should generally be making the most appropriate UI for our own audience, as Microsoft is attempting to do for its own audience. Again, we may find these things more difficult to use, as we are used to doing things a set way -- but it's the right thing (typically) for Microsoft to do. Remember that we programmers are not the target users of most UI. (How many of us turn off visual themes, for example? Now how many normal end users? BTW, I don't fall in that camp; I'm one of the few who actually finds Vista moderately attractive.)
Again, at the end of the day, what Microsoft does matters only to the extent that it becomes what your users expect, and then only if you can't educate them that "your way" is better. In any event, if usability is truly critical for you and your users, it's time to invest in usability testing and ensure that your application really is as usable as you think it is. And start reading usability sites. (You don't have to agree with them all, but understand them.) Here are some samples:
AskTog (Bruce Tognazzini, inactive but the archives are a treasure trove)
UseIt (Jakob Nielsen)
jnd.org (Don Norman)
Office User Interface Blog (Jensen Harris)
Microsoft Windows User Experience Interaction Guidelines (The holy word on Windows)
It's interesting because there was a lot of talk about the usability testing that went into the design of the Ribbon controls, but along with almost everyone else I know I find them very difficult to use. I keep losing controls that I need and not being able to get them back until I've cycled through another three or four document views looking for them. I instinctively move my mouse to menus that no longer exist.
I wonder if they would be easier to someone not accustomed to the earlier office products- maybe this is who they did their usability testing with. I don't think the design of the new interfaces is bad as such, but it is different enough that for those of us who don't spend our whole time staring at Office but have been using the product for a long time it makes life difficult. I guess most real power-users would be doing most tasks from keystrokes anyway which presumably haven't changed too much.
The business problem is really that they need an incentive to upgrade and so they keep adding new features ( who do you know that uses all the features of Word ) and then they need to find ways to present those without making the application impossibly cluttered, which was certainly happening in the previous version of Office.
I'm not sure what we take from this as developers- maybe it's that we should design for usability from the start or find ways to make the transition between old and new functionality as easy as possible for our existing users.
Microsoft IIS 7.0 is a PAIN
I'm relieved to hear that others have found the new IIS UI a challenge. I stumbled into it without being forewarned, and was completely discombobulated. There is so much clicking around. You have to memorize where the feature is, or click and click. I don't know of a way to see all of the IIS settings at once (not that you could before, either, but at least you could stay in the single tabbed dialog).
I think it is really hard to adapt to an entirely new UI when you are so familiar with the old one. I am similarly disoriented by the ribbon menus. More clicking around to find the features. And not everything is in the ribbon. Some is in menus accessible from other entry points, such as file properties.
For new users who never saw the old UIs, it probably isn't so much of a problem.
I guess what I really dislike is having to spend the time learning the new UI, at the least convenient time. There is an immediate loss of productivity when you have to learn the new UI. You can't just drop into IIS, configure the website, and be on your way. The first few times, it's going to take a lot longer. Maybe with growing familiarity, we will come to like the new UIs better.
I wish they had given the option to show the menus for us old fuddy duddies.
I had a meeting with one of the Microsoft Office guys last year when I brought up the same points. His point was that the number of features had grown so much that a new method of displaying them was required. I was not entirely convinced and found it amusing that Microsoft are so touchy about the problem that he had a very nice, well-prepared PowerPoint presentation to give to try and explain it.
MS is trying to give users more power by being able to click this to do this or that and try to make what others may see as very advanced functions simpler to use and more powerful than the previous ones. I remember going from IIS 3.0 to 4.0 where suddenly, there are all these new buttons to click and things are different but it is kind of better. I also remember going from Windows 3.11 to 95 having its own shock of updating things.
Did you ever try watching a movie on VHS and on DVD or go from cassette to CD? Remember how the DVD suddenly had all these new features like chapters, no need to rewind, bonus features that you could just go to and not have to fast forward to find? Similarly how a CD organized things so much better than a cassette? Another point would be to look at TVs where it used to be very few options on a TV: There were 2 dials, the power and volume where combined into one place, and a few other knobs were all we had but now you have TVs where you can store favorites, closed captioning options, sound setting, and color style that could scare some people that remember the old days where you had to physically pull a knob to turn on the machine.
I find that most of microsoft's new
programs are very hard to use.
If you feel so, do yourself a favor and change to Mac. I did it and wont go back to windows. So much time wasted to achieve little things with Windows.
And Apple has Style Guides for GUIs. You dont have to stick to them, but as far as I can tell most developers do.
To prevent a Mac-Windows-Flamewar I would like to point out that this is totally my opinion. Please dear Windows user, do not feel attacked by my opinion.
I work in a very small shop (2 people), and since I started a few months back we have been relying on Windows Scheduled tasks. Finally, I've decided I've had enough grief with some of its inabilities such as
No logs that I can find except on a domain level (inaccessible to machine admins who aren't domain admins)
No alerting mechanism (e-mail, for one) when the job fails.
Once again, we are a small shop. I'm looking to do the analogous scheduling system upgrade than I'm doing with source control (VSS --> Subversion). I'm looking for suggestions of systems that
Are able to do the two things outlined above
Have been community-tested. I'd love to be a guinae pig for exciting software, but job scheduling is not my day job.
Ability to remotely manage jobs a plus
Free a plus. Cheap is okay, but I have very little interest in going through a full blown sales pitch with 7 power point presentations.
Built-in ability to run common tasks besides .EXE's a (minor) plus (run an assembly by name, run an Excel macro by name a plus, run a database stored procedure, etc.).
I think you can look at :
http://www.visualcron.com/
Consider Cygwin and its version of "cron". It meets requirements #1 thru 4 (though without a nice UI for #3.)
Apologize for kicking up the dust here on a very old thread. But I couldn't disagree more with what's been presented here.
Scheduled tasks in Windows are AWESOME (a %^#% load better than writing services I might add). Yes, not without limitations. But still extremely powerful. I rely on them in earnest for a variety of different things.
If you even have a slight grasp on c# you can write as custom "task" (essentially a console application) to do, well, virtually anything. If persistent/accessible logging is what you're after, why not something like Serilog or NLog? Even at the time of writing, it had a very robust feature set. This tool in and of itself, in conjunction with some c#, could've solved both your problems very easily.
Perhaps I'm missing the point, but it seems to me that this isn't really a problem. At least not anymore...
If you're looking for a free tool there is plenty of implementations for the popular Cron tool for Windows, for example CRONw. It's pretty easy to configure and maintain. You could easily write add custom WSH scripts to send your emails and add log entries.
If you're going commercial way BMC Control-M is arguably one of the best but I don't believe that it is particularly cheap.
You may also consider some upcoming packages like JobScheduler
Pretty old question, but we use Jenkins. Yes its main purpose is for CI\CD, but its also a really nice UI for CRON with a ton of plugins and integrations.
My dad always says "Responsibility without Authority is meaningless".
However, I find that as developers, we get stuck in situations all the time where we are:
Responsible for ensuring the software is "bug free", but don't have the authority to implement a bug tracking system
Responsible for hitting project deadlines, but can't influence requirements, quality, or team resources (the three parts of project management)
etc.
Of course there are tons of things you could say to get around this - find a new job, fight with boss, etc....
But what about a technical solution to this problem? That is, what kind of coding things can you do on your own without having to convince a team to correct some of these issues - or what kind of tools can you use to demonstrate why untracked bugs are hurting you, that deadlines are being missed because of quality problems, and how can you use these tools to gain more "authority" without having to be the boss?
***An example - the boss comes to you and says "Why are there so many bugs!!?!?" - most of us would say "We don't have a good system to track them!", but this is usually seen as an excuse in my experience. So what if you could point to some report (managers love reports) and say "See, this is why"?
All you can do is your best, don't feel as if the key to successful software is only in your hands, your part of a team and don't have to be responsible for all.
Obviously you are in a environment that affects negatively your software, but can't change all his behavior so I recommend you start with yours, start working as a team of one with your own bugs, deadlines, requirements, quality and resources don't bother for the rest of the mess, but try to be the best at your work.
Working as a self-directed team of one showing your boss your plans, and reports of your progress, asking for more resources when you need it and showing him how your plans get affected when he give them to you or not.
You can find more advise about this in the PSP and TSP articles of wikipedia
After showing your boss a good work and meeting your own deadlines, surely he will trust you more and let some of your ideas flow to the entire team.
You don't need a bug-tracking system, you need automated tests: unit tests or otherwise. You can set-up automated tests with a Makefile. You can always find paths that are blocked by management, but that doesn't mean there aren't things you can do within the constraints of your job. Of course, the answer could be "find another job". If you can't find another job now, learn some skills so that you can.
The simple answer is -- you can start using the tools yourself.
Improve your own work. If people want you to fix code, tell them to file a bug. Show them how. Make sure they can do it without installing anything. They want a status update? Tell them to check the bug. They ask abou a code change you made? show them how to make a source control history query. or just show them on your box. Start showing them this stuff works.
And when you need the same results from them, demand that they do the legwork. When you can't find the changes in your source control, ask them to start diffing their revisions manually from the backup tapes. Don't do their work, or the work of source control and bug tracking, for them.
And most importantly, when applying this peer pressure, be nice about it. Flies and honey and all.
If they don't get it, you can continue to be the only professional developer in your company or group. Or at least it will help pad your resume: 'experience setting up and instructing others in CVS and FogBugs to improve product quality' and the like.
As for specific tools for showing that untracked bugs are hurting the team's ability to produce quality code, you've got a catch-22 here since you need something to track bugs before you can show their effect. You can't measure what you can't track. So what to do?
As an analogous example, we recently had a guy join our team who felt the way we did code reviews via email was preposterous. So, he found an open source tool, installed it on his box, got a few of our open-minded team members to try it out for a while, then demoed it to our team-lead. Within a few weeks he had the opportunity to demo it to all our teams. The new guy was influencing the whole company. I've heard lots of stories of this guerrilla-style tool adoption.
The trick is identifying who has the authority to make the decision, finding out what they value, and gathering enough evidence that what you want to implement will give them what they value.
For a broader look at how to lead from the middle, or bottom, of an organization, check out John Maxwell's The 360 Degree Leader.
If you want a report about quality and it's impact on productivity - here's the best:
http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html
Caper Jones has a few books out and is still showing up at conferences. Outside of a good IDE a developer/IT group needs source code control (VSS, SubVersion, etc ) and issue tracking
If an accountant is asked to produce a set of account without using double entry and don’t balance, no one would expect the accountant to do so.
However double entry has been in standard usage by accountants since about the 13th century.
It will take a long time before we as a profession have standard practise that are so ingrained that on-one will work without them.
So, sorry I expect we will have to face this type of problem for many year to come.
Sorry for not answering your question directly, but...
I feel strongly that the failure you refer to is one of communication, and it's incumbent on us as professionals to develop our communication skills to the point where we are respected enough and trusted enough to leverage the authority we need to improve our working environments and processes the way you suggest.
In short, I don't think there is a technical solution that can solve all the problems created through poor communication in the workplace.
If anything, technology has caused the attrition of direct face-to-face communication.
Sorry, I'm off on a tangent again - feel free to downmod.
Coding only you can only keep your own source files tidy, well commented, keep the bug count low with tests. But you are going to need external tools for tracking progress and bugs (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, a blog, whatever). In these cases the people and the discipline and the good habits and the leadership are the overwhelming force, no software tools and no offert from the individual can win alone.