So, to summarize the points here: focus on writing the most lines of code per unit time possible; don’t bother figuring out how that piece of code interacts with other pieces or the humans who are going to interact with whatever it is you are building. Also, a coder should know ‘all they need to know’ once they are out of college.

Really? Is this satire, and I missed the label somehow?

Assuming it’s actually not satire, the point of refactoring is converting slapped-together-too-quickly-because-of-time-pressure code into something understandable (and, yes, maintainable) by an intern (the previously mentioned ‘someone just out of college’). If you don’t forsee the need to maintain something, then refactoring’s a waste of time. Ditto if the code’s already perfect (hint: it never is). And if it’s APL there’s really no point, even if the original authors are going to be maintaining it.

A major point of design documents, which IMO, should be in the form of prototypes, is to get buy-in from whoever’s going to use the product, or marketing/planning if it’s a commercial product. There’s no point in writing code if it doesn’t solve the problem your ‘customer’ wants solved or doesn’t fill the market niche marketing wants to sell to.

The other point of docs is time pressure. With those docs (or prototypes) you have a prayer of finding out what functionality (or feature set) is most important to your customer. You can then give them the choice of slipping a deadline or eliminating some less-important-to-them features when your milestones start to slip, which, most probably if this is the first time this team had built a product like this, they will. Try to do this early enough that you can make good use of the freed-up coder-power.