5 ms·

I think we have this problem now. Too many chefs in the kitchen has led to an unorganized codebase. Lack of direction/vision. No consistency. We have a “scrum m

by speg 7y ago

I think we have this problem now. Too many chefs in the kitchen has led to an unorganized codebase. Lack of direction/vision. No consistency. We have a “scrum master” but they are more to facilitate meetings, the work falls to whichever developer happens to take it on which can be different than the one who previously worked in that area. Some days we need a quarter back to call the plays. Otherwise, it’s like watching a game of six year olds playing soccer.

lmm 7y ago
Whenever I've seen "organisation", "direction", "vision" or "consistency" in a codebase, it's always done more harm than good. One of the cornerstones of agile is that you ruthlessly pare away anything that isn't necessary for delivering user-facing functionality - YAGNI. If anyone is reshaping the style of an area of code, they should be able to justify that in terms of the value they're delivering in their current two-weeks-or-smaller story. Each part of the codebase ends up uniquely shaped to the business problem it actually solves, and is as simple as possible to solve that problem. You don't need architecture; what would adding it gain you?
- speg 7y ago
  How do you deal with all the uniquely shaped pieces of code? If they are radically different, you won't be able to use them together later. Bob doesn't grok what Alice did when he goes to implement something in that area, and ends up introducing a bug of his own.
  - el_programmador 7y ago
    There is also the case of Alices & Bobs using inconsistent variable & function names, etc. if left unchecked and make life difficult for everyone. Organization/Consistency in code is a real problem that can't be simply wished away.
  - lmm 7y ago
    > If they are radically different, you won't be able to use them together later. Why would you want to use them together? Their differences reflect differences in the underlying business areas. If those businesses need to somehow be combined, their representatives will have to come to a common understanding of how to translate between them, and then that business understanding can be reflected in a corresponding way in the code. > Bob doesn't grok what Alice did when he goes to implement something in that area, and ends up introducing a bug of his own. The biggest barriers to understanding are length and indirection, and they're the only way to make code consistent. It's easier to understand code that describes the unique problem that it solves in a unique way than code that tries to force that solution into some generalised framework.

by speg 7y ago

lmm 7y ago

Whenever I've seen "organisation", "direction", "vision" or "consistency" in a codebase, it's always done more harm than good. One of the cornerstones of agile is that you ruthlessly pare away anything that isn't necessary for delivering user-facing functionality - YAGNI. If anyone is reshaping the style of an area of code, they should be able to justify that in terms of the value they're delivering in their current two-weeks-or-smaller story. Each part of the codebase ends up uniquely shaped to the business problem it actually solves, and is as simple as possible to solve that problem. You don't need architecture; what would adding it gain you?

speg 7y ago
How do you deal with all the uniquely shaped pieces of code? If they are radically different, you won't be able to use them together later. Bob doesn't grok what Alice did when he goes to implement something in that area, and ends up introducing a bug of his own.
- el_programmador 7y ago
  There is also the case of Alices & Bobs using inconsistent variable & function names, etc. if left unchecked and make life difficult for everyone. Organization/Consistency in code is a real problem that can't be simply wished away.
- lmm 7y ago
  > If they are radically different, you won't be able to use them together later. Why would you want to use them together? Their differences reflect differences in the underlying business areas. If those businesses need to somehow be combined, their representatives will have to come to a common understanding of how to translate between them, and then that business understanding can be reflected in a corresponding way in the code. > Bob doesn't grok what Alice did when he goes to implement something in that area, and ends up introducing a bug of his own. The biggest barriers to understanding are length and indirection, and they're the only way to make code consistent. It's easier to understand code that describes the unique problem that it solves in a unique way than code that tries to force that solution into some generalised framework.