5 ms·
> And they'd know the classics, like memorizing all design patterns. That sentence is bringing back ptsd-like flashbacks. I remember distinctly how much every
by jrochkind1 3y ago
> And they'd know the classics, like memorizing all design patterns.
That sentence is bringing back ptsd-like flashbacks.
I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing.
I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The phrase "architecture astronaut" was a common epithet, and not a friendly one]
That above paragraph [without the brackets], ironically, could certainly be said of "agile" more recently too. I don't know how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous.
But yeah, I'm pretty convinced going back to appointing some almighty deity architecture astronaut who isn't responsible for or involved in any implementation (let alone operations!), who hands down plans from on high after "memorizing all design patterns" and drafting some diagrams, never sullied by "contact with the enemy"... no thank you, but thank you.
----
Instead of just complaining about that though, what I'll say in addition is -- I think the real problem is that engineers aren't given the time to carefully consider top-level designs. it's a basic business/resource issue -- until engineers have more breathing room to talk to each other and research and consider and come to decisions in an unhurried way, the top-level design stuff will remain chaotic. It's not an issue of appointing an ivory tower "architect", or something solved by it.
Although sure, there should be senior and even "staff" or "principal" people with more authority/responsibility for higher-level designs.
Everyone should be responsible for design at the level they are working. Everyone needs enough time to feel like they are doing it well, instead of running on a sweatshop code production treadmill.
- jrumbut 3y agoTo be fair to the design patterns people, a lot of them got baked into pieces of infrastructure like web servers and frameworks, while others are part of frequently included libraries. If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new things that would have taken too long to do before. And that was the intent of the Gang of Four book, not to teach you patterns you should copy mindlessly, but to give examples of how to identify and extract useful patterns from the software you've already written and describe them to others. Since that is a lot more difficult than memorization, very few took up that work.
- greiskul 3y agoDesign patterns are missing language features. http://norvig.com/design-patterns/ http://norvig.com/design-patterns/
- bluGill 3y agoPeople who say that don't understand design patterns and have never worked on a very large project with code dating back a few decades. Design patterns are what let you deal with the mess that results from that.
- kristjansson 3y agoGood _design_ improves long term maintainability. Design Patterns (in the GoF sense) are basically orthogonal to good design. Besides, Peter Norvig, even as of 1996, is not not the sort of neophyte you’re referring to.
- bb88 3y agoSo, here's something I hate on this site. Arguments that are made in the fashion "People who disagree with me must not understand X". When in fact you're often talking to some of the smartest people in programming on here (though, maybe not in other things.) It's possible to understand design patterns and work in a language that doesn't require them as much. Here's a talk about it from 2009 with regards to python. https://www.youtube.com/watch?v=kSQFZrTDaQ0 https://www.youtube.com/watch?v=kSQFZrTDaQ0
- bluGill 3y agoSome design patterns work around a bad language, but most are about complex problems. They are a way of describing abstraction, and that is what languages are about.
- rottc0dd 3y agoEven GoF says that class and interface are part of language for C++ or Java can be a design pattern for languages like C. I think in some ways AspectJ can make the observer design pattern obsolete in Java. I have arguments against doing it in aspect way, but it was revelation nonetheless.
- devin 3y agoI tend to agree about the time thing, namely that people aren't given enough of it to sit down and take their time with design decisions. If you squint you can kind of see that "software architects" are a business's way of creating a "solution" to this problem, but with lackluster results. That said, I've been at places where management did a pretty good job of making sure that there was enough time to do this kind of work with middling results. People have to enjoy the work or feel invested in a way that makes them care about "3 years from now", and sadly in a lot of places there's a lot of "whatever, it'll be fine for as long as I work here." It seemed to me that in let's say 50% of cases, having the extra time didn't really matter. Assumptions about what was being built were proven incorrect not long after a design was laid down and work had begun, or particular engineering types would create increasingly complicated designs with their time rather than doing the hard work of distilling the problem, sometimes including $PET_TECHNOLOGY as part of their solution. The "let's design something truly great" really has to be in a team's DNA in my experience or you wind up with a good design that isn't followed, one person who does all the work, a gold plated design, etc.
- jrochkind1 3y agoThat's fair, and a good observation. I'm not sure what to make of it as far as general narrative. If people are creating stuff they don't really care about, of course it won't be very good? And there's a lot of money spent paying people to build things that honestly nobody would reasonably care much about? One way or another, the pining for a software engineering world where we all collaborate on creating things that are maintainable products with high-quality user-facing experiences, and have the time to do that... well, that's not the one we've got.