tag:blogger.com,1999:blog-8221886912876606828.post8744209965112415648..comments2023-06-23T00:44:05.938-07:00Comments on Elided Branches: Process Debt and Team ScalabilityCamille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-8221886912876606828.post-3515684729074876502012-05-19T14:25:50.824-07:002012-05-19T14:25:50.824-07:00Thanks, as usual, for another thought-provoking pi...Thanks, as usual, for another thought-provoking piece.<br /><br />I don't think we pay as much attention to process as we should, nor to the concept of the "product" as a whole, which is distinct from the code that's used to build the product. So, for example, developers tend to think of correct functionality and performance (maybe!) as the be-all, end-all of their responsibility. Whose responsibility is it, however, to think about the entire lifecycle of the product (requirements + development + operational + versioning)?<br /><br />A couple of additional comments:<br />*) "Now you have better style, but at the cost of everyones' productivity, especially your senior developers". Maybe, but only if you define the productivity of your senior developers as being the code _they_ individually produce. Being a senior developer (to me) means being responsible for the whole product (code + process). If they are improving all that by detailed code review, then they are being very productive.<br />*) "Will the solution work with twice as many developers…. ten times… a hundred". I think it's difficult to expect any good process to scale that way. A good process that works for 10 rarely works for 100.<br /><br />The correct amount of process is an art depending on the size of the team, it's experience, the state of the code (debt), and the business drivers for the product (which is why we are doing any of this!).Mike Mhttps://www.blogger.com/profile/11490344190768803850noreply@blogger.com