Whenever I see somebody saying "Who needs process" or "Process is overkill", it's usually followed up with how they work in a small team.
Having no process may work well in a small team where you can walk over and chat to the other folks in the team, but that's an implicit process:
"Our process is to talk to each other face to face and do pull requests, but we don't call it process because that's a dirty word".
When there's only a few of you, it's easy to get everybody pulling in the same direction. This becomes much harder when you have an organisation with several thousand people in it.
At some point your team / product group may expand past the point where its reasonable to fit the whole team and all the other teams (eg QA, Sysadmin, DBA's, Networks, BI, Sales, etc) there's a dependency on in the same room. At that point, trying to maintain face to face interaction breaks down completely and you need to start defining processes that result in effective interaction between members of disparate teams who may not even know each other exist.
One way to avoid this problem would be to not increase the size of your team or product, but that doesn't solve the issue of needing to develop something large, like say Mac OSX or Linux.
Speaking of Linux - even the kernel has a strict process for getting things done. It's how they manage large numbers of commit's from all sorts of people without going completely insane.
"Same room" is another factor being independent of the fact of having or not a process for software development. I think the article proposal is close to the proposal "Programming, Motherfucker Do you speak it?" - http://programming-motherfucker.com/
I have seen a lot of enterprise making "software development" avoiding programming by replacing it with an ugly process. Just to avoid doing the real job of programming. If I look for the past years in my narrow view, usually the most successful ones are the ones focusing on programming and nothing more.
Having no process may work well in a small team where you can walk over and chat to the other folks in the team, but that's an implicit process:
"Our process is to talk to each other face to face and do pull requests, but we don't call it process because that's a dirty word".
When there's only a few of you, it's easy to get everybody pulling in the same direction. This becomes much harder when you have an organisation with several thousand people in it.
At some point your team / product group may expand past the point where its reasonable to fit the whole team and all the other teams (eg QA, Sysadmin, DBA's, Networks, BI, Sales, etc) there's a dependency on in the same room. At that point, trying to maintain face to face interaction breaks down completely and you need to start defining processes that result in effective interaction between members of disparate teams who may not even know each other exist.
One way to avoid this problem would be to not increase the size of your team or product, but that doesn't solve the issue of needing to develop something large, like say Mac OSX or Linux.
Speaking of Linux - even the kernel has a strict process for getting things done. It's how they manage large numbers of commit's from all sorts of people without going completely insane.