Top Linux Developers Losing the Will To Code?

E5Rebel noted that Don Marti has a piece that talks about "Core Linux developers are finding themselves managing and checking, rather than coding, as the number of kernel contributors grows and the contributor network becomes more complex."

a good or bad thing?

[brunascle]

that's odd. the linux.com article [linux.com] covering the same event made it sound like the kernel team thought it was a good thing that there were more developers, and the work was more spread out.

Not loosing the will

[realdodgeman]

They are not loosing the will to code. They just have too much other work, like reviewing others code. So they do not have enough time left to code. RTFA. The headline is not reflected in the article itself at all.

The Mythical Man Month

[$RANDOMLUSER]

Described this in 1975. As you add more people to a project, communication takes up more time than coding. From Wikipedia [wikipedia.org]:

Assigning more programmers to a project running behind schedule will make it even later, due to the time required for the new programmers to learn about the project, as well as the increased communication overhead. When N people have to communicate among themselves (without a hierarchy), as N increases, their output M decreases and can even become negative (i.e. the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created).

* Group Intercommunication Formula: n(n 1) / 2
* Example: 50 developers -> 50(50 1) / 2 = 1225 channels of communication

Re:Should have used Eiffel

[ajs318]

Eiffel? No, they wanted something that would actually run.

That's why people still use languages like C. It's quick to get a program together, even if it doesn't do exactly what you wanted first time. You fix the mistakes and try again. Each time you go around the loop, there should be fewer bugs (but Sod's Law says that each one will take longer to find). After just a few generations, you end up with a mostly-usable program.

With all these fancy-arsed "designed so mistakes are impossible" languages, you can spend longer trying to write a "demonstrably-correct-first-time" program than you would chasing down bugs in a nearly-right one. Or at least, that's what it feels like.

This is Good

[EmbeddedJanitor]

It is far better to have the more experienced folk checking the contributions of others. This builds a broader base of contrubutors and the more seasoned folk get to ensure that the Good Stuff is getting in to the kernel/whatever.

Experience does count, and age is not a limitation. There's a myth that older people can't program. At 45 I reckon I can outprogram most youngsters, but it is probably more valuable to be mentoring others. I know a few very active programmers in their 60s and even 70s.

Old good programmers should not become managers unless they are actually better managers than programmers. Programming is not a science or an art, it is a blue-collar skilled trade. Knowledgable older programmers should be helping out the youngsters.