People for hire that are paid to perform activites in the world wide web.
I see them most in regular comments who create comments with links to other websites. Today, these posters-for-hire use bots to electronically post these sites. Current counter-measures include simple tests like input words from images, spam filters, and community opinion. Each have their pros and cons, and none eliminates these types of comments.
With the growing industry in product reviews and other public opinions, there are now posters that post reviews that are not their opinions. Jobs for these posters include posting positive reviews to the clients' products, posting negative reviews to the clients' competitors. These are harder to track and easily misleads the general public who
still believe most if not all information on the internet is true. Currently, the only countermeasure is to review the reviewers. There are patterns to these posters like uses the same wordings to describe products, uses very general descriptions that can be used for a wide range of products, higher volume of posts, etc. But like a friend's opinion that has been bought, certain opinions are nearly impossible to spot.
Besides reviews, many other social networking sites can be used to redirect traffic. Use of twitter, link farms, private/public sites, facebook, even less known social networks provide many sources where information may appear legitimate.
Anonymity plays a large obstacle in preventing these nuances. There are many ways to make it harder for these mercenaries.
One method is to create a network of trusted contacts, where you can rank their "expertise" (ie trustworthiness) in certain matters and their contacts. This would require a central server so that other sites, vendors, etc. can access to provide you the most relevant information. The premise is that your trusted friends are not going to include these unknown "mercenaries" at least not that role. In other words, although one of the friends might be a fraudulent poster, (s)he will most likely not post fraudulent information under known pretenses since those will typically be under different accounts. Thus using several degrees of separation, a value can be computed to the value of certain information.
For example, I will trust an engineering friend with technical opinions, a doctor with medical opinions, etc. I may rank a close friend with their medical opinion too. If I find a friend who is easily misled by unsubstantiated claims, then their opinion will be downgraded to a lower level. I also trust a friend of a second degree of separation but not as much as close friends, but if that is the only opinion and my friend trusts them then I am more likely to trust them too. Thus the lower the value, the less the information can be trusted. The value can also increase if many of my friends also trust the same person. Also if more friends says the same thing, the more trustworthy the information.
This can also be expanded to people's profiles. If they have worked in the industry, have personal interests or hobbies in related field, had the specific injury or close family/friend who had a similar illness, etc., these can also be used to automate some factors to trust.
Trust of Information = (some constantA) * (how much I trust personA) * (personA trust in information) + (some constantB) [ (how much I trust personA's friends) * (how much personA trusts their friends) ] + [[repeat for all friends]] + ... + (some constantZ) * (unknown source)
Of course, no information can be fully trusted. This only provides a scale to filter information by. Because many activities can be automated today, unknown sources can in theory override the other values. Thus, constantZ should be constantly be scaled appropriately... and similarly with all other constants.
Wednesday, January 16, 2013
Monday, January 14, 2013
Software "Agile" Process vs "Agile Process"
Software "Agile" Process vs "Agile Process"
With all the hype with agile processes, there are many pseudo-confusion in some parts of the IT world. I say pseudo-confusion because some companies think they have an agile process but really just has an "agile" process. By process, I mean software development. By "agile" process, I mean minimum to no documentation, cutting corners, and highly-adjustable schedules.
"Agile process" is a discipline. There is a process, just like a disciplined process, but with a different structure to accommodate a much high frequency of releases. There are steps that are to be followed, see agile software development methods like Scrum, Extreme Programming, and Crystal Clear. Each stressing more importance on an evolutionary development approach.
But as I experience in my work place and speaking with other professionals, a common trend is that development managers are hiding the lack of processes and documentation by explaining that their processes are now more agile. Executives hearing the buzz-word will interpret this as a good thing and now follow through.
Whether this is intentional or not, this puts a lot of weight on keeping key players because processes are no longer transparent thus not easily transferable. This "agile" process is very developer-friendly in that documentation is often bypassed, processes are not always followed, and very difficult for others to make development teams accountable for poor quality products. Similar to how software was originally developed many years ago. Without documentation or audit trails, there is no method to track accountability to issues that arise in the future.
The projects manage to keep afloat but seem to lag farther and farther behind competitors that use a formal process. But with the growing software industry, scalability and growth is now more important than ever. Lagging due to inefficient processes will be costlier down the road if not making the project completely obsolete.
This confusion will primarily hurt the business stakeholders. Developers now have experience in the industry and thus can transfer to competitors. Development managers can claim agile methodology experience because they used the term agile. For the few that were powerless to the process, they have real experience on what worked and what failed in the "agile" methodology.
With all the hype with agile processes, there are many pseudo-confusion in some parts of the IT world. I say pseudo-confusion because some companies think they have an agile process but really just has an "agile" process. By process, I mean software development. By "agile" process, I mean minimum to no documentation, cutting corners, and highly-adjustable schedules.
"Agile process" is a discipline. There is a process, just like a disciplined process, but with a different structure to accommodate a much high frequency of releases. There are steps that are to be followed, see agile software development methods like Scrum, Extreme Programming, and Crystal Clear. Each stressing more importance on an evolutionary development approach.
But as I experience in my work place and speaking with other professionals, a common trend is that development managers are hiding the lack of processes and documentation by explaining that their processes are now more agile. Executives hearing the buzz-word will interpret this as a good thing and now follow through.
Whether this is intentional or not, this puts a lot of weight on keeping key players because processes are no longer transparent thus not easily transferable. This "agile" process is very developer-friendly in that documentation is often bypassed, processes are not always followed, and very difficult for others to make development teams accountable for poor quality products. Similar to how software was originally developed many years ago. Without documentation or audit trails, there is no method to track accountability to issues that arise in the future.
The projects manage to keep afloat but seem to lag farther and farther behind competitors that use a formal process. But with the growing software industry, scalability and growth is now more important than ever. Lagging due to inefficient processes will be costlier down the road if not making the project completely obsolete.
This confusion will primarily hurt the business stakeholders. Developers now have experience in the industry and thus can transfer to competitors. Development managers can claim agile methodology experience because they used the term agile. For the few that were powerless to the process, they have real experience on what worked and what failed in the "agile" methodology.
Subscribe to:
Posts (Atom)