Only on HN would you see a topic called "Programming, motherfucker" and see a comment asking "But does this scale?"
Oh look, a feature short by Goatse Man and 2girls1cup.
The other group write up huge requirements documents, set up Sharepoint sites and wikis, raise tickets and Jiras, you name it, but they never talk to each other and so they get nothing done...
Nothing in scrum stops you talking to anyone at any time. The stand-up makes sure that you have to say a few words to the whole team and other interested parties, daily.
I like to read criticisms of scrum, when they're not straw-man ones.
I'm a big believer in trying to persuade people to keep feedback loops short, make teams small and cross-functional, and to design/code/test/ship in the smallest increments possible. At this point, calling an approach agile/scrum/xp carries a lot of baggage.
If people don't get the why (e.g. the team isn't small and cross-functional, and people aren't working on tiny increments) it kind of doesn't matter if you get everyone in the room at the same time every day.
I'm going to start a post-Agile programming methodology called, "Programming, Motherfucker." It'll be awesome.
If your software is late/buggy/whatever the solution is rarely adding people / process. It's usually removing people / process. Process is what allows managers to fuck up projects.
hell yeah.
http://www.youtube.com/watch?v=My-P4LssMsI
It seemed appropriate.
I agree with the parent comment. "Just programming" looks nice on a manifesto, but you need processes when you want to scale.
If you are working with 500 programmers, they are likely to be mostly mediocre - the good ones would have run away screaming to better jobs.
Sure, if you have 500 mediocre programmers, you need to rope them in with systems. If you hire 5-10 great programmers, stand well clear and let them do their job.
I've worked on very large software systems before, places that had around 1,000 developers spread throughout the organization. While there were a lot of mediocre, and truly some flat out bad developers, I guarantee you that 5-10, or 10-20 great programmers could have developed an equal system.
Throwing bodies at a deadline doesn't usually work. Throwing bodies at a problem can help, though.
Places with 1,000 developers spread throughout are working on hundreds of interacting projects. But, the communication and coordination isn't between all 1,000 developers.
And yes, I did well actually you.
Linux is a monolithic kernel, and because kernel parts depend on one another, unfinished changes are often blocking other changes and/or are breaking other parts.
Of course you aren't going to have 1000 developers working on the same line in the same file.
Linux is a product by itself, not a distribution of independent parts. You either have the whole kernel, or you have nothing. And I would die to see another kernel developed by 5 people, achieving the same feature-parity / stability and all that jazz as Linux.
the communication and coordination isn't between
all 1,000 developers.
No, it's worse. Teams usually don't know what the others are doing, leading to broken, blocked or half-baked features and work duplication.Here's an example: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
Having all those 1000 developers talk to one another would solve all problems, but this is a problem of scale which processes solve to a certain extent. Your opinion also highlights what's wrong with software development as a whole -- you seem to be under the impression that you can go and hack stuff in a vacuum, without interacting with others.
[Piling] bodies at [the door] can help, though.
FTFY.
Beyond ~7 people, someone needs to begin to coordinate, which is the logical introduction of management and process. But again, avoid large teams where possible.
Linux, Windows, Microsoft office - all great examples of a huge number of modules working together. For instance, the programmer writing the font rendering doesn't need to work closely with the video driver developer, they interact through a carefully designed interface.
But if you are in a startup, odds are you are slinging many large libraries and iterating quickly on new code (that often only you consume). In that case, you're better to "Program, Motherfucker"
It's a business decision - is it cheaper to hire one genius to produce something amazing or to hire a few mediocre programmers and manage the heck out of them to produce something that just about works?