> There are many programmers that put cart before the horse - they think they should use those patterns even before they start to emerge in their systems and tr

> There are many programmers that put cart before the horse - they think they should use those patterns even before they start to emerge in their systems and treat those patterns as some kind of a goal. Isn't that the whole purpose of design AND of patterns? You design your software first, and instead of reinventing solutions that already exist, you base them on patterns. It doesn't have to be a BUFD, but you should still map out your requirements before hand, and when thinking of your implementation, if it's a solved problem why not use the patterns that are accepted and available. That improves build-time and maintainability because you're using familiar patterns. There's a time and a place for going full hacker and just start coding immediately and letting the pieces come together as they will, but lets not glorify it and certainly not call it the "right way" or imply that design before building is "putting the cart before the horse". Design should come before construction.