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 9 years ago.
Improve this question
Well, the title's pretty much it: if I sat a non-techie/my mum/twelve-year old boy/cocker spaniel in front of you and asked you to explain actors to them, where would you start? I ask because my master's project involves them to a pretty large degree, and every other day someone asks me to tell them what I'm doing. When I'm talking to other people on my course it's not so bad—usually the concept is foreign but understandable—but recently my flatmate, a chemist, asked me to explain it to her, and to say I struggled would be a pretty humongous understatement.
I'm looking for some sort of explanation that conveys the idea, rather than the technical underpinnings. It can be a metaphor, and it doesn't have to be precise—I just want to make them understand what I'm doing with them. Any ideas?
There can be many actors. All actors act "at the same time". The concurrency is a key part of this model.
Actors cannot know what other Actors are thinking. The only way to move information is with a message. (no shared state)
Actors can receive messages, and act on them by:
doing computation with the data in them
sending messages to other actors
creating other actors.
ignoring/discarding the message.
This basically makes actors just like... People. People don't know what each other are thinking, they must send messages to convey information, they have the choice of ignoring incoming messages, considering them, or communicating with other people. Random bad things can happen to people. Lots of people all do things at the same time. To handle more load, add more people.
Regarding your masters project, I suggest finding out about the Erlang Web framework. The programming language Erlang is based on the Actor model, and is used to great effect in scalable systems including phone switches... and the Facebook messaging system.
I'll try a simple metaphor:
Actors are people doing some work inside their houses. In front of each house, there is a mailbox.
In order to communicate with each other and get work done, messages are sent between the actors.
I am not sure that this will be good one, but I'll try:
Let's imagine a classic middle-east marketplace. There are buyers(suppose they are just walking tourists) and sellers. Buyers are walking through marketplace, and sellers cry out name's of theirs goods: Carpets!! Species!!! Horses!!! Сandies!!! Jewels!!! and so on... Some buyers are not interest in specific kind of goods and go to the next store, but some buyers become interested, and ask: "How much is it?", seller: "50$", buyer:"Can you give me a discount?", and so on...
Actors are buyers and sellers here. Sellers are sending messages with types of their goods. Buyer can skip a message, or can send message for asking price.
Actor - is something we can also call subject. Actors are doing something with objects.
Actor is calls so, because it's somebody who acts.
I would say, "Actors are a simple way to tell computers to do more than one thing at the same time. They are different from other ways to tell computers to do more than one at the same time because they take fewer resources than some of the alternatives and because they are easier for programmers to use correctly than some of the other alternatives."
Related
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 2 years ago.
Improve this question
lately I've been asked to do a UI or UX audit and to be honest I truly don't know how to charge people for this... The story is that I've used some portal X and I've started complaining about how unfriendly it is and they asked me to do a full audit for them... so I did... It took me 8h of writing a doc about what things are good and what are bad - just in general, since we've agreed to sign a new contract for a detailed audit (with graphics, talking with people etc.) if they'd like the general one.
In short:
How to charge it? I can do something like: price * hours. But it's like I've used that portal for about two months so I didn't have to get to know it and I don't even know how to measure that. It took me 8h of writing the doc... I've charged them about $200 but I didn't do that kind of stuff before (not in commercial space) so I can't show any recomendations or anything... and I'm feeling like that's gotta be worth a some real cash since this is really hard and often people get it wrong... like... really really wrong...
Would be great to hear what people in the UI/UX business have to say about it.
TIA.
I am a professional UI developer, and I can tell you that we handle this many different ways depending on the situation at hand. If the job is "in the bag" then we will do a lot of the pre-planning work (not user surveying) for "free" up front then make it back on the cost of the actual work. On smaller jobs I will even go so far as to do several wireframes as part of the planning and bidding process. For some clients, I'm asked for semi-working mockups, in which case there will be separately charged "spec" and "design" phases. One million dollar account I worked on hired my team to develop the requirements to begin the planning process, which seemed a bit overboard.
I'm often asked to design or build something I've never done before, so don't let that hang you up in pricing. The important thing is to put out a quality product in the end that you're happy to put your name on. Experience is nothing compared to results.
One hard and fast rule I follow. If I can see a "challenging" client coming, which I've gotten very good at, then the charge is always billed at an hourly rate with no exceptions. I have the flexibility to "give" them a few extra hours if things are going well, but if the client begins to take advantage of the situation, I can still get paid in the end.
Regardless of the process you take, the key to success in this business is documentation. Put in writing your fee, change management strategies, warranty period, etc. GET IT SIGNED! I've been burned by clients trying to use me for a site and then inserting a low-ball contractor into the equation, so don't be afraid to spell out who will do what, when it will happen, and when deliverables are due from each person.
There are hundreds of resources about this subject on smashingmagazine.com. It's the UI person's go-to for this sort of information.
Good luck!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
What are the best practices when managing a software project involving a non-English-speaking client?
What communication issues are relevant? Would you maintain documentation in both languages (especially updating the specifications regularly)?
The basic risk in such type of projects is miscommunication, so the top priority is
validating the understanding of both parties, i.e. you should not only validate that the customer understand what you say - you must also validate that you understand what the customer says. Then, with the explicit goal of validating communications and based on the resources you have to understand your customer's language and the resources your customer has to understand your language, you and your customer shall agree on how to handle communications for the project: documentation in both languages, single points of contact, written minutes of all communications, translation of all communications, etc.
To minimize the possibility of misunderstandings, it is better to have all official communications in just one language, if possible. If communications shall be held in more than one language, you must minimize the number of communication channels, i.e. you must not have everybody communicating with everybody else: liaisons should be designated to handle all communications. Single points of contact with known proficiency on the language(s) used in the project are crucial.
Casual communications shall be avoided. All conference calls and meetings shall have written minutes describing all agreements and action items - if multiple languages are being used, all minutes shall be translated by a single party and reviewed by the single point(s) of contact.
The practices I have just described, may seem an ugly burden to bear, but they will prevent a lot of headaches.
Good luck!
My native language is not English, so I'm on the other side. There were times when we had to write project documents in 4-6 languages.
Try to find somebody who understand English (like a key person). I try to avoid the communication in different languages on a project. Of course you can talk and write on different languages with project members, but if you talk or write to all members of the project at once, it should be one language.
Documentation should be maintained in as many languages as many involved. All documents should be updated on a regular basis and try to avoid the situation when you have to tell them that "the English is the current one". Find someone who is native in the target language and translate from English for you. It will be far more better, understandable, and more native than if you try the other way around.
This might be the perfect case in which you might want to switch over to Agile development. This puts less of an emphasis on large amounts of documents and you can provide work at the end of every interval for the customer to sign off on. If you don't know what Agile is, just google it, you'll get tons of information back.
Always follow up with a written confirmation of any verbal discussion. Most people can read foreign languages better then they can speak them. It also helps to pick one language as the standard for all documents and code.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Probably an easy one:
Are there any rules of thumb or pointers that could help recognise political requirements?
Let’s say one of stakeholders (your boss, a head of another department or an actual user) asks for a feature or particular characteristic of software being developed by yourself or your team. Is there a litmus test to determine whether requirement is political?
This question is really simple and is not about how to deal with political requirements or whether they are bad or good for software. How do you tell that whatever you have been asked to do is to pursue someone’s tacit or actually openly stated political agenda?
Will it really help you to know? I mean - if you're already embroiled in political games you'll know anyway. If you're not it isn't something you'll be able to use.
If you're going to have to implement the feature anyway I'd say just get on with it. Finding out that it's part of some management game will only demotivate you.
That said - if you're working on the sort of application that's so themware that you can't tell whether it's a real user feature or a political lever of some sort then it's probably a safe assumption that everything is political.
I would say that you should assume that all requirements are political.
If you are in a situation where more than one person is responsible for determining the set of features you implement, then every feature is effectively a negotiation between those people. That negotiation makes those features political.
However, even if there is only person deciding what features ship, there is still a pretty strong chance that those decisions are political. In any organization of reasonable size (say more than ten people), you are going to have politics. The politics in that situation will differ than the "design by committee situation". They will focus on currying the favor of the person who decides which features ship, rather than on "if you support my feature, I'll support yours" that exists in the committee scenario. That process, however, is still political.
I'm not trying to say that it's not possible to have a development environment free of politics. It is. However, I would say that to pull of it off that you need:
A small, tightly knit team
A boss that focuses on creating an environment that fosters creativity, and delegating creative ownership, rather than focusing on control over the creative process.
Smart, highly talented and creative people that share a strong sense of purpose and aesthetic values.
Missing any one of those things, you are doomed to a repetitive deluge of office politics.
The best idea is to find out what all the features are to be used for, i.e. find out not only how a feature is to be implemented, but also learn why it should be done. It really helps to know the background of the desired solution. It might even allow you to suggest an alternate feature set that might better suit your customer (maybe even play your own political game).
As long as there is anything you do not understand, do not do the project. It will only cause problems at some point.
Obviously it's a tricky question and much depends on your definition of the 'political'.
I would start with the simple question:
* Are the authors/originators of the requirement really using the software in question?
The requirement could come from your boss but it could be a translated valid requirement of the real user
Here are some I've seen:
It directly contradicts other requirements
It is clearly not feasible technically
It is "out in left field" ... it doesn't fit into the defined problem space
It contradicts common sense
BEWARE ... sometimes this results from your use-cases being wrong or incomplete. I've also purposely allowed some of these to proceed to development (e.g Eye-candy that sells the product but is useless or at least generally not used by the operators).
Use the SCRUM approach. Don't describe a feature as
"It should be doing this and that in the following way"
While the sentence above describes all you need to know to implement the feature, it does not justify the feature. My SCRUM book says features should be written down as a story. A story looks like this:
"As a <user-role>
I need a <functionality>
So that I get <business value>"
A feature that cannot be justified using such a story is an unjustified feature and thus there is no use to actually implement it.
E.g.
"As a visitor of a web portal I need a way to authenticate, so I can access my customer data, but nobody else can"
Now you don't only know that you need an authentication for your web portal, you also know who needs it (the visitors, basically everyone planing on using it more intensively) and you also know why it is needed, as it gives the user some value.
Other examples:
"As a passenger I need a list of all my booked journeys, so that I know when I'm going to travel where and won't lose the overview"
"As a book keeper, I'd like to have the sales tax being automatically printed to each bill based on customer data, so that I don't have to enter it manually each time I'm printing a bill"
If every feature needs to be written like that, you'll automatically see if a feature is for the customer, because it is really necessary, or just something your boss/company wants to have and also why they want to have it (what is the big picture behind it? Why are they doing it?).
The use of ambiguous words or phrases is often political.
However,
Never attribute to malice that which is adequately explained by stupidity.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Do you use a formal event to get people talking in your IT department? Like a monthly meetup in a social place, a internal wiki/chat space or just a regular "information market" with some presentations about technology or projects made by your staff for your staff? Do you invite Sales people to participate or is it a closed event for programmers only?
How do you get people to participate in these events? Do you allow them to spent work time on knowledge transfer? Or do you understand it as an integral part of the work time?
I wonder how to monitor the progress of knowledge transfer itself. How do you spot critical one-person spots of failure in your projects? There are several methods to avoid it, like staff swapping or the "fifo" attempt on bug fixing.
Note: Ok, this is a very very noisy question and I hope to fix it after a few comments. Sorry for the mixup.
edit: My personal experience is that there is a very high barrier for people to start contributing. It looks like they won't put in the (minimal) extra time to edit our wiki, or spend the hour in the afternoon to talk about technology topics with the developing staff. It's like people don't like our wiki, our document management system or the meeting. Maybe it's because it's all free-to-use and not forced by the management. But I don't like to force people into it - but is it the right way?
One example: Our wiki holds pages about projects, telling who worked on it to get a first contact in case of questions. But nobody besides a colleague and me is creating this pages...
Knowledge Transfer and Knowledge Management have one drawback. They seem to cost an aweful lot: if everybody knows what I know, am I still needed? All the time I use to bring others up to speed, what do I gain from it?
The best way to go about this is to be an example. Share your knowledge; in a wiki, blog about it, talk about it, make it easily accessible, and talk about the benefits you have from that: less people come to interupt and ask you stuff, as they can get an answer easily without even getting up. And show them that you are still there.
This with all the other things mentioned will actually win out. One more thing: one of my employers kept on paying me 1/3 of my salary for another year after I left (on my own initiative), just to keep my knowledge-base up and running. Did he have to? No, it was his property anyway. But it motivated people still working for him to share their knowledge.
I think all of the above. But you're forgetting the most important way.
The most efficient way to transfer knowledge is to have people work together. You might think about doing 1 on 1 code reviews or even pair programming and make knowledge transfer an intergral part of the work.
I think it depends on the knowledge you are trying to transfer. I've found the following:
Technical Knowledge: "How to guide" with screenshots and a short demo - similar to the way you will see new features at a conference. The added benefit of this is what you have got is documented for when you leave the company.
Problem solving: informal discussions, short internal projects, lessons learned and an internal FAQ system which EVERYONE is responsible for updating.
Soft Skills (people skills): social meetings/outings/informal events etc.
Measuring that is going to be difficult though, as no matter how you transfer your knowledge there will always be varying degrees of uptake, after all, just because I do something one way doesnt mean its correct. Another developer/designer/manager may have a different way of doing the same thing with the same end result.
Mauro
At my workplace we use a wiki. The workplace is small enough (~20 people) so that you can always ask the person who was most involved in a particular project, however it is expected that you have searched on the wiki before you ask "the expert". If you cannot find your answer in the wiki, then you should add it after you have discussed it with your co-worker.
One word: Lunch
You should encourage people about things that you want them to do. You should "feed the animal". Look at stackoverflow; what do you think about badges? Why do you think this wonderful things exist? Thanks to ego, there is nothing you can't get it done. Give them badges, real badges, wearable badges. They will wear with happiness, they will do with happiness.
Btw, yes, I am a boss :)
Although i am still a student, when i did work experience 12 months ago, the all IT departments from within the corporation (I was 'working' for large corporation which own several mines in the area) would have a daily telephone conference, where each employee would say what they had been doing etc, and then talk about something new they had discovered and any other interesting tid-bits.
Couple ways I have seen so far:
Wiki is suitable for internal knowledge, for example environment, project specific topics.
Open doors policy
Encourage asking questions.
Voluntary presentations. Find out who have special knowledge and make it easy and attractive to set up a short presentation about it.
Project post mortem documents. A wrap up meeting moderated by someone outside project team held after project is finished or terminated.
Compulsory presentations.
Project presentation when they go live. Technologies used etc.
In case someone is sent to conference, he should have a presentation about new technology he saw.
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 3 years ago.
Improve this question
From time to time, there will be student attached to our projects, i would certainly like to assign him/her many things to do so can learn more. But alot of times we are resigned to assigning stuff like documentaiton, updating of ui mockup screens etc. As problem is that is it bit hard to trust the quality of work provided by students and another thing is that they are still young and their enthusiam may not be there.
How do we better utilize them such that they really cut down our workload and also in turns mean learning more stuff which will aid them in their future job opportunies?
I am afraid it might sound disappointing but it is not the best idea to utilise students to cut your organisational unit workload down. Probably, if your goal is cutting workload the best thing is not to take students. Read on to understand why.
Though you haven't specified the level of work-related expertise the students possess, nor did you mention the duration of their attachment, I assume from the tone of your question that their expertise is not sufficient to hit the ground running. It is also reasonable to assume that they are not staying for longer than 2-3 months.
The essential benefits your organisation can extract even given the limited timeframe are:
Notice and grab talented workers before they even get to the job market. Later in their working life they are likely not to be that easily available.
Turn every student into your organisation salesman. Let them tell everyone how good your product is, bring you in contracts in the future or make their peers envy their work experience increasing the pool of good candidates for your company.
Outsiders can help cast a fresh eye on your processes, procedures, product, expose inefficiencies etc.
Learn from them the latest stuff taught at universities.
Boost your time morale: Maslow theory, "esteem needs". Even the most junior member of your team becomes somewhat more senior, since these students have yet to achieve that position.
Cutting down workload means that you'd need to find a set of tasks which is fairly independent, does not require knowledge or skills that the students do not have and needs much of your team's time to transfer. The tasks cannot be strategically important in case they cock it up, not can it be operationally important. Hence you left with some dusty requests for management reports or research and development projects.
Chances are that R&D considered to be more desired work within your organisation and if you give exclusively to students some people feelings are going to get hurt.
How long are the students around for? When we have had students on-site for up to two weeks there was not much other then testing type work we could give them.
If the student has enthusiasm you code do some pair programming through a bug and let them write the unit tests for verifying the fix.
Even if you don't normally do pair programming, I find that with a junior dev it is sometimes productive to have him/her do pair programming with a more experienced developer, for the following reasons:
I wouldn't assign coding tasks to the junior developer alone, because his code would have to be closely reviewed by someone else anyway and quite probably rewritten or changed substantially.
On the other side, how can a junior developer learn if not by programming? So, you want him participating in some way in programming tasks.
You get some of the advantages of pair programming: the most experienced dev is less prone to make silly mistakes (even a very junior programmer can point things like 'hey, you made a typo there') and less likely to goof off checking stackoverflow.com every 10 minutes during the pair programming session.
Of course I also would rotate the junior with several seniors during the day, so they don't feel 'slowed down' or annoyed by the young guy for extended periods of time.
Why not assign one or more engineers as "sheperds" to the student and let them oversee their work or even better pair with them. The student will gain a good understanding of your project and real work and have a known fallback when in trouble and someone who can give provide direction.
The sheperd/mentor gains a fresh perspective, and the joy of teaching.