And you are here why?

Process is not the solution. Process is never the solution. It can, however, be the means to the solution. Do not, repeat, not , confuse the means and the end... Mind you, I have seen "Agile" and "Scrum" used most frequently to just mean "now you have more work to do..."

Ever wondered why many of the erlang modules provide seemingly similar functionality (" functionality". ho ho ho ) using different functions? Why there are so many tools that seemingly do pretty much the same thing? Consider that you could just use lists :map / 2 instead of lists :foreach / 2 , and ignore the result if all you cared about were side-effects.  e.g. lists:foreach(fun(X) -> do_something_to_a_file_named_(X) end, [a,b,c]) could just as easily be done as _Ignore = lists:map(fun(X) -> do_something_to_a_file_named_(X) end, [a,b,c]) Yeah, yeah. I know. Its stupid.  But you could do it, no?  Come to think of it, I'd bet that any number of people are actually doing it even as we speak - given that its not actually wrong , y'know?  It doesn't stop there - consider the following in the lists module     ⁃    lists : sum / 1 could just as easily be done using just a wee bit more code using lists :foldl / 3  ...

OK, some bugs are the developer's fault, but if you eliminate the n00bs and the idiots from the test demographic, then I stand by my statement. OK, fine, we'll also eliminate syntactical errors (you are using syntax checking in your development environment, aren't you?  If you aren't, go away.).  But that pretty much is it. I've used a plethora of languages and platforms - C, C++, erlang, java, objective-C, perl, python, ruby, and javascript (if you can call that a language.  And yes I'm joking.  Mostly.).  Its pretty much a best tool for the time and the place kind of existence, and AFAICRemember there has always been the persistent underlying frisson of fear , forever,  around bugs/errors.  And they all share one commonality. Errors are, always and every-time, considered to be a fault on the part of the developer. Pity you, the poor java developer. You begin by writing defensively. You absolutely infest your code with fun stuff li...

From a Tedd Ziuba post hating on process . Software development methodology is organizational Valtrex. Sure, it treats a symptom, but the only cure for the underlying disease is to never have contracted it in the first place He goes on to point out that the main reason to have process/methodology is that, thanks to the Law of Large Numbers , the more developers you have, the more your average skill is going to regress to the mean, i.e., the skill of the Mythical Average Developer The underlying cause is that the variance of developer skill on your team is too high, which means your team can't execute well, and you need process to wrangle the laggards  Communication Overhead   In my experience, there is a second reason called, you guessed it, Communication Overhead . See, I am the Perfect Developer.  Everything I do is Perfect.  Crystalline Joyeous Glorious Perfection. (yeah, yeah. humor me).  Oh, did I mention I don't need to sleep either?  ...