Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: You can thank "process improvement" consultancies. (Score 4, Interesting) 507 507

At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.

Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.

So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?

For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.

Comment: Move on -- this is ordinary supply and demand... (Score 1) 574 574

Netflix isn't raising prices just for the hell of it. Prices get raised for two reasons: 1) Increased upstream costs (passed on to the customer), and/or 2) Increase in demand.

The reality is, Netflix has run the numbers and they believe that the demand for their product is such that most of their customer base will be willing to pay the higher price. They'll definitely have some attrition, but that loss in revenue will surely be replaced by the increase in revenue from the customers that stay. Believe me, they've already run these numbers.

Netflix has a great product, it is served through far more mechanisms than it used to be (phones, gaming consoles, televisions, set-top boxes). As demand has increased, I'm certain their delivery costs have increased. As Netflix's demand has increased, I'm sure the entertainment industry has raised their prices to meet the demand. It isn't that big of a deal. Okay, yes, they could have done a better job of publicly positioning the price alterations, but so what?

In the end, we have a company that raised the price of it's higher demand service and lowered the price of it's lower demand service. Is this really surprising?

Comment: Re:The rake is the problem... (Score 1) 104 104

I think you are seriously understating the rake...

Of course the rake is capped. If it weren't, nobody would play. Because the rake would be unbeatable by even the most skilled of players. Any rake is intended to maximize the house's profit while still keeping good and bad players interested in playing.

The situation you describe is a rare one. For every hand where the "rake doesn't matter", there are probably 10 or 20 hands where the rake DOES matter. Hands where you paid an ante to simply fold. Hands where you paid a rake to fold on the turn. This happens WAY more often than not.

Like you said, you can't be a winning player by winning only the small pots. I'll go further to say that you can't be a winning layer by winning medium pots. The only way you can be a winning player is to maximize the profit potential of all hands -- small, medium, and large.

Comment: The rake is the problem... (Score 1) 104 104

I agree with you conceptually.

But the big problem is *THE RAKE*.

I am a poker player. I do believe poker to be a skill game. But the reason why poker is not a complete skill game is because of the rake. Being consistently more skilled than your opponents at poker is not enough to make you profitable. You have to be skilled enough to also overcome the rake.

Let's say that in an ideal world, with no rake, I am skilled enough to win 5 dollars per hour. After introducing the rake, I could potentially lose 10 dollars per hour... putting me at a net loss. Even though I didn't change my playing style one bit. Overcoming the rake is a hard feat given that it is at least 10%. Over the long run, that is an incredibly huge amount of money. And you pay the rake regardless of whether you win or lose.

Being better than your opponent isn't good enough. You have to be skilled at maximizing profit. This is what most people don't understand.

I know very skilled players who win a lot of hands... but are losers... because they don't know how to maximize their winning value to surpass the rake.

Comment: Solve a problem that is interesting to you... (Score 1) 293 293

Niris,
I have helped teach several people how to program. What you really need to next is apply what you have learned and solve a problem. Ideally, solve a problem that you know something about. Or solve a problem where you have some subject-matter expertise.

I'm not sure if you actually like being a security guard or not. Maybe you do. Maybe you don't. But you are probably familiar with the subject matter. Write a program that will solve a problem related to the subject matter. Using problems that are in operations research are really good ones. For example, a problem I might give you:

Security Scheduling Program for a Business

Purpose
The program should create the optimum shift schedule for a week -- guarding a business 24 hours a day.

Requirements
1) The program must allow for the user to input the number of available security guards.
2) The program must print out the shifts for each security guard.
3) No shift schedule can be over 8 hours long.
4) No security guard can work more than four days in a row.
5) All guards must be used in the schedule.
6) Each guard must have a 30 minute lunch and two 15 minute breaks each day.
7) During a break or lunch period, another guard must cover the watch.
8) If any of the constraints cannot be met -- given the number of guards available -- then the program should indicate that more guards are needed.

This problem is just an example of an operations research problem -- finding optimality. If you don't like this problem, you can make up another one. Or do a search on the internet. The idea is that you find a problem to solve that you: 1) know something about and/or 2) have some interest in.

When first learning to program, the key isn't the language you learn. The key is proving that you can solve a real world problem using programming. Good luck to you.

Science

Why the First Cowboy To Draw Always Gets Shot 398 398

cremeglace writes "Have you ever noticed that the first cowboy to draw his gun in a Hollywood Western is invariably the one to get shot? Nobel-winning physicist Niels Bohr did, once arranging mock duels to test the validity of this cinematic curiosity. Researchers have now confirmed that people indeed move faster if they are reacting, rather than acting first."

Comment: It sounds like a hedge answer, but "it depends"... (Score 1) 426 426

Interesting. I've never heard the converse question... "When the manager comes in early, should the developers come in early?" But that's another topic...

The real question is "why would the manager stay?" Here are some possible -- one or more -- reasons:

1) Because the manager does not trust that the job will get done... "trust but verify".

2) Because the manager feels like it will gain him/her credibility with the team.

3) Because the manager feels guilty and wants to share in the pain.

4) Because the manager feels like it will give the bosses peace of mind during hard times.

I can't think of any other reasons. But it is important to say that usually, if a manager wants to stick around, it is for noble reasons.

My advice to developers, is that if reasons #2, #3, or #4 are any of the motivations for their boss to stick around... cut them a break. Even if #1 is also a reason.

Comment: Don't forget "yall's"... (Score 1) 408 408

The possessive form of "yall" is "yall's". Here is an example sentence.

"I saw the car outside and figured it was yall's."

"Yall's" is a contraction of Yours (all of yours).

In the northeast, a variation is "youze guys'es". In the deep south, another variation is "your'n".

Gotta love English.

Comment: Find the Nash Equilibrium... (Score 1) 376 376

One of the earlier posts talked about the difficulties around "too big to fail" or "to big to succeed". To me, this is where the concept of finding a Nash Equilibrium is critical.

To resolve this situation optimally, a means to an end must be found where all of the affected parties benefit the greatest as a whole. You can't simply issue a patent judgment and say "have a nice day, you have X days to comply". That might benefit i4i, but it really hurts a lot of other stakeholders in the system -- including consumers (who do you think will bear the cost of that judgment?). Like it or not, by the law, i4i deserves something for the infringement (if the court finds the patent valid).

However, this is where our legal system in the free market breaks down. You've got to make sure you can come to judgments where the market isn't overly harmed, but everyone gets a taste of what they deserve.

Comment: Re:Programming != Engineering... (Score 1) 141 141

Your analogy is off. Let me restate it.

You don't need to have knowledge of engineering to engineer a bridge.

Likewise...

You don't need to have knowledge of programming to write a computer program.

Stop getting the wires crossed. Engineering != Programming. The two are completely orthogonal.

Comment: Re:It is a managerial problem. You aren't motivate (Score 1) 601 601

This is so well said.

You are exactly right. It does NOT matter at all who's fault it is.

The reality is, the manager has to address any kind of motivational issues. Regardless of the source of de-motivation. De-motivation kills individual productivity, team productivity, and can even sour an entire organization.

Comment: Re:It is a managerial problem. You aren't motivate (Score 1) 601 601

Uh, exactly. If you have an employer that uses terms like "self-motivated", "works smarter and not harder", "ability to work without direction"... et cetera.... RUN (don't walk) for the hills.

These are companies who have incompetent managers who delegate their own management responsibility to their workers.

Managers are supposed to actually serve a purpose.

"If you own a machine, you are in turn owned by it, and spend your time serving it..." -- Marion Zimmer Bradley, _The Forbidden Tower_

Working...