BOUNTY: To get bounty either show me how to play the system, or explain why you think it's impossible to play it.
I'm developing a reputation system for a site that allows you to start your own blog of sorts, and to comment and have favorites etc.
I aim for a very short ruleset that is easy to understand for the users and can't be "played". Note: when I write "answers", I mean answers to comments, which is
the equivalent of Stack Overflow's comments to answers.
To create an account you need one Mojo. Without it you can only answer other people's comments.
When you have an account, you get one Mojo a day.
Each day you can only post as many posts and comments as you have Mojo. You can answer as many comments as you like. You don't lose Mojo when you post.
You can give one Mojo to someone who has less, but only once to each person.
Alternatively, you can burn one Mojo to take one Mojo away from someone who has less, but only once.
You can't have your Mojo back.
The site is supposed to be invite-only, but non-members can answer member's comments, and maybe they'll be able to start their own blogs too, I'm not sure yet. The idea is for a system based mainly on seniority, where power can be transferred between users only in a very limited manner so basically there's no way to inflate your reputation (Mojo only flows down.)
Giving and taking Mojo is supposed to be an act on the level of marking someone as a friend or as an enemy.
I don't want Mojo itself to be a motivator for people to be part of the community. I want them to use it to influence how other people behave on site. By burning someone with your Mojo you effectively limit how much they can post on the site. By giving someone Mojo you allow them to express more.
I'm also planning to add ways to get extra Mojo, like "Post of the Day" or "Favorite Blog of the Week" contests with prizes of around 3-10 Mojo. But one of my main goals is to avoid inflation.
Here are some consequences of your design. These may or may not be what you intended, but I point them out so that you're aware of them.
A very Mojo-ful user who has been mostly quiet is not going to care at all about stepping on some toes, because they have a huge bank of Mojo from which to draw. This seems to go against your goal of limiting negative behavior.
Likewise, users who contribute absolutely nothing to your site still get Mojo just by virtue of having an account. But an otherwise valuable contributor who makes one off-color post that's disliked by the community will be silenced until he has enough Mojo to post again.
If someone has something very valuable to contribute, he has to make sure to have "reserve Mojo" at all times -- that is, he must ensure that he isn't at his posting limit. If he doesn't, he might lose the opportunity to say something useful that would earn him more Mojo.
The rate at which people can accrue Mojo is limited by the size of the community. If there are few people who are handing out Mojo, pretty soon they won't be able to hand out Mojo anymore, since there won't be anyone left who hasn't already received Mojo from them.
The oldest users will effectively become an invincible cabal whose ideas may define and shape your site. Since you can only reduce someone else's Mojo if they have fewer Mojo than you, these users can make statements your community vehemently disagrees with and have their Mojo ratings remain intact.
In general, by restricting the supply of Mojo, you have created an economic system in which people will probably be more hesitant to contribute to a discussion. They will need to more carefully weigh what they say, since a post that is disliked by the community may prevent them from speaking further if they get too much negative Mojo.
Playing the system
Either show me how to play the system, or explain why you think it's impossible to play it.
Suppose we define "playing the system" as "artificially changing the value or quantity of one's Mojo in ways you didn't intend". I would say your system is safe from artificial inflation of Mojo, but at the cost of stifling discussion that would have otherwise taken place. You must be able to make the following guarantees:
Flow condition. Mojo only "flows down"; it is not possible for a lower-ranked user to transfer Mojo to a higher-ranked user.
Creation condition. It is difficult for users to take actions which can generate their own Mojo. Also, it is either impossible to make new accounts, or they carry such a heavy penalty that no one will want to do it.
For example, if you cannot satisfy the creation condition, then malicious early users will simply make an army of new accounts. They keep a number of these new accounts in reserve, quietly accruing Mojo. They then use them as a "bury brigade" to drain Mojo of factions or ideas they disagree with. Although they will lose Mojo when they do so, the collective Mojo of the bury brigade will be constant as long as they don't go hitman on more than a single hated foe per day.
This is clearly not what you intended.
Artificial deflation
However, your system is not safe from artificial deflation of Mojo. To see why, imagine that users stream into your site to accept their invitations. Imagine a user, Mallory, with k Mojo points. Because Mojo can only flow down, there is no way for a user with k or fewer Mojo points can express their disagreement with Mallory. Only users with k+1 or more Mojo can do so.
Mallory's reign of terror will continue unchecked unless there are enough users with k+1 or higher Mojo. In fact, if Mallory is an early enough user, there may not be any users who have the power to reduce her Mojo. Indeed, because you've artificially made Mojo scarce, they may not want to burn a Mojo to express their opinion, given how precious each Mojo point is -- since that also weakens them and makes their opinions more vulnerable to attack.
In short, if there are enough (or maybe even just a few) Mallorys, you will be reduced to playing traffic cop and cleaning up after Mallorys instead of improving your site. The system can no longer be self-policing. Each Mojo point has now become worth much more than before, because people will see from the example of Mallory and her ilk that it is better not to burn a Mojo to open oneself to attack. Thus, Mojo deflation.
This is also clearly not what you intended.
The flaw in your system is that it focuses on length of membership, not quality of contribution. An inactive user who contributes nothing gains status simply by virtue of having joined a long time ago.
Why do you want to limit the amount of content users can post? I'd suggest a simple system that lets other members flag a post as "bad" (just like SO). Once a certain number of members (say 5) all mark the post as "bad," it is automatically removed. Members with too many "bad" posts are booted off.
I have a long answer, but the summary is: your system does not get rid of the bad users, but only delayed them from doing harm.
...can't be "played"
Giving and taking Mojo is supposed to be an act on the level of marking someone as a friend or as an enemy.
I want them to use it to influence how other people behave on site.
The only way to see if your system is secure is to be evil and game it. Stackoverflow is full of nice people, but for this question to be answered, its best to think evil thoughts.
/me wears goatee
To create an account you need one Mojo. Without it you can only answer other people's comments.
Hi, I'm MrValdez. I'm a nice guy. Here's some friendly answers to your comments.
When you have an account, you get one Mojo a day.
You can give one Mojo to someone who has less, but only once to each person.
Hey, this is a cool site. I'll invite my friends over.
/me creates dummy accounts and give them Mojo.
Hey, here's a blog post. What do you guys think?
/me logins into dummy accounts and post like crazy.
You can only post as many posts and comments as you have Mojo.
You can answer as many comments as you like.
You can't have your Mojo back.
Via a post or private message: Awww man, I'm out of Mojo. Can you give me some so I can answer [dummy account #1]'s post? His post is awesome and I got a great response which I think he'll enjoy.
"Post of the Day" or "Favorite Blog of the Week" contests with prizes of around 3-10 Mojo.
I'll make a post and have my dummies vote me.
10 days later, I would have mojo = (number of dummy accounts) * 10 + (Number of users fooled into giving me Mojo).
/me gives the Mojo to dummy account who goes into a flaming spree. /me washes hands of the deed.
What happens next depends on your current community. They could start flaming back or they could ignore me and my dummies until we go away.
The worst case is that they will fight back and all of your planing and system would go to waste.
The best case is that they would be mature enough not to entertain the bad guy. BUT, if your current community is mature enough, why would you still need such a complicated system to encourage people to be nice?
I recommend that you should spend time building the community. In my opinion, if you want a good community, you should spend more time with the community and helping set the tone for the rest to follow.
Case-in-point: StackOverflow started with a community of programmers who are genuinely interested in helping other people. We got a great sense of community because we all have the same interest. We know the top users won't abuse their moderator's power because we explicitly gave them our trust over a long period of time (in contrast with your system where time and trickery are used to rank a person's status). And finally, the developers of the site actually posts questions and answers as well as "talk" to us via a weekly podcast.
As a (pretend) bad guy, I don't have the heart or the resources to destroy such a tight community.
updates:
To avoid having people create multiple accounts to boost their main account you can only give Mojo to people with less Mojo (and each user can only give another user Mojo once).
Same problem. I'll just have the main account give Mojo to the dummy accounts until I get almost even Mojo across the different accounts. In addition, that rule can be easily circumvent by making more dummy accounts.
The scoring on "Post of the day" type of things is something I have yet to work on.
If you want us to comment on the scoring, update your post and we'll update our answers. But my opinion still haven't changed, you're just applying band-aid to the wrong problem.
Other posters have mentioned that your system encourages idle accounts. From the point of view of a bad guy, I wouldn't want to have an idle account. I would want to get as many account recognized by the community as a legitimate account. This would cause more damage when I finally decide to attack.
There are a lot of good answers here, but I think what you are looking for is a way to "game" the system such that no user, no matter how powerful, can limit how you behave. Thus this is my attempt to game the system in this way.
Necessary precondition: Someone invites you to the site/gives you one mojo, since it takes one mojo to create an account.
Then,
I have my one mojo account.
Each day, I use my one mojo to create a new account (I "invite" them and give them one mojo).
Then each day, I use the mojo of my created accounts to create another account for each account I already have (obviously burning each accounts Mojo down to zero each day).
IE Day 1
1 account creates another account - so I have 2
Day 2 - Each account creates another account - so I have 4
Day 3 - 8
Day 4 - 16 accounts
Day 5 - 32 accounts
Day 6 - 64 accounts
Day 7 - 128 accounts
Day 8 - 256 accounts
Day 9 - 512 accounts
Day 10 - 1024 accounts
Day 11- 2048 accounts
I repeat until I have enough accounts that even the highest ranked user won't have enough mojo to silence me - instead of competing by increasing my individual mojo, I compete by increasing my "group's" mojo - If I post something and you don't like I just repost under another one of my thousands of accounts. Instead of being a bigger dinosaur I would be a swarm of mosquitoes.
It looks pretty good, but remember that some users will eventually find ways to game any system.
Hopefully you can get a vague idea about the effectiveness of your reputation system after the public beta.
So that is about security.
A problem (may be it is how you designed it to be) I see with the system is that unlike SO or any other similar community site, you need to burn your points to contribute to the system rather than gaining points for those actions.
This decision may harm the growth of content in the site. Users will think like "I have a small number of points. So I will keep it and let my reputation grow". This means that your current system does not promote growth of content in the system.
When you have an account, you get one
Mojo a day.
i don't know but getting paid for doing nothing does not make much sense
overall, i would say your system will not work out. a reputation system should be primarily based on the (good or bad) things people do and not on the number of days people have an account.
Mojo is not a currency, it's
determines your status among other
users.
that's exactly what money does ;)
I can see where you are coming from, but as long as you hand out free Mojo(s), it will be possible to game the system.
But aside from that, your system has a side effect that you probably haven't thought of:
You launch the service on Dec 31st.
MrFirstUser registers as your first user, followed by MrSecondPlace and a few others
In the following days, a bunch of others register users
On January 3rd, everyone from the first day has 3 Mojo, and everyone else has fewer. MrFirstUser writes a comment, and MrSecondPlace gives him a Mojo for it (they have the same amount of Mojo, so I assume he is allowed to do that).
Now, MrFirstUser has 4 Mojo, and everyone else has 3 or fewer.
Now, MrFirstUser has exactly (numberOfDaysRunning + 1) Mojo, and he can never get any more, since all other users have too little Mojo to give him more. The only way he could get another Mojo, would be if User 3 gave 1 Mojo to User 4, who then gave a Mojo to MrFirstUser. Beyond that, it becomes even more involved: the number of other users who would have to participate in this human pyramid of Mojo contributions increasing exponentially.
In other words, the first thing I would definitely do to game the system, would be to create as many first-day users as humanly (robotically) possible, or at least make sure my own account was created on the first day, since that would make me an automatic Jon Skeet -- since noone would ever go significantly higher than 1 or 2 above me (only prizes could help them).
To fix your system, I would do three things:
No more automatic Mojo; Mojo is earned through upvotes, gifts and special prizes only
Allow giving Mojo to all other users (if there must be a limit, cap the gifts so no more than 10% of one's total Mojo can be given to one user)
Keep the system invite-only, and penalize users whose invitees misbehave or get too many downvotes/'report user's
As far as I understand, no one can have as much mojo as someone who joined on the first day and never "burned" any. He can even do nothing and still be at the top of the mojo list. I wouldn't call this reputation, just something like seniority, and it doesn't have much correlation with achievements.
far too complicated. KISS
Is there any good reason why your reputation system exist? Joel Spolsky's Building Communities with Software mentioned that if you want your users to participate, you shouldn't be making it hard. By setting up a complicated reputation system, aren't you limiting your community too much?
In software, as in architecture, design decisions are just as important to the type of community that develops or fails to develop. When you make something easy, people do it more often. When you make something hard, people do it less often. In this way you can gently encourage people to behave in certain ways which determine the character and quality of the community. Will it feel friendly? Is there thick conversation, a European salon full of intellectuals with interesting ideas? Or is the place deserted, with a few dirty advertising leaflets lying around on the floor that nobody has bothered to pick up?
Your system is basically a popularity contest with feedback, so expressing popular sentiments will be rewarded and expressing unpopular sentiments will be penalized. This will discourage intelligent conversation and encourage the echo chamber effect that has occurred on Reddit around issues such as Ron Paul.
Also, as Paul Graham noted in a recent essay, a joke or a slogan is easier to understand and upvote than a research paper, so your system encourages simple posts.
say the maximum posts anyone wants to do is 15 in a day - that's a lot, but you only have to be a member for 2 weeks, and then there's no point in accruing more mojo because you've maxed out what you can do with it.
So at this point you don't care too much if you get more, and you'd need quite a lot of coordination to knock someone down.
Pies,
I've been thinking about reputation algorithms (that's how I found this thread).
You have to model your reputation algorithm after real world:
1) Older people are not necessarily better or more interesting, or should have more reputation points
2) Very young people can't have much of a reputation as they are new and did not contribute anything to the community that they can get reputation points for
3) Opinion / vote of a truly respectable / reputable person weighs more than that of some Joe Schmo.
4) If a bunch of Joe Schmos gang against a truly reputable individual, their combined mob opinion still should not prevail this individual's opinion
5) Possessing a lot of money (or mojos) does not translate into having a better reputation score (otherwise rich people would ALWAYS ultimately prevail over smart people).
6) Associating with more reputable members of a community passes some of their reputation juice to their friends and family (and it doesn't matter how much these friends and family contribute -- they are cool just because they know or related to someone cool).
Thus, my conclusions:
1) You can't increase reputation score based on age
2) You can "penalize" very young accounts (same as Google Sandbox), which will at least solve a problem of creating a number of accounts and immediately voting something up or down. Some time should pass until user account "matures". Maybe even as little as 24 hours.
3) Same actions (that can cause your or other members reputation score to increase or decrease) can't be same for all members. Value of up or down vote of a more reputable member should be more than of a member with low reputation, and opposite for low reputation member.
4) Even an army of members with average reputation score way below targeted member's reputation score, they should not be able to decrease this member's score. Though it would sort of make sense if their average reputation score was closer, in which case the mass effect should trigger something that we can call a revolution. (Though in history revolutions have not always result in a good thing for the communities where they happened).
5) Reputation can't be the "currency" of your site. Something else can, but not reputation.
6) If you have a friendship concept, than being friends with someone with higher reputation should automatically pass some of that reputation to you. And that should be happening if you become friends with someone you know (at least on your web site), not befriending anybody and everybody.
No reputation system is secure, without real life verification. If anonymous people can be invited then it can always be gamed, with sufficient effort and false identities.
Your aim should be to increase the cost of such gaming above the potential gain, which will depend on what your system gets used for.
The main cost you can use to inhibit power gains is forcing users to contribute positively reviewed contributions before you increase their standing.
How you do this, and how you make it difficult for them to leverage existing identities to falsely rate as positive the contributions of new identities they are trying to give power to, is the nuts and bolts of the system; and should make use of an existing user base to spot and penalise spurious false positives.
You can make use of game theory by rewarding people for being in the majority. So if A accuses B of wrong-rating, it is highlighted and lots of people get to vote on it. Those who cast their mojo on the side of the vote that ends up winning, get it back and increase in reputation for reliability (it is worth having more than one type of reputation), while those in the minority, lose a triangle number of mojo (one the first time, 2 the next, 3 the next, 6 the next, 10 the next, and so on)
Your system is impossible to game, because it is impossible to join it in the first place.
You say a user needs one mojo to join. How do they get that one mojo if they are not already a member?
Related
I am developing one small reputation system, and I faced one problem.
So, in my example I want to create a website for pictures with 4 different types of user; let's call them: amateur, good, very good, professional.
Each user can upload a picture and this picture can get rated by other users. When the user reaches certain number of points, he passes to the next level
(e.g. if he was amateur, he becames good).
Now my question is: How should I develop this reputation system?
Should I include weighted points or unweighted?
E.g. if professional user gives 5 stars to a amateur user pic, should this bring more points then when a good user gives 5 stars to an amateur user pic?
Also for negative points.
Which path should I choose? How to choose the right solution?
Is there some name for this kind of "problems" so I can read about it?
Could you address me on what should I pay attention with both solutions and what are the pro and cons?
Thank you
PREVIOUSLY READ:
I read about SO pointing system, precisely this:
https://meta.stackexchange.com/questions/57278/if-a-user-has-good-rep-on-a-particular-tag-shouldnt-his-votes-on-that-tag-weig
This answer made me think about. Which way should I choose?
This is a tremendously difficult question to answer, without knowing the specifics of a use case. Is there a reason to believe that those who have reached higher levels are more authoritative in delivering ratings to others? It may be the case. It is notable, however, that you are almost by definition creating a system which will lead to conformity - that may or may not be what you are looking to do.
There are some interesting implementation questions, if you decide to go ahead with such a system. Does the relative ranking of two individuals matter, or just the one who is rating? (i.e. if you are "good" and I am "very good", should my vote on your image be the same as if you are "amateur" and I am "very good"? or should it hold less weight in the first case since we are presumably closer individuals?)
If I rate someone when I am very good, and then later I cross the threshold into professional, does my rating get scaled by the "very good" or does it later get updated when I update?
If I am an individual who currently has no ratings by anyone, and a Professional individual rates me as Professional, should that count for more or less than if I am someone who has been called an Amateur by 100s of Amateurs, and then a single Professional rates me as a Professional? In other words, how does the variance of ratings get reconciled with the variance of weightings?
So, in some type of summary: If there is reason to believe that those who rank more highly will be better judges of how others rank, and you do not mind uniformity of the highly ranked individuals, then perhaps a weighted ranking system may work.
If you are looking to implement a weighted ranking system, then you need to decide exactly what matters. Is it the relative weights? Is it the explicit weights?
My recommendation would be to think about specific scenarios. Enumerating how this should work specifically may help you generalize a solution.
As some readings of interest:
https://www.microsoft.com/en-us/research/project/trueskill-ranking-system/
https://en.chessbase.com/post/the-sonas-rating-formula-better-than-elo-
The reputation of a voter should almost certainly influence the weight of her vote and how much it affects the votee's reputation, as long as you believe that a person's reputation directly correlates with her ability to judge the reputation of others.
Take a look at the Elo rating system and its peers (with R implementation here). Player ratings -- analogous to your reputation calculations -- depend on their opponents' ratings, not just a simple win/loss incrementing.
In my very short time working in the programming field, I've seen two extremes:
Projects where little to no planning was done and thus become maintenence nightmares.
Projects that are perpetually in the planning stages and don't move from there.
It seems like the latter oftentimes happen as a reaction to the former. Where is the happy medium? And more importantly, if a project is moving in one of these directions, what is the best way to move it towards said happy medium?
In my own personal experience, I have found that 'decisions' are my bottle neck.
If this is the case, then :
List all your design options
Pick an option(s) (pick a few if you can't decide on one)
List the risks of the best option(s)
For each risk, brainstorm a solution, then design a conclusive proof of concept and write it.
If your proof of concepts proves it will NOT work, then toss that option, and pick another one.
A 'Proof Of Concept' is a minimal app to prove something. (mine are usually 1-6hrs)
If you have a situation where 2 or more options are equal, give yourself a time limit (like 5 minutes, not 2 months) and make a decision ... any decision, and don't look back.
And trust yourself to be able to deal with any problems you will hit which you did not take into account at design time.
Initial planning should be roughly O(log n) where n is expected total development time.
If you have to push in a week, sketch something on a napkin.
If you have a month, the first day is for initial design.
If you have a year, spend a week.
This does assume that you revisit planning iteratively, and don't just go all commando-style on your codebase, without adult supervision :-).
Analysis paralysis can have many symptoms. One that I have noticed is that same questions are asked each meeting and no resolution is reached. If you can point this out to people that might be able to help them admit that the planning process is stagnating.
If you can, at the start of the project, state that you want to cover a certain percentage of the requirements in the planning stage, say like 80-90%. This way there is a clear goal and you aren't trying for perfection. You can revisit the planning and analysis later just don't let it hold things up.
I think it depends on 2 factors:
The length of the project
Is it a 1 week project?
Is it a 1 year project?
Or somewhere in between?
The risk of the changes being introduced in the project
Are they architectural in nature, potentially affecting a lot of the original code?
Or are you simply adding a new feature?
Obviously, it's a combination of the above 2 factors. It simply doesn't make sense to spend 1 month designing a feature which will take 2 days to implement and is of little risk to the architecture. I'm picturing a matrix here of length/risk/design time tradeoffs.
There was some interesting advice in Code Complete 2, which I am currently in the process of reading. I can't remember the exact wording, so I am paraphrasing here, but it said something along the lines of:
The 2 biggest mistakes you can make in a design are:
1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation
Finding the happy medium between these 2 is the key to successful design and planning.
Great questions - with no absolute answer - this is what makes experience meaningful. Experience including:
how much detail can you actually get from any user/sponsor and from this specific group
how much detail does your current team need (technical/business specific skill levels)
how open are your sponsors/users in helping during the development (how agile of a team do you have - does it include the sponsor/user?)
how good are you are identifying gaps
A big factor is the system being developed - the more 'life' critical the more details you will need (heart monitor compared to a web page).
The more complex, cost/time constrained, life-critical the more up front work - the less the more you can detail out as you do the work (prototype to production)
Personally, I've found that when good developers deal with clients, they often get sucked into the after-sales support process and this process has been difficult to reverse, so was just interested to hear the various strategies that developers employ in maintaining a healthy, useful relationship that keeps clients using the right person at the right time.
So do you and, if so, how do you deal with clients?
Just a tip: Write down every single thing a client says to you.
Most of the projects I work on are done on time-and-materials contracts, which means: we give the customer an initial estimate of how long the project will take but bill for actual hours worked, whether over or under the estimate (I don't know why a client would agree to this, but they do). Once the project is "complete" and in production, we set up a service extension to the time-and-materials contract, creating a block of billable hours to cover after-sales support. When a client is aware that they're being billed for all contact with us, they tend to keep that contact to a minimum.
One other point: I've found that it's best to communicate with clients via email where possible. It's a much more efficient way to transfer information (assuming everyone involved can write), and it leaves a permanent record of what the client told you to do.
I'd go the opposite of what have been said.
The client is your number one information source
Avoid intermediaries (human and technical)
Keep tracks (not to use it against the customers, even if it can happen, but because he pays to get what he wants)
Communicate - on your initiative - in a short regular basis but for small amount of times.
Any doubt can be cleared asking the good questions. The guy don't want that ? Get rid of it (even if you like it better). The guy want that ? Why not, add time and money on the contract.
You must train your communication skills
Most of what has been said here before is essentially related to the fact that programmers usually have poor communications skills. So they fall into the typical traps :
customers give them bad info
they waste time
they get stressed
At the end, nobody is happy.
But with trained communication skills you will learn to direct when, how long and about what your chats will be, and so :
Make any deal quick and nice
Give confidence to the client
Understands what the client wants (not what he says he wants)
Ensure is satisfied with the answer (even if it's nonsens for you)
Everybody will be happier : the customer will feel good and let you work in peace while you will have the information to keep working. Eventually, the resulting software will be better.
Think talking to customer is boring ? They think it too. And paperwork is boring as well, but you must do it, so do it well instead of looking for excuses.
This is a pain we feel as well. Once you help out a customer it is too easy for the customer to directly contact the developer later on and request support. And since we usually aim to please, and probably feel sort of responsible when the application we built for them has a problem, we too often give the customer a quick helping hand.
I think that the developers should be separated from the customers, but this requires that the company has a support/concultancy department which can fix the problem instead. They in turn should be free to contact the developer, unless it's a huge company with a mainstream application where there is a less risk that the problem can be traced back to a problem with the sourcecode.
But let me tell you, I understand how difficult this is. I've been working in our consultancy shop for many years, starting from support and now I'm mostly managing the other consultants and developing. There are a lot of customers (like hundreds) who feel they have a personal relationship with me, and assume that they can call me directly even after years and years.
My tip is to make sure you have a good network of concultants and supportworkers who can help the customer for you, and have them contact you instead if they can't figure it out.
I just finished my education and am working at my first job, but here is what we do:
I communicate through a third party from the same company with "higher rank". The third party is someone knowledgeable of the requirements the software should have, but not in software engineering. When I ask about specifications, or send them proposals he distills the essence of their answers send them to me.
I think this way of working with stuff limits the amount of bullying a customer can get away with when it comes to changing specs, expanding specs etc.
For me it's especially useful since I'm only 21 years old, and people might have trouble believing I can get things done.
best practices:
Remember the client is the one who signs the checks.
Users work for the client.
Refer any user requests to the client for approval.
Always deal with the client because they understand that everything you do will cost them money.
If the client wants after the sale support and is willing to pay for it then give it to him cheerfully.
Oh and what MusiGenesis said!
The best way is to never ever ever give your direct line to a customer. Have them go through Tech support (if it exists) first. We employ this method and it works well. The software developers are the last resort - for things that support simply can't do/don't know how to fix -- such as a DBA not knowing that the servers are instanced. But it will cut down on the "it's not connecting to the internets" type of phone calls.
You could also force all support requests to go through email/secretary. At that point, you can discern which ones are critical, and which ones can be solved with a simple 'tutorial' on how to fix the problem.
And as stated above - record EVERYTHING in an exchange with a customer. Doing so prevents the 'well he said she said' deal that customers can fall into.
Then again -- if you're getting a ton of customer support issues, you should be looking at the cause of it - whether it's a training issue, or whether the software is legitimately buggy.
In our company, every developer is also a salesman. If I step over the door of a Customer then I'm in a good position to make more business.
They know me and I have credabillity because I've allready delivered to them.
I have knowledge about their business
I use my knowledge to ask questionas about other parts in their business
I plant hooks to them when I talk to them, in their best interrests of course.
I make clear that we are not a "hit and run"-company, but there to really support their business.
Maybe this is not how all company does, but I think you should use the people you have that allready has a foot inside the customers company to really work with them and make more business and tie the customer tighter to you.
I personally think developers should never interact with clients. This is why you have the Q/A team. They get requirements, hand them to developers, discuss any issues, schedule development progress meetings. If developers have questions, the go to the Q/A personnel responsible for the requirements and documentation. Developers are engineers, not salesmen or negotiators. They should be given environment to develop stable, working code without getting distracted by customer phone calls. This is how many companies deal with customers regardless of company size. In the end, your chances of completing a project on time are higher than when you customer calls up and decides to change requirements or requests a feature. Which would probably mean you have to go back a couple of iterations and change something that may break everything completed past that point.
Lots and lots of communication. Communication can be as simple as checking in with your customers by stopping by at their desks (if you are co-located) or keeping in touch over the phone. The more personal the communication is (in-person beats phone call, phone call beats email, etc.), the stronger your relationship will be.
Another good conflict resolution practice I've used is keeping as much information as possible in a single, shared place. I've used a bug/feature database (JIRA), a wiki, and even a network share drive for this purpose, but the point is that neither party has exclusive lock/write access. Updates can be made together with your customers, and there is a clear, public record of the change history of your system.
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 have written presumably some of the first code to modify the memory of a popular new MMORPG in such a way as to create a macro framework, allowing for advanced automated reactions, skill/level gain, large scale data retrieval, and botting.
It's my supreme pleasure to automate tasks in this way, I can't help but think of any manual approach as "broken". In fact I find myself rather unable to complete even single player games before dissecting their mechanics and gaming them, in a specifically read-only (not cheats, per se) mouse and keyboard input only fashion. Supplementing my advancement toward a game related goal with my own programming knowledge seems natural, it's really not fun otherwise, like ignoring your firearm in an FPS.
Since I love this form of reverse engineering I assume others do as well, they'd appreciate the end result at least. I tend to feel a project should somehow "ship": be sold, open sourced, or freely distributed. "Happiness only real when shared." Otherwise it's just me and my timesink.
The problem is that there are several moral stances involved with a project of this nature:
An evil is released upon the virtual world. Those with the program have an advantage, the game is unbalanced, you've got to use, simply to be on equal footing. It's no longer about the game, but the tools, an arms race. It's like every other MMORPG. Therefore, keep the code private.
The above is inevitable, so release a peremptory free distribution to give players equal access to the advantage and potentially deny someone else a more evil™ (e.g. elitist, commercial, etc.) release. Between evils the least is selected, though its necessity is disagreeable.
Sell the program, reap the benefit of your proclivity, it's work for which you deserve recompensation, fair trade (and regardless of ToS violations). Follow the likes of WoWGlider. Is it better in fewer hands?
Keep the code private. Respect at least this much of the company's Terms of Service you agreed to.
What is a morally defensible approach? What haven't I considered? In my experience ToS agreements are a largely ineffective form of dissuasion, and the gaming of MMORPGs (and subsequently results described in #1) is indeed inevitable, but there's something to be said in not pulling the trigger yourself - or is it not so bad?
I did a poor job on the original phrasing/titling of this question, I was really looking to see if there were special circumstances when it could be morally defensible, not whether or not it would normally be, in hope my code could have constructive purposes.
As a new user I didn't realize 99% of the responses would be immediate, before my update. That said, I still received some very helpful answers regarding commercialization and the original question merited the answers provided, so: well done on that front.
I do have my answer: despite the inevitability of bots, don't pull the trigger yourself! Be the change, etc. (#3 was never on the table for me personally, but elicited some brilliant answers.)
You need to tread very lightly.
MMOGlider was a popular WoW bot up until recently. I wrote an addon for it in C# called GliderTools (GliderTools.net) which made a decent bit of money.
Blizzard recently sued MMOGlider for $6 million dollars and won. There is legal precedent now against the writing of bots and commercially selling them. The monetary damages associated with doing this are staggering. It worth noting that the crime Blizzard was able to get MMOGlider on wasn't "botting" but instead, copyright infringement. They claimed that because the bot client had to access and copy certain parts of the running games memory that this constituted copyright infringement.
Considering MDY (creators of MMOGlider) made less than $2 million dollars, they have a heavy price tag on their heads. Michael Donnelly the original creator and founder of MDY was not protected under his LLC license and he is personally liable for those $6 million dollars. This kind of debt does NOT go away with bankruptcy. He has it for life. Once you add on legal fees, appeal, etc this is a dangerous game.
I personally love writing bots. To me a game isn't fun unless I've dissembled it, wrote a patcher for it or automated it in some way. This what makes the game fun for me, not the game itself. Seeing your bot run autonmously for the first time is a real high. However, if you make a commercial product and sell it to others it becomes a different matter.
So, if you decide to make a bot I strongly suggest you either release it from outside the United States or keep it private among friends.
Earning money on annoying million of other players, on something that's close to be taken for illegal won't look good on your resume either.
Use your skills for good™, not evil.
Personally I see botting software for populare games, is like writing botnet worms.
You waste other people's time and efforts (and often money).
Would you write a virus to earn money?
I've been building (but never selling) bots for online poker and chess for over a decade (insert promotional web link here) so this question caught my attention. I agree with #Simucal in that you need to tread lightly, especially where MMORPG's are concerned. Blizzard in particular has a draconian stance towards automation.
4.5 million copies of EULA-compliant spyware
Then again, the idea that a private company's TOS/EULA = LAW is a bit of herdthink. The moreso when that company markets to a worldwide audience across international borders. This introduces additional complexities into the TOS/EULA, which is already a vague piece of legalistic verbiage in the first place. The common practice is to structure the TOS/EULA to make it as aggressive, all-encompassing, and wide-reaching as possible. This is just good legal sense. It doesn't necessarily mean that every line of the TOS is legally binding. A TOS is a deterrent and the company will insert whatever language they think they can get away with, and hope it holds up when/if it's tested in court.
Nothing wrong with this.
At the same time, building a bot is, in and of itself, neither morally or ethically wrong. There's a very strong and convincing argument to be made that provided your bot doesn't actually "hack the servers", you have every right to run whatever piece of software you like on your machine in the privacy of your home. This is especially the case when the servers are inundated with bots anyway, so by not running a bot you put yourself at a disadvantage. Everquest PVP (for example) has been dominated by botting pretty much since the beginning.
Anywhere, there are two important criteria to consider:
Does the bot depend on information which other player's don't have?
Does the bot enable superhuman reactions, stamina, or coordination?
This puts wallhacks (unfair information) and aimbots (superhuman reaction) firmly in the "unfair/cheating" category. On the other hand, a simple farmbot is most probably NOT cheating, because the bot doesn't have access to any insider information and it doesn't allow you to do something you couldn't otherwise have done. You could, if you wanted to, sit there for 10 hours a day and farm ore or roots or whatever. It's not much fun, but you could easily do so.
This is a good acid test for whether your use of automation has crossed the line. Trying to cheat people is a bad idea. But writing a bot to essentially ward off carpal tunnel is understandable, and it can actually be a rewarding project.
But again, I wouldn't advise actually selling a bot. Because if you make any money on it, you open yourself up to the sort of retaliation #simucal mentioned.
Just because other people will make similar bots does not make it morally OK.
These games are, at the end of the day, supposed to be fun. As you said, bots turn the game into an arms race, especially if the game has any competitive component.
Here's an example from my experience with World of Warcraft: I wanted a specific item crafted. The materials for this were hideously expensive on my server; the large number of rich players (who may or may not have gotten their gold legitimately) had pushed the prices up to a point where I couldn't afford it.
My only option was to farm the materials myself. Many of these required killing huge numbers of monsters for days at a time. One particular item had something like a sub 1% chance to drop. And almost every single farming spot was being run continuously by bots.
It's hard to compete against something that doesn't sleep or take breaks. You can't simply wait for them to go away because they don't. Because I played by the rules, my goal was made far harder than it should have been.
It's hard to have fun in the game if there are people willing to ruin your experience out of laziness and greed.
So no, I'd say it's not morally defensible. You know full well that what you create is going to harm people.
The real question is, do you have a problem with that?
If you've described your true feelings here, then the fun was in solving the problem, not in creating a product. If others appreciate this kind of thing they'll do it themselves.
In my opinion, you cannot have a morally defensible position when in order to being solving the problem interesting to you, you agreed to terms and conditions prohibiting you releasing your work.
The problem with this is that it reduces most of the game down to just one thing: end-content.
Take World of Warcraft for instance, I love playing that, and I love leveling up a character. Sure, there are some tedious points in the process, but by and large, it's fun.
Now, if I had installed a bot and just put it to work leveling up my character, at least doing all the repetetive work and leaving me with just visiting a trainer NPC and getting my new skills once in a while, then all I had left was the things I could do at level 80.
Additionally, all the skills I, as a person (not my character) should've learned along the way goes out the window.
There are two types of people that are beyond good in Counterstrike, as an example, it's the people that use bots, and it's the people that have just played so much that they are that good.
Once you resolve to using bots, you're pretty much doomed to keep using them, and trying to automate your end-content playing as well, since you really don't have the experience to play at that level.
So basically, you're reducing the whole game down to a programming contest.
Even if you keep you code only to yourself, all you've proven is that you can program. You've yet to prove that you can play the game.
So in the end, what actually is the point of you playing that game then?
As others have said, there's many options available to you if all you want to do is create software to automate things.
Having said that, I share some of your joy of controlling my environment. I use regularly quite a lot of addons in World of Warcraft, but they don't give me an advantage over others in the same way a bot would. They might make it easier for me to organize my inventory, let me keep notes inside the game, or just prettify the user interface, but in the end, it's still me that pushes the buttons in response to game events.
And that's what gaming is about for me.
Progression requires unethical choices. My advice is Go Ahead and "reap the benefit of your proclivity, it's work for which you deserve recompensation [...]". Why are you ever worried about this? Release the hounds and let others fight it if they can. Take a history book to see thousands of similar decisions made. It pushes humankind forward.
I'm a big multiplayer gamer myself, and played so many MMORPG.
When I see someone cheating in an online game only one sentence is out of my mouth "What a wank*r!"
Morally it's wrong to mess up other people's fun, and if you try to make money out of it it's not any better than running a SPAM company.
To be honest personally I don't care about farming bots, playing a game which requires constant farming sounds stupid to me anyway. But still there lots of people out there who cares, and you these tools definitely spoiling their fun.
I understand it's a fun challenge, keep it private have your fun, tell your friends and show off, but do not kill other people's fun.
In my opinion a ToS holds no one back [...]
So, by using the MMO, you agree to the ToS; but it's OK to break the rules, because you don't agree with the ToS? Nice doublethink, but the court would probably ROFL at such argumentation.
You see, the basic idea of ToSes everywhere is "it's our way or the highway" - by using the service, you agree to play by the service's rules; if you don't like the rules, nobody is forcing you to use that service, you can freely walk away.
Also, don't try to be "clever" and release the bot in Elbonia just because its jurisdiction allows that: the ToS probably states that server's jurisdiction applies (which can bite you if you ever decide to visit the country in question, or even another country which has extradition agreements with it).
Disclaimer: IANAL
If you been following the Blizzard versus MDY case, and the recent outcome, I would strongly recommend you to keep code in private if you're located in the US, or any country with Intellectual Property laws.
Also #3 , selling it will only get you into trouble. MDY went bankrupty, is not allowed to sell their product anymore, had to hand over the source code, and pay Blizzard 6 million USD in damage.
The author, Michael Donnelly, is likely to end up in dept for the rest of his life.
I recommend you keep it private.
As opposed to Blizzard and WoW, take a look at Ultima Online and OSI as to they allowed 3rd party tools, and even supported them (Tugsoft's UOAssist).
To me it's morally fine, if the game is designed in such a way that grinding one thing only leads to grinding another thing, and if the grinding in general is done in really unpleasant manner then, hey, why not? If it's allowed, everyone has an equal chance, as everyone can use the particular supported 3rd party product, this is a chicken-egg question.
It's mostly forbidden because it reduces the time you need to spend in the game, effectively reducing the time you're paying them for their service, so, greed or fun?
As a sidenote, I'm all against unattended macroing, it's a huge difference between attended and unattended.
Yes, it is fun to reverse engineer games and to do automation. From your question it sounds like you're asking where to go from there.
A) It violates the ToS, so you shouldn't use it yourself.
B) It violates the ToS, so you shouldn't sell it.
My impression is you're looking for an OK to do one of those two things, while admitting that the fun was in writing it. I would suggest you take the entertainment value from writing things for what is, and assume your "fun" time is not worth any money. Particularly at the expense of others.
The ToS holds no one back? Check with Blizzard, they are not pleased by such things It's definitely in their ToS not to run any programs that mess with WoW). The companies running these MMO's try pretty hard to stop such programs because they lead to unfair advantages and ruins the economies.
If you like doing these kinds of things, you can also look at non-MMOs. There are plenty of games (e.g. TES:Oblivion and Fallout 3) that have very active modding communities which are tolerated and even supported by the game developers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Suppose you're working on an enterprise project in which you have to get management signoff in order for you to develop a new feature set. Usually your management has no problem signing off on some bright shiny new UI feature. Unfortunately they have a hard time appreciating some behind-the-scenes issues that are crucial to the application's well-being such as transactions, data integrity, workflow routing, configurability, security, etc. Since they're non-technical and these issues are not immediately visible, it's not obvious to them that this is crucial.
How have you convinced them that these infrastructural issues have to be dealt with and that it is important to their business process?
Every craft has its unsexy sides. Things that HAVE to be done, but nobody notices them directly. In a grocery store somebody has to organize how and when to fill the grocery shelves so they always look fresh. In a laundry you need somebody who thinks about how the processes should be optimized so that the customer gets his clothes in time.
The tricky part is: The customer won't notice when these subtle things have been done right UNTIL HE NOTICES THEY ARE MISSING! Like when the laundry is not ready on time but two days late, or the veggies in the super market have brown spots and look terrible.
Same goes for IT. You don't notice good transactions until your major customer knocks on your door and tells you that an important and expensive project has failed because the database entries of your product were mysteriously mixed up. You don't notice good security until customer credit card information shows up in Elbonia (and soon after word is in the national newspapers warning customers of your company).
The thing you really have to hammer in again and again and again is that software is NOT static. It has to be cared for even after its initial development phase is over. It is not just a product you buy once and forget about. Every car manufacturer knows that services is of prime importance to the products they build, simply because things WILL occur that have to be fixed and improved. It's the same with software.
So make a presentation, visualize, verbalize, translate your technical information into benefits. Business people don't care about your wish for code aesthetics in a refactoring project, but they WILL understand that your changes will help the product to become more reliable, gain a better reputation and reduce the amount of future service requests. Make them understand by showing them the benefits!
Same thing folks have been doing for thousands of years: draw pictures. Diagram the problems, use visual metaphors familiar to your audience, drag the problem into their territory.
Assuming they're not being intentionally obtuse...
A big +1 for analogies and metaphors. If possible, find one that will resonate with the personal interests of your audience (if it's 1-2 people). For general metaphors, I often find myself using commuter traffic or subways, for some reason.
e.g. We are currently migrating an app from an OODB to Postgres/Hibernate: the bulk of this work is done in Release '4'. Many domain experts have been asking why there are so few user-facing features in R4. I regularly tell them that we have been 'tearing up the city to put in a subway. It is very expensive and undeniably risky, but once it is done, the benefits in R5+ will be astounding, truly.' The true conversation is more involved, but I can return to this theme again and again, well after R4. Months from now, I hope to say "You asked for X and it is now very easy -- precisely because you let us put in that subway back in R4".
The surest way to get upper level management to buy off on development work is to present it in a quantifiable way. Ideally this quantifiable measure is in $$. You need to explain to them the consequences of skimping on data integrity, security, transactions, etc. and how that will affect the customer\user community and eventually the bottom line. You should be careful in these situations because sometimes management expects these non-functional requirements to "just work." If this is the case, you should either estimate high and work on these items alongside the visible UI work (ignorance is bliss) or you need to document these areas of need as you communicate with management so if things do go bad as you anticipate, it's not your job that is on the line.
Unfortunately, it usually takes a disaster or two before this stuff gets the attention it deserves.
It really depends what your management is like, but I've had luck with good old honest-to-goodness fearmongering. If you go through a couple of disaster scenarios, and point out someone's going to get blamed if they occur, that can be enough to make their arsecovering instincts kick in and finally pay attention :)
Car analogies.
Everybody knows that 'system' and it's sufficiently complex to depict the dire situation.
I'm battling with essentially the same kind of situation. Whether it is sign-off by management or acceptance by a user/sponsor, the problem remains one of different vocabularies, priorities and perspectives. I asked a simmilar question here.
I also got diverse answers, tantalizingly close to useful, but not quite definitive enough. Browsing and searching SO using relevant keywords led me to find usable insights in various answers spread out over many unrelated questions. To find and extract these gems led me to pose this question on site-mining.
It would have been useful to be able to flag the various answers and see them all in a single list, but alas, that functionality is not yet available in SO. I suggested it on uservoice.
Hope you find something you can use from the references I gave.
The right kind of countering question is the secret.
Is it okay to crash every 5 web pages?
Do we have to protect the credit card numbers?
Is is okay to have to pay contractors to deploy a patch every weekend?
Did you want it now or did you want it to work?
Robustness. When it comes down to it, you need to talk their language, which is how it affects their bottom line. If its a security or correctness issue, you need to tell them that customers aren't going to want incorrectly acting products, no matter how nice they look.
I like the idea of Technical Debt, because it enables technical issues to be translated (albeit loosely) into money issues -- and money is something most managers do understand.
Although the idea of technical debt was originally applied to architectural issues, it can be used more broadly for any type of situation where there is pressure to take a shortcut -- that is, go into technical debt -- rather than do it right the first time. (Doing it right is the equivalent to saving up to buy something -- it takes time -- rather than buying it on credit and going into debt.)
Just as debts can be good (e.g. home loans) and bad (e.g. credit cards), so technical debt can be good and bad. I won't try to characterise the differences completely, but good technical debt can be tracked accurately, so that you know how much in debt you are.
So, try to explain your important, non-UI problem in terms of technical debt, and the cost of not fixing it in terms of paying interest on that debt.
A descriptive picture really helps non-technical people understand what you are talking about. For example, below is an example from Sun describing how information is processed in one of their somewhat complex applications.
(source: sun.com)
Trying to explain this application in words would be impossible to a non-techy. Pointing at the diagram and say look, this part is our weak point, we need to improve it. That will make sense to them. If they feel like they have some understanding of what you are doing, they will be far more willing to support your request.