4 ms·

in the Mythical Man Month, Fred Brooks asserts that conceptual consistency is the single most important quality of a large, successful software project. Althoug

in the Mythical Man Month, Fred Brooks asserts that conceptual consistency is the single most important quality of a large, successful software project. Although I was skeptical at first (it seemed a little too believable to be true), experience has led me to believe that Brooks is correct. If a change makes a project conceptually incoherent, it should be rejected, and a new project started. I think this article is one very good illustration of this phenomenon, albeit in an agile rather than a waterfall setting. As a corollary, I think people often use agile as an excuse for introducing conceptual incoherence. I think this is almost always a mistake, and represents laziness, short-sightedness, and immaturity on the part of devs and managers alike. edit: I'll add that I think under-investment in quality principal engineers is what gets one in this mess in general. If you replace your architect and her copilot with a handful code monkeys and one or two arrogant senior devs, you get crap stew unless you're careful to manage around your team's lack of experience and maturity.

squiggleblaz 9y ago
I was thinking of making a comment here, describing this as precisely my experience. I work on an old legacy system. I have done so for some time, from junior to lead. [Edit: wait, I meant to say "i have discovered this same principle but you expressed it better than me". instead, i just described my experience.] And I can see from experience that every refactor we did that was "this is the latest and greatest and we'll write the new feature like this and we'll just start migrating everything over to this eventually" has been an utter failure. But the changes that were by their nature spread throughout the system automatically have been so much easier to work with. You don't even notice them. (Which makes it harder to get credit for it. If I have to train a new dev up today, I can say "the system is a little crappy, but we're trying to make it better". But they'll never see that we've made huge progress. But they will see the four different database abstractions we've got going on and they'll curse me, because this is where you see some work. It is better to have a crappy core that you gradually fix, then do have a crappy core that remains there and five crappy other cores from each different dev. And whatever problems are caused by the shitty database abstraction some idiot dev created are always going to be there, so you might as well just live in that world.
- jknoepfler 9y ago
  i really appreciate your taking the time to write up your experiences in response, thank you. I think it's really important to continually articulate hard, possibly unpopular truths learned through experience. Otherwise how will our children's children have anywhere to look for guidance (lol... but seriously)
coconut_crab 9y ago
Consistency is also the reason why Java or C# are so popular for large system. I asked a Scala developer recently why does his company use Java but not Scala, despite their developer's familiarity with the latter. He answered that while Scala is fine for small teams, when we have 100 or more developers there will be factions (scalaz, cats etc...), and it's very hard to maintain consistency between systems. With Java there is only one true style so it's easy to scale with larger number of developers.

squiggleblaz 9y ago

I was thinking of making a comment here, describing this as precisely my experience. I work on an old legacy system. I have done so for some time, from junior to lead. [Edit: wait, I meant to say "i have discovered this same principle but you expressed it better than me". instead, i just described my experience.] And I can see from experience that every refactor we did that was "this is the latest and greatest and we'll write the new feature like this and we'll just start migrating everything over to this eventually" has been an utter failure. But the changes that were by their nature spread throughout the system automatically have been so much easier to work with. You don't even notice them. (Which makes it harder to get credit for it. If I have to train a new dev up today, I can say "the system is a little crappy, but we're trying to make it better". But they'll never see that we've made huge progress. But they will see the four different database abstractions we've got going on and they'll curse me, because this is where you see some work. It is better to have a crappy core that you gradually fix, then do have a crappy core that remains there and five crappy other cores from each different dev. And whatever problems are caused by the shitty database abstraction some idiot dev created are always going to be there, so you might as well just live in that world.

jknoepfler 9y ago
i really appreciate your taking the time to write up your experiences in response, thank you. I think it's really important to continually articulate hard, possibly unpopular truths learned through experience. Otherwise how will our children's children have anywhere to look for guidance (lol... but seriously)

coconut_crab 9y ago

Consistency is also the reason why Java or C# are so popular for large system. I asked a Scala developer recently why does his company use Java but not Scala, despite their developer's familiarity with the latter. He answered that while Scala is fine for small teams, when we have 100 or more developers there will be factions (scalaz, cats etc...), and it's very hard to maintain consistency between systems. With Java there is only one true style so it's easy to scale with larger number of developers.