3 ms·

So I would rephrase the parent poster you replied to even though he replied himself. There are many programmers that put cart before the horse - they think the

by ozim 4y ago

So I would rephrase the parent poster you replied to even though he replied himself. 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. Whereas one should notice when pattern is applicable because it starts emerging as such - and GoF wrote down descriptions for people to realize what these are and have names to call it out. Like if you would be tasked to build local "folks music" museum and you insist that it has to be built just like Guggenheim Museum because that is state of art of building museums. So real architect should say "well for folks music museum - build a shed, put on some folksy clothing on mannequins, set mp3 player with folksy music, that is good enough ... what is your budget? ... well it will not be enough for top grade sound systems so maybe a smartphone instead of mp3 player with amplifier". Most of people in software dev should stop pretending they are building next Guggenheim Museum and accept they are building shed from wooden planks.

pull_my_finger 4y ago
> 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.

by ozim 4y ago

pull_my_finger 4y ago

> 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.