Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re:Nine years of pair programming? (Score 4, Interesting) 186

This is nothing new.

The effort of every individual in a group of people has been measured by Ringelmann in 1914, for army's purposes.
Here is the original article:

And the results are (number of people => measured effort)
1 => 100%
2 => 93%
3 => 85%
4 => 77%
5 => 70%
6 => 63%
7 => 56%
8 => 49%

This is called "Ringelmann effect" or more recently "social loafing".
As you can see, 8 people produce the same amount of effort than 4 individuals.

Comment Re:Can anyone keep up all these bullshits? (Score 1) 166

I maintain that this 2 weeks is completely arbitrary, and leads to unregular velocity during the session.
You'll get most work at the beginning, and the effort disappears at the end of the session.

The worst thing is that some of the nice features get cut in so many parts that we can only implement the least costly ones.
This leaves the whole features unfinished and creates a lack of satisfaction.
Perhaps it works well for new teams, but for experienced teams, this is a serious problem.

Also, an experienced manager will know when to negotiate (which is what agile encourages) and when to stop negotiating (which is what agile discourages).

Comment Re:Can anyone keep up all these bullshits? (Score 1) 166

What agile does for the developer is codifies "I have 2 weeks to code this specific thing, go away and let me do it".

I wanted to agree with you, but you are clearly too much obsessed by Scrum !
Frankly, this "2 weeks-sprint" is probably one of the least agile techniques.

It's like saying: we are in the Titanic, we need 10 miles to turn right. Hey, there is an iceberg in front. No, we need 10 miles, so we'll take 10 miles !

Agile is here to force managers focus on their work, and let the developers focus on their work.
Forget daily scrums, forget sprints, just do it in the agile way: as it comes.
How can I balance between planning/cutting tasks and coding/testing, when software changes during its development ?
I can assure you that 2 weeks sessions will not solve your problem !

Comment Re:Can anyone keep up all these bullshits? (Score 5, Insightful) 166

What is the correct balance between "planning" and "doing" ?

"Doing" works for people with plenty of experience, but they are rare.
"Planning" works when the project is very complex, but it is rare
The correct cursor is something between "a little planning, a little doing, and we see what we reached", which is basically agile's definition.

I'd like to share my experience: I wanted to become an agile coach (yes, shame on me !).
This was because I saw the opportunity to help people become better, but that's not really what agile became nowadays.

And I realized that Agile is not for developers, but for managers.
In other words, it's not designed to help developers, but to make money out of managers.
You have to agree that the vast majority of managers are completely clueless, so they doubt about their own skills.
Agile, or most exactly Scrum and Devops, are designed to tell them: you don't understand software development ? No problem, you'll only have to follow a basic algorithm and we promise you that all your problems will disappear.
I agree that this is quite dishonest, but hey, the goal is to squeeze money out of companies, and managers can use their budget for this !

What is funny is that most agile gurus are not decent developers.
They'll explain that such agile game will help people realize something, but they are quite clueless regarding programming.

Comment Re:Nope (Score 4, Interesting) 132

I'd like to share my own experience, since I'm self-taught programmer.

I started programming 35 years ago, on a pocket calculator (TI58-C), then moved onto some micro-computers.
At this time, I realized that that's what I wanted to do as my job.
So I spent a lot of time disassembling code, in order to understand how it was done.
Then I started to write my own games.
I finally got hired into a video game company, but I realized that working in a company could not provide me enough software education.
I bought the Art of Computer Programming, and I passionately read it.
Later, I entered programming contests, where I could explore combinatorial algorithms by practicing them.
Now, I'm equivalent to a software engineer, though I'm underemployed given my experience.

So yes, you can practice programming and acquire theoretical bases afterwards.
But most coders I met were satisfied with their level, never trying to challenge their knowledge.
I don't speak about learning new languages, but new ways to solve problems.
They are more dedicated to build their career.

Comment Re:After RTFA (Score 2) 157

Since I'm from France, I found some other articles explaining the real reasons, and they are pretty different from TFA.

Here are my sources:

First, Montreuil is 11 kilometers away from Paris, it's reasonably near and a lot cheaper.
You can check the photographs, the residents live only a few meters from the datacenter.

The problems appeared because Interxion would like to add an extension to the datacenter, doubling its capacity, and thus the noise it produces.

Here is a translation about the various causes:

In particular because of the presence of generators with combustion engine, of course designed for use in emergency power supply and when the monthly testing and maintenance, but also for refrigeration systems installed outdoors on terraces, designed to operate continuously, and because of a law daily traffic of 15 heavy vehicles.
Besides the sirens sometimes trigger during the night.

It's nice to have datacenters, but it's hellish to live nearby.
And if you are the owner of a house nearby, your house cannot be sold at a correct price.

Comment Re:What's in a patent? (Score 1) 76

In fact, it's quite easy to patent new ideas.
There are even methodologies for that: TRIZ, SIT, ASIT or USIT.

The only problem is that these methods don't focus on "inventing" but on "improving" existing ideas.
So basically, it's not a very "creative" process, so "genius" is not required.

Comment Re:Suggestion... (Score 2) 230

A french magazine for consumers wrote an interesting article about long-term reliability of the various cars.

Volkswagen has a generally good quality, but still a lot of problems.
Here are a few ones:
- fouling and breakage of the turbo diesel 4 cylinder
- failure of injectors and water/oil leakage on the 1.6 TDI

The recommended models are : Up!, Polo (except diesel until 2014), current Golf Jetta and Passat, New Beetle, Sharan since 2013 and current Touareg.

If you are interested, I can translate some of their recommendations.

Comment Continuous integration (Score 1) 325

In fact, what you want is several different tools, at least a VCS and an integrated build:

At my company, we are using CruiseControl.NET, which is free and open-source, but seems discontinued.
It's sufficient for our needs.
We use a SVN server to make our commits (with TortoiseSvn on the clients), it's dead simple to install and use.
Configuring CruiseControl is more tedious, but you'll get automated builds, along with code coverage and unit tests.

A better tool may exist, but we use this one.

Comment Divide-and-conquer is an art (Score 5, Insightful) 281

Dear Anders,

I know you are trying to defend your point of view, that DevOps is THE solution to everybody's problems.

I agree that divide-and-conquer is an approach useful in algorithms (especially if you pass Google's recruitment tests), but it's much more difficult in real life.

Social loafing exists in groups, and has been known since a long time.
Ringelmann measured the productivity at the beginning of the twentieth century, and discovered what is now named Ringelmann effect:
Ringelmann's original article explains that a team of 8 persons produces the work of 4.
You may argue that you can optimize that by splitting in several groups, but the effect exists starting at 2 persons (85% of effort is produced).

To a certain degree, you can optimize a process by splitting tasks in independent subtasks, preferably assigned to one person each.
However, there are several major problems:
1) some tasks are not as independent as you may imagine
2) some tasks require that people with multiple domains work on them
3) some tasks are so long that it slows down the entire process. It is well known in Supply Chain that a single bottlenecks reduce your output.
4) splitted tasks become boring as hell
5) working alone doesn't improve your knowledge

So no, you didn't show that the Mythical Man-Month has been disproved.
You just showed that dividing tasks to a certain level may improve productivity, which is nothing new.

Also, applying efficiently DevOpt requires experienced managers.
Experience comes from mistakes and mixing various techniques, like ITIL, Scrum, DevOps, etc.
If you only use DevOps, I can assure you that you are bound to fail !

Slashdot Top Deals

Mathematics is the only science where one never knows what one is talking about nor whether what is said is true. -- Russell