I do think there are good reasons why “that level of formality never seems to get carried on down to the level of actual coding” though. If I understand correctly what you mean by “actual coding” then it involves the engineering team spec-ing and manufacturing in-house a very large number of very small components (methods and classes and whatnot.) It seems that the systems being created are orders of magnitude more complex than a physical engineering team of a similar size would attempt, so less formality can be justified.

Over time though, every software engineer I know has seemed to find that even for agile and able thinkers, the optimum balance between formality and flexibility is considerably further away from “it seems to work” than they expect…!

Anthony: It seems that the systems being created are orders of magnitude more complex than a physical engineering team of a similar size would attempt, so less formality can be justified.

Yeah, there’s the old “people want a good product *today*, not a perfect product 5 years from now” tradeoff in the Real World. If anything, I think greater complexity should ideally justify greater formality, not less, but if you have a fixed amount of “developer hours” then something has to give.

Also, feel free to just chop off a long entry abruptly, if you feel the domino effect of idea association has gotten out of hand. I’ve done this a couple times, and I find that it’s useful to have gotten it out at least. It makes the thoughts more concrete and easier to work with. And if you’re lucky, people will post comments that will take you in directions you might not have thought of on your own.

In short, don’t strive for perfection, just aim for something that has a minimum level of interesting-ness. It’s up to you what that level is.