11 ms·

Why I hate all articles about design patterns (2016)

92 points by lkrubner 9y ago

chj 9y ago
The issue I am having with design patterns is that they are full of big weird words that doesn't mean anything to a new programmer.
apo 9y ago
Bizarre. The article doesn't explain much about why the author hates design patterns. The best I could come up with is in this passage: Perhaps I’m being unfair to Design Patterns, but those articles [about design patterns] seem like the worst kind of tech writing, the most likely to inspire useless discussion that doesn’t help move a team forward. Catering to software developers perfectionism tends to be bad for business. And this particular type of article seems to be the most extreme in that regard. To recap, DP articles: - are the worst kind of writing (still no explanation) - likely to inspire useless discussion (sometimes play is a lie?) - catering to perfectionism (this can be said about any tool) The article reminds me of many folks I've met who despise analysis and planning. They're constantly getting themselves into trouble that requires quick action. When it works, the chalk the success up to their quick action. They denigrate project planning tools of nearly every stripe. They're also typically very bad communicators and don't manage time well. But in the end, the need for quick action resulted from the immense dis-ease the person feels around planning, brainstorming, and up-front analysis. The cycle repeats on every project. There must be an anti-pattern that describes this kind of behavior...
- rosser 9y ago
  > There must be an anti-pattern that describes this kind of behavior... Well, the anti-pattern that describes this kind of logic is the Straw Man. If all Design Pattern articles were theoretical blah blah blah, The Fine Article might have a point. They aren't. Not even the majority. As long as we just point to the (bad) minority, and act as if they're representative of the whole, then we can continue to hate all articles about design patterns, and play — because this is just as much a form of "play" as the "learning" or "avoiding" techniques being decried — in our preferred, and specifically unstructured way.
  - euske 9y ago
    Can you pick one DP article that seems good to you, please? I won't complain about the article you'll mention. In both OP and your comment, the lack of a concrete example irks me.
    - couchand 9y ago
      All of Ward's Wiki.
    - geezerjay 9y ago
      It seems to me that those making blanket statements on how design patterns are bad or useless are actually the ones who have an obligation to support their baseless assertions. Meanwhile, it seems rather obvious that similar problems can be solved by similar solutions, and experience derived from solving those frequent problems can be levetaged to avoid reinventing the wheel every single time that very same design problem pops up. These solutions have a name: design patterns. It boggles the mind how some people insist in claiming that reusing tried and true solutions is useless.
- skizm 9y ago
  I think the author was saying he hates articles about design patterns, not the actual patterns themselves.
- freshhawk 9y ago
  I thought it was explained really clearly at the very beginning: It's what those cargo cult architecture conversations are full of. The ones where people sound smart but aren't actually designing anything useful. I think the author might be taking it a bit too far, but they are certainly describing a real thing that I see all the time. Which is bad engineering choices made without thinking and then justified with a string of design pattern terms, used incorrectly.
  - wmccullough 9y ago
    > “The ones where people sound smart but aren't actually designing anything useful.” I’ve been part of lots of teams and teams composed of great and poor levels of talent and I’ve never seen this type of behavior which you describe. Usually the folks getting up in arms over architecture are pissed because folks with experience shot down their idea for reasons of pragmatism and the individual couldn’t handle it because of ego.
    - milesvp 9y ago
      You may have been lucky. One of the worst messes I had to make work was nonsense a senior dev was working on up until he quit. It was a mess of object oriented wankery that soured me to even the term 'object' for years. He needed to implement 6 funtions with a couple of sql statements to do session handling in php, and instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. He was supposed to be done, and it just needed deployment, but it ended up taking me 3 months, and a half dozen late night deployments and rollbacks before I managed to get it working. If I'd been more experienced at the time I would have ripped it all out and just implemented the 6 functions we needed, but I really assumed he'd had a good reason for the nonsense he'd written.
      - itronitron 9y ago
        that reminds me of all the EJB/JBoss/Spring nonsense that soured Java for a lot of people... presumably it was a necessary step but it would have been nice to just skip ahead to web services
- peterevans 9y ago
  To me, this essay read more like a troll; a mish-mash of complaints and anecdotes that don't frankly make any sense when put together. But the author succeeded in getting to the first page of HN, so–congrats? As such, it's hard for me to bring myself to respond to any one point in the piece. It'd be quite easy for most of us to do so, but I suspect that was the intention.
- mcphage 9y ago
  > The article doesn't explain much about why the author hates design patterns. The author doesn’t hate design patterns. They hate articles about them.
  - itronitron 9y ago
    personally, I can't stand to read any article about an 'MVC variant' that has some new idea for how to delineate the difference between model, view, and controller
    - beobab 9y ago
      This. I spent a good long while trying to find out how I was "supposed to do it", only to find out "there are loads of ways", and "it depends". This left me feeling like nobody really knew, and that everyone was just chucking dirt and hoping it stuck.
      - YouKnowBetter 9y ago
        Or as a friend of mine would put it: Coding is closer to art then to sience, and briliant code more like poetry then math. I've been in this industry for over 35 years. On dark days I'd give my left leg for working templates and strickt design patterns. On good days I love the close to absolute freedom we have.
      - geezerjay 9y ago
        It's not that nobody knows. It's as some frameworks prefer to shoe-horn the MVC pattern to their particular implementation which has some nuances, and therefore prefer to create a whole new jargon to dance around that fact. In some cases there are even frameworks who force gui responsibilities onto the model and don't even provide any controllers and yet still feel entitled to call what they did as MVC. Meanwhile,
- Can_Not 9y ago
  > There must be an anti-pattern that describes this kind of behavior... Sounds like a cowboy coder.
deepsun 9y ago
> They had begun work in 2011, but they rejected all of the existing document databases (such as MongoDB or Riak). In 2013 they decided to work on version 2.0 of their software, which would be a complete re-write, but they decided to continue to keep JSON strings in PostGres. That's speaks in their favor, in my opinion. We actually consciously moved the way MongoDB -> PostgreSQL JSONB column, and are pretty happy with that. Sorry, original author, but if you recommended us to use shiny new databases like MongoDB or Riak, we'd probably think of you as a young and inexperienced engineer. Although I agree about Design Patterns. For example, you'd use/no use ReactiveX regardless of whether you know about Observer pattern or not.
- crb002 9y ago
  The #1 enginering design pattern is to obey speed of light transfer of information latency. Moving data into and out of MongoDB has that unavoidable cost, and it is a waste if the only thing you want is JSON formatting of the same data already in your RDBMS.
  - Shikadi 9y ago
    >Speed of light transfer of information latency That's not a thing, at least not in this context or that phrasing.
  - Retra 9y ago
    That's not a design pattern, it's just a constraint that designs have to account for.
  - b4lancesh33t 9y ago
    Overall latency is important. Where it comes from isn't very important. Transferring data a few light-nanos of distance into or out of a colocated Mongo DB instance simply isn't going to move the needle on any important metric. (Disk IO latency might, but that has little to do with the speed of light.)
- tomca32 9y ago
  I believe his complaint isn't about not using MongoDB, but about storing JSON as strings in a database that supports actual JSON(B) data type. As you said yourself, you migrated to PG JSONB columns, not to PG Text columns for storing JSON. So it seems to me that you agree with the author.
dev360 9y ago
This is a really serious indictment, folks: “Also, they were doing some unusual things, such as storing JSON strings in a text field in a PostGres database”
- itronitron 9y ago
  I will keep that section in mind the next time I see a job posting at a startup that requires PostGres experience :)
- Noumenon72 9y ago
  Don't understand if you are being sarcastic. I can say that the giant blobs of XML in our text fields are very annoying. I have to compare them with Kdiff and too many of them don't fit in DBVisualizer's buffer.
  - steve_adams_86 9y ago
    I think sarcastic. Psql has great support for json - they were probably taking advantage of it. If you've already got psql set up in your project and have minimal json storage requirements, it can be all you need. You also gain the possibility of retaining some normalization of the data if necessary, which is a lot more complicated if you throw it all in an entirely different database.
    - grzm 9y ago
      Small nit: psql is the command line client bundled with Postgres (PostgreSQL). And yeah, the JSON/JSONB support in Postgres is pretty nifty. Postgres 10 added full text search for JSON/JSONB columns.
      - steve_adams_86 9y ago
        Oh geez, you're right. It's really the only way I use postgres so I kind of equated the names, but yeah, different tools.
dev360 9y ago
I hate all articles about monads. There, I got it off my chest.
mikekchar 9y ago
I hate to be negative, but as far as I can tell, the only thing this article does is indicate a lack of understanding of design patterns. Equating them to a pseudo-intellectual exercise is missing the point by a proverbial mile. Here's a brief explanation: Often when you are coding, you find an interesting solution to a problem. Then when you look at someone else's code, in a different domain, you realise that they are using a very similar solution. You ask them where they got the idea and they say that they saw it in some code in yet a different domain. So you think, "Hey, this seems to be a useful solution to a problem that occurs in several domains". You tuck it away in the back of your mind and when you see that problem again you say, "I've got a solution to that problem!" and you use it. That's a design pattern. Everybody uses them. The alternative is to bloody mindedly refuse to learn and to use completely novel approaches to the same problems every time you see them. That fact that people write down these solutions and give names to them doesn't suddenly make the solutions ridiculous. The fact that some programmers mindlessly apply "patterns" in the hopes that they can escape thinking doesn't make the solutions bad. That's like saying we should never make libraries because some bad programmers think they can glue 1500 libraries together to make a website without having to know how to program. What the author is complaining about has nothing to do with design patterns. People sitting around building mythical designs that never get built has been going on since before the time of Fred Brooks. There are whole classes of architects, analysts, and consultants who have mastered the art of getting paid big money to talk impressively about software without ever writing a single line of code. Quite a lot of them write popular blogs! That's nothing to do with design patterns. I am half curious to read the author's rants about OO, but I suspect I'll find more of the same -- some programmers wrote some terrible, terrible code and called it OO. It must stop! Sigh...
- Shorel 9y ago
  I'm partial of the explanation of DP as missing language features. In fact, Design patterns all use the human compiler to check for correctness of implementation. PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp." With this mindset, functions (or subroutines) are language patterns in assembler. In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features. http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
jakelazaroff 9y ago
Legit question: where does one learn new design patterns if not from articles?
- jcelerier 9y ago
  ... books by the authors of such patterns ?
ThomPete 9y ago
I love design patterns because they tell me where my company shouldn't be focusing. One thing we did very early on was going after clients where there are no well-established design patterns.
rpdillon 9y ago
> Perhaps I’m being unfair to Design Patterns, but those articles seem like the worst kind of tech writing, the most likely to inspire useless discussion that doesn’t help move a team forward. Design patterns have their place, though I can see merit to arguments that assert they have been emphasized out of proportion to their utility over the years. But this is a strange critique, given the content of this particular article.
unclepresent 9y ago
Not a good read to be honest. Author does not sound like a solid programmer. Examples he is giving actually say he might be a “change chaser” - A person who would make a change just because he can add something new to his CV. The fact that guys he was talking about used PostGres to store JSON as a text field literally means that they chose a simplicity over introducing another dependency from no-sql db with all the cost of supporting it. Unless one needs to search over information stored in JSON it is perfectly and probably disarable to store it as a text field. Author remark “they spent years for what they can spent weeks just by using a framework” is a proof that he has little or no experience of doing such things himself. No framework can save you so much time. I was designing UI using frameworks and using just basic language tools. Difference is in trade off obetween quality of standard framework components over flexibility of desinging your own. Time is not so much different and might even take longer with frameworks as adoption time for frameworks could be long especially for teams with a high turnover. I decided to not read till the end because author did not present himself as a person whose opinion might be useful.
gopher2 9y ago
Anyone have any good articles about design patterns that they've bookmarked or feel like sharing?
codedokode 9y ago
The problem arises when people use something just because they think it's cool and someone wrote about it on Twitter and not because it has clear advantages compared to other solutions. Do not blame design patterns if you don't understand them. But you can blame book authors for not explaining it to you properly; maybe they don't understand the patterns too. Also I disagree about DB and normalization: in most cases the best choice will be SQL DBMS and normalized data. Please let me explain why: - normalization saves you from duplicating data; MongoDB will make you do the opposite. Updating the data will be more difficult and you will spend more time writing the code. - fixed schema will make it easier to understand DB structure for new developers and helps you to detect errors; with MongoDB all invalid data will go straight into the storage and you will spend additional time fixing them later. - foreign keys and transactions save you from saving inconsistent data into the database; MongoDB won't help you with this. Designing a database properly doesn't require much thinking, it is a natural thing and you are not losing time. But I understand what the author is talking about. Recently I was using two of Google's products, Doubleclick for Publishers and Google Analitics. Their UI is super slow, at least on my hardware. One Chromium tab with DFP page consumes over 700 Mb of memory. When I decided to inspect it, I found that on DFP page they used Dart "apps" compiled to JS; each of them was not less than 2.4 Mb. Even the "changelog" app which was just displaying information about recent changes (yes, they did it as a separate app). In Analytics UI, they decided to use Material Design with large number of animations, it is very slow and UI elements are too big for 1280px wide display. It looks more like your legacy enterprise app written 10 years ago in Java and IIS, rather than a Google product. They could just use something simple, like Symfony Framework and jQuery and avoid most of those problems. I think the reason why they didn't is because Google employs smart people and gives them a boring job; to entertain themselves they tried to play with something new, like Dart or make Android-like UI but didn't have enough time to do it properly.
- pjmlp 9y ago
  > It looks more like your legacy enterprise app written 10 years ago in Java and IIS I would like to see this, given that IIS never had an official Java ISAPI module.
  - 9y ago
northwest65 9y ago
I too misunderstood the value of design patterns when I was lad. Dr Mike Lance set me straight, and I'm forever grateful.
CoolGuySteve 9y ago
All these comments are terribly reactionary. I completely agree with the author. Before you write a design pattern, abstraction, or interface, ask yourself: Is this the simplest possible thing that can work? And then: Will I ever touch this code again? And then: How hard would this be to rewrite if the requirements change? Design patterns were meant to future proof code, but usually they just introduce complexity and useless abstraction, or serve to paper over limitations of your language. You probably can't predict the future as well as you think you can. Your program is a document. You can change it. You can make it do anything.
- couchand 9y ago
  > Design patterns were meant to future proof code That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. > paper over limitations of your language. See http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures
  - hinkley 9y ago
    Whenever anyone asks me if they should read Design Patterns by Gamma et al, I tell them to go read Refactoring. If they say they've already read it I tell them to read it again. The patterns are loosely what to do, but that's not the thing that lasts across the years and languages. Refactoring is why and how.
  - geezerjay 9y ago
    > That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. I would add that IIRC Martin Fowler himself, a manwho writes whole books dedicated to desing patterns and software design, is also the man behind the "monolithic design first" mantra.
- watwut 9y ago
  I have read the original design pattern book and future proofing the code was not mentioned. They always started with existing requirements.
codedokode 9y ago
Design Patterns are used very often; you probably just don't notice them. Most of the patterns described by Fowler [1] can be found in large web application frameworks. For example, Ruby on Rails uses Active Record, Page Controller, Template View patterns. If you look at an ORM, for example Hibernate or Doctrine, they use even more patterns described by Fowler. But of course they are mostly used in frameworks. If you are writing a CRUD app, just take a web framework and make everything as simple as possible. [1] https://martinfowler.com/eaaCatalog/ https://martinfowler.com/eaaCatalog/
ncmncm 9y ago
It's much easier to express what's wrong with design pattern chatter: Each design pattern represents a failure in the host language to provide facilities sufficient to abstract the pattern as a library component. when you find yourself relying on design patterns, it is a sign that it is long past time to switch to a more expressive language.
- blain_the_train 9y ago
  Indeed, I wrote a bit about that here https://drewverlee.github.io/tags-output/Design%20Pattern/ https://drewverlee.github.io/tags-output/Design%20Pattern/.
crimsonalucard 9y ago
I get what he's trying to say. I think he expresses it very unclearly. I'll try to elucidate the main idea in an example: If I give a programmer a task. His task is to create an api that can email someone a message with a subject and tell me whether the message is successfully sent. All I need is this: func email(address: str, subject: str, message: str) -> bool I do not need this: Class Email(AddressObject, SubjectObject, MessageObject, ConfigObject, ClientObject).send_mail() The definition of the Email object vs the email function is about 10x more complex with little benefit. The send_mail method is virtually IDENTICAL to the email function, the objects and patterns you are building are just extra cruft you are layering around the email method. Not to mention you literally have to define 5 extra objects as well. It's obvious to me that most of the code is 100% cruft yet why does everyone who is knee deep in design patterns gravitate towards that Email object? I look at Email object and I think: I get what you're doing, but WHY.. what is the point? Are people really unable to see why this abstraction is unneeded? Some clown once told me dependency injection (The example object pattern above) helps with unit testing. I agree. Literally, the Email object has 5 extra objects that need to be unit tested so more unit tests!. More lines of code = more unit tests = a better program... In all seriousness, the core method is send_mail and that cannot be unit tested because it's IO. Everything you build around that method is extra BS that only needs to be tested because you made it exist. Sometimes it baffles me how people just start using design patterns everywhere. I think what's going on is that people reach this cathartic state when they understand a new mind bending concept. Dependency Injection is a bit of mind bender, and this catharsis people feel when they reach a point of understanding blinds them from the downsides of patterns in general. Actually dependency injection is a stupidly simple concept, it's the word "dependency injection" that adds artificial complexity to the concept by making it sound cool and harder to understand.
- nathanaldensr 9y ago
  Of all the patterns you could pick on, you pick on one of the most useful in modern OOP; however, I think you actually intend on picking on dependency inversion, not injection. Dependency injection is simply an automated way to satisfy constructor dependencies in OOP languages where your intent is to invert a dependency graph. I won't go into why dependency inversion (see: Dependency Inversion Principle, the "D" in SOLID) is so valuable because much has already been written on the topic. As far as your email example, sometimes the language's basic type system abstractions (e.g., string, integer, etc.) do not encapsulate a real-world concept sufficiently. Encapsulation failures can frequently lead to bugs when edge cases are hit. I may, indeed, need to create an Address class to replace "string address" parameters if there is validation logic inherent to the existence of an email address in my code. If there isn't, then the base type of string would do just fine, of course.
_pmf_ 9y ago
If you have only done greenfield development and source-based extension (instead of having to either provide 3rd party extension points or use them), your opinion on modularity is invalid.
smadge 9y ago
Patterns exist whether or not you are aware of them or give them a name. Most nontrivial programs will end up recreating patterns whether the programmer is conscious of them or not.

92 points by lkrubner 9y ago

chj 9y ago

The issue I am having with design patterns is that they are full of big weird words that doesn't mean anything to a new programmer.

apo 9y ago

Bizarre. The article doesn't explain much about why the author hates design patterns. The best I could come up with is in this passage: Perhaps I’m being unfair to Design Patterns, but those articles [about design patterns] seem like the worst kind of tech writing, the most likely to inspire useless discussion that doesn’t help move a team forward. Catering to software developers perfectionism tends to be bad for business. And this particular type of article seems to be the most extreme in that regard. To recap, DP articles: - are the worst kind of writing (still no explanation) - likely to inspire useless discussion (sometimes play is a lie?) - catering to perfectionism (this can be said about any tool) The article reminds me of many folks I've met who despise analysis and planning. They're constantly getting themselves into trouble that requires quick action. When it works, the chalk the success up to their quick action. They denigrate project planning tools of nearly every stripe. They're also typically very bad communicators and don't manage time well. But in the end, the need for quick action resulted from the immense dis-ease the person feels around planning, brainstorming, and up-front analysis. The cycle repeats on every project. There must be an anti-pattern that describes this kind of behavior...

rosser 9y ago
> There must be an anti-pattern that describes this kind of behavior... Well, the anti-pattern that describes this kind of logic is the Straw Man. If all Design Pattern articles were theoretical blah blah blah, The Fine Article might have a point. They aren't. Not even the majority. As long as we just point to the (bad) minority, and act as if they're representative of the whole, then we can continue to hate all articles about design patterns, and play — because this is just as much a form of "play" as the "learning" or "avoiding" techniques being decried — in our preferred, and specifically unstructured way.
- euske 9y ago
  Can you pick one DP article that seems good to you, please? I won't complain about the article you'll mention. In both OP and your comment, the lack of a concrete example irks me.
  - couchand 9y ago
    All of Ward's Wiki.
  - geezerjay 9y ago
    It seems to me that those making blanket statements on how design patterns are bad or useless are actually the ones who have an obligation to support their baseless assertions. Meanwhile, it seems rather obvious that similar problems can be solved by similar solutions, and experience derived from solving those frequent problems can be levetaged to avoid reinventing the wheel every single time that very same design problem pops up. These solutions have a name: design patterns. It boggles the mind how some people insist in claiming that reusing tried and true solutions is useless.
skizm 9y ago
I think the author was saying he hates articles about design patterns, not the actual patterns themselves.
freshhawk 9y ago
I thought it was explained really clearly at the very beginning: It's what those cargo cult architecture conversations are full of. The ones where people sound smart but aren't actually designing anything useful. I think the author might be taking it a bit too far, but they are certainly describing a real thing that I see all the time. Which is bad engineering choices made without thinking and then justified with a string of design pattern terms, used incorrectly.
- wmccullough 9y ago
  > “The ones where people sound smart but aren't actually designing anything useful.” I’ve been part of lots of teams and teams composed of great and poor levels of talent and I’ve never seen this type of behavior which you describe. Usually the folks getting up in arms over architecture are pissed because folks with experience shot down their idea for reasons of pragmatism and the individual couldn’t handle it because of ego.
  - milesvp 9y ago
    You may have been lucky. One of the worst messes I had to make work was nonsense a senior dev was working on up until he quit. It was a mess of object oriented wankery that soured me to even the term 'object' for years. He needed to implement 6 funtions with a couple of sql statements to do session handling in php, and instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. He was supposed to be done, and it just needed deployment, but it ended up taking me 3 months, and a half dozen late night deployments and rollbacks before I managed to get it working. If I'd been more experienced at the time I would have ripped it all out and just implemented the 6 functions we needed, but I really assumed he'd had a good reason for the nonsense he'd written.
    - itronitron 9y ago
      that reminds me of all the EJB/JBoss/Spring nonsense that soured Java for a lot of people... presumably it was a necessary step but it would have been nice to just skip ahead to web services
peterevans 9y ago
To me, this essay read more like a troll; a mish-mash of complaints and anecdotes that don't frankly make any sense when put together. But the author succeeded in getting to the first page of HN, so–congrats? As such, it's hard for me to bring myself to respond to any one point in the piece. It'd be quite easy for most of us to do so, but I suspect that was the intention.
mcphage 9y ago
> The article doesn't explain much about why the author hates design patterns. The author doesn’t hate design patterns. They hate articles about them.
- itronitron 9y ago
  personally, I can't stand to read any article about an 'MVC variant' that has some new idea for how to delineate the difference between model, view, and controller
  - beobab 9y ago
    This. I spent a good long while trying to find out how I was "supposed to do it", only to find out "there are loads of ways", and "it depends". This left me feeling like nobody really knew, and that everyone was just chucking dirt and hoping it stuck.
    - YouKnowBetter 9y ago
      Or as a friend of mine would put it: Coding is closer to art then to sience, and briliant code more like poetry then math. I've been in this industry for over 35 years. On dark days I'd give my left leg for working templates and strickt design patterns. On good days I love the close to absolute freedom we have.
    - geezerjay 9y ago
      It's not that nobody knows. It's as some frameworks prefer to shoe-horn the MVC pattern to their particular implementation which has some nuances, and therefore prefer to create a whole new jargon to dance around that fact. In some cases there are even frameworks who force gui responsibilities onto the model and don't even provide any controllers and yet still feel entitled to call what they did as MVC. Meanwhile,
Can_Not 9y ago
> There must be an anti-pattern that describes this kind of behavior... Sounds like a cowboy coder.

deepsun 9y ago

> They had begun work in 2011, but they rejected all of the existing document databases (such as MongoDB or Riak). In 2013 they decided to work on version 2.0 of their software, which would be a complete re-write, but they decided to continue to keep JSON strings in PostGres. That's speaks in their favor, in my opinion. We actually consciously moved the way MongoDB -> PostgreSQL JSONB column, and are pretty happy with that. Sorry, original author, but if you recommended us to use shiny new databases like MongoDB or Riak, we'd probably think of you as a young and inexperienced engineer. Although I agree about Design Patterns. For example, you'd use/no use ReactiveX regardless of whether you know about Observer pattern or not.

crb002 9y ago
The #1 enginering design pattern is to obey speed of light transfer of information latency. Moving data into and out of MongoDB has that unavoidable cost, and it is a waste if the only thing you want is JSON formatting of the same data already in your RDBMS.
- Shikadi 9y ago
  >Speed of light transfer of information latency That's not a thing, at least not in this context or that phrasing.
- Retra 9y ago
  That's not a design pattern, it's just a constraint that designs have to account for.
- b4lancesh33t 9y ago
  Overall latency is important. Where it comes from isn't very important. Transferring data a few light-nanos of distance into or out of a colocated Mongo DB instance simply isn't going to move the needle on any important metric. (Disk IO latency might, but that has little to do with the speed of light.)
tomca32 9y ago
I believe his complaint isn't about not using MongoDB, but about storing JSON as strings in a database that supports actual JSON(B) data type. As you said yourself, you migrated to PG JSONB columns, not to PG Text columns for storing JSON. So it seems to me that you agree with the author.

dev360 9y ago

This is a really serious indictment, folks: “Also, they were doing some unusual things, such as storing JSON strings in a text field in a PostGres database”

itronitron 9y ago
I will keep that section in mind the next time I see a job posting at a startup that requires PostGres experience :)
Noumenon72 9y ago
Don't understand if you are being sarcastic. I can say that the giant blobs of XML in our text fields are very annoying. I have to compare them with Kdiff and too many of them don't fit in DBVisualizer's buffer.
- steve_adams_86 9y ago
  I think sarcastic. Psql has great support for json - they were probably taking advantage of it. If you've already got psql set up in your project and have minimal json storage requirements, it can be all you need. You also gain the possibility of retaining some normalization of the data if necessary, which is a lot more complicated if you throw it all in an entirely different database.
  - grzm 9y ago
    Small nit: psql is the command line client bundled with Postgres (PostgreSQL). And yeah, the JSON/JSONB support in Postgres is pretty nifty. Postgres 10 added full text search for JSON/JSONB columns.
    - steve_adams_86 9y ago
      Oh geez, you're right. It's really the only way I use postgres so I kind of equated the names, but yeah, different tools.

dev360 9y ago

I hate all articles about monads. There, I got it off my chest.

mikekchar 9y ago

I hate to be negative, but as far as I can tell, the only thing this article does is indicate a lack of understanding of design patterns. Equating them to a pseudo-intellectual exercise is missing the point by a proverbial mile. Here's a brief explanation: Often when you are coding, you find an interesting solution to a problem. Then when you look at someone else's code, in a different domain, you realise that they are using a very similar solution. You ask them where they got the idea and they say that they saw it in some code in yet a different domain. So you think, "Hey, this seems to be a useful solution to a problem that occurs in several domains". You tuck it away in the back of your mind and when you see that problem again you say, "I've got a solution to that problem!" and you use it. That's a design pattern. Everybody uses them. The alternative is to bloody mindedly refuse to learn and to use completely novel approaches to the same problems every time you see them. That fact that people write down these solutions and give names to them doesn't suddenly make the solutions ridiculous. The fact that some programmers mindlessly apply "patterns" in the hopes that they can escape thinking doesn't make the solutions bad. That's like saying we should never make libraries because some bad programmers think they can glue 1500 libraries together to make a website without having to know how to program. What the author is complaining about has nothing to do with design patterns. People sitting around building mythical designs that never get built has been going on since before the time of Fred Brooks. There are whole classes of architects, analysts, and consultants who have mastered the art of getting paid big money to talk impressively about software without ever writing a single line of code. Quite a lot of them write popular blogs! That's nothing to do with design patterns. I am half curious to read the author's rants about OO, but I suspect I'll find more of the same -- some programmers wrote some terrible, terrible code and called it OO. It must stop! Sigh...

Shorel 9y ago
I'm partial of the explanation of DP as missing language features. In fact, Design patterns all use the human compiler to check for correctness of implementation. PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp." With this mindset, functions (or subroutines) are language patterns in assembler. In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features. http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

jakelazaroff 9y ago

Legit question: where does one learn new design patterns if not from articles?

jcelerier 9y ago
... books by the authors of such patterns ?

ThomPete 9y ago

I love design patterns because they tell me where my company shouldn't be focusing. One thing we did very early on was going after clients where there are no well-established design patterns.

rpdillon 9y ago

> Perhaps I’m being unfair to Design Patterns, but those articles seem like the worst kind of tech writing, the most likely to inspire useless discussion that doesn’t help move a team forward. Design patterns have their place, though I can see merit to arguments that assert they have been emphasized out of proportion to their utility over the years. But this is a strange critique, given the content of this particular article.

unclepresent 9y ago

Not a good read to be honest. Author does not sound like a solid programmer. Examples he is giving actually say he might be a “change chaser” - A person who would make a change just because he can add something new to his CV. The fact that guys he was talking about used PostGres to store JSON as a text field literally means that they chose a simplicity over introducing another dependency from no-sql db with all the cost of supporting it. Unless one needs to search over information stored in JSON it is perfectly and probably disarable to store it as a text field. Author remark “they spent years for what they can spent weeks just by using a framework” is a proof that he has little or no experience of doing such things himself. No framework can save you so much time. I was designing UI using frameworks and using just basic language tools. Difference is in trade off obetween quality of standard framework components over flexibility of desinging your own. Time is not so much different and might even take longer with frameworks as adoption time for frameworks could be long especially for teams with a high turnover. I decided to not read till the end because author did not present himself as a person whose opinion might be useful.

gopher2 9y ago

Anyone have any good articles about design patterns that they've bookmarked or feel like sharing?

codedokode 9y ago

The problem arises when people use something just because they think it's cool and someone wrote about it on Twitter and not because it has clear advantages compared to other solutions. Do not blame design patterns if you don't understand them. But you can blame book authors for not explaining it to you properly; maybe they don't understand the patterns too. Also I disagree about DB and normalization: in most cases the best choice will be SQL DBMS and normalized data. Please let me explain why: - normalization saves you from duplicating data; MongoDB will make you do the opposite. Updating the data will be more difficult and you will spend more time writing the code. - fixed schema will make it easier to understand DB structure for new developers and helps you to detect errors; with MongoDB all invalid data will go straight into the storage and you will spend additional time fixing them later. - foreign keys and transactions save you from saving inconsistent data into the database; MongoDB won't help you with this. Designing a database properly doesn't require much thinking, it is a natural thing and you are not losing time. But I understand what the author is talking about. Recently I was using two of Google's products, Doubleclick for Publishers and Google Analitics. Their UI is super slow, at least on my hardware. One Chromium tab with DFP page consumes over 700 Mb of memory. When I decided to inspect it, I found that on DFP page they used Dart "apps" compiled to JS; each of them was not less than 2.4 Mb. Even the "changelog" app which was just displaying information about recent changes (yes, they did it as a separate app). In Analytics UI, they decided to use Material Design with large number of animations, it is very slow and UI elements are too big for 1280px wide display. It looks more like your legacy enterprise app written 10 years ago in Java and IIS, rather than a Google product. They could just use something simple, like Symfony Framework and jQuery and avoid most of those problems. I think the reason why they didn't is because Google employs smart people and gives them a boring job; to entertain themselves they tried to play with something new, like Dart or make Android-like UI but didn't have enough time to do it properly.

pjmlp 9y ago
> It looks more like your legacy enterprise app written 10 years ago in Java and IIS I would like to see this, given that IIS never had an official Java ISAPI module.
- 9y ago

northwest65 9y ago

I too misunderstood the value of design patterns when I was lad. Dr Mike Lance set me straight, and I'm forever grateful.

CoolGuySteve 9y ago

All these comments are terribly reactionary. I completely agree with the author. Before you write a design pattern, abstraction, or interface, ask yourself: Is this the simplest possible thing that can work? And then: Will I ever touch this code again? And then: How hard would this be to rewrite if the requirements change? Design patterns were meant to future proof code, but usually they just introduce complexity and useless abstraction, or serve to paper over limitations of your language. You probably can't predict the future as well as you think you can. Your program is a document. You can change it. You can make it do anything.

couchand 9y ago
> Design patterns were meant to future proof code That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. > paper over limitations of your language. See http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures
- hinkley 9y ago
  Whenever anyone asks me if they should read Design Patterns by Gamma et al, I tell them to go read Refactoring. If they say they've already read it I tell them to read it again. The patterns are loosely what to do, but that's not the thing that lasts across the years and languages. Refactoring is why and how.
- geezerjay 9y ago
  > That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. I would add that IIRC Martin Fowler himself, a manwho writes whole books dedicated to desing patterns and software design, is also the man behind the "monolithic design first" mantra.
watwut 9y ago
I have read the original design pattern book and future proofing the code was not mentioned. They always started with existing requirements.

codedokode 9y ago

Design Patterns are used very often; you probably just don't notice them. Most of the patterns described by Fowler [1] can be found in large web application frameworks. For example, Ruby on Rails uses Active Record, Page Controller, Template View patterns. If you look at an ORM, for example Hibernate or Doctrine, they use even more patterns described by Fowler. But of course they are mostly used in frameworks. If you are writing a CRUD app, just take a web framework and make everything as simple as possible. [1] https://martinfowler.com/eaaCatalog/ https://martinfowler.com/eaaCatalog/

ncmncm 9y ago

It's much easier to express what's wrong with design pattern chatter: Each design pattern represents a failure in the host language to provide facilities sufficient to abstract the pattern as a library component. when you find yourself relying on design patterns, it is a sign that it is long past time to switch to a more expressive language.

blain_the_train 9y ago
Indeed, I wrote a bit about that here https://drewverlee.github.io/tags-output/Design%20Pattern/ https://drewverlee.github.io/tags-output/Design%20Pattern/.

crimsonalucard 9y ago

I get what he's trying to say. I think he expresses it very unclearly. I'll try to elucidate the main idea in an example: If I give a programmer a task. His task is to create an api that can email someone a message with a subject and tell me whether the message is successfully sent. All I need is this: func email(address: str, subject: str, message: str) -> bool I do not need this: Class Email(AddressObject, SubjectObject, MessageObject, ConfigObject, ClientObject).send_mail() The definition of the Email object vs the email function is about 10x more complex with little benefit. The send_mail method is virtually IDENTICAL to the email function, the objects and patterns you are building are just extra cruft you are layering around the email method. Not to mention you literally have to define 5 extra objects as well. It's obvious to me that most of the code is 100% cruft yet why does everyone who is knee deep in design patterns gravitate towards that Email object? I look at Email object and I think: I get what you're doing, but WHY.. what is the point? Are people really unable to see why this abstraction is unneeded? Some clown once told me dependency injection (The example object pattern above) helps with unit testing. I agree. Literally, the Email object has 5 extra objects that need to be unit tested so more unit tests!. More lines of code = more unit tests = a better program... In all seriousness, the core method is send_mail and that cannot be unit tested because it's IO. Everything you build around that method is extra BS that only needs to be tested because you made it exist. Sometimes it baffles me how people just start using design patterns everywhere. I think what's going on is that people reach this cathartic state when they understand a new mind bending concept. Dependency Injection is a bit of mind bender, and this catharsis people feel when they reach a point of understanding blinds them from the downsides of patterns in general. Actually dependency injection is a stupidly simple concept, it's the word "dependency injection" that adds artificial complexity to the concept by making it sound cool and harder to understand.

nathanaldensr 9y ago
Of all the patterns you could pick on, you pick on one of the most useful in modern OOP; however, I think you actually intend on picking on dependency inversion, not injection. Dependency injection is simply an automated way to satisfy constructor dependencies in OOP languages where your intent is to invert a dependency graph. I won't go into why dependency inversion (see: Dependency Inversion Principle, the "D" in SOLID) is so valuable because much has already been written on the topic. As far as your email example, sometimes the language's basic type system abstractions (e.g., string, integer, etc.) do not encapsulate a real-world concept sufficiently. Encapsulation failures can frequently lead to bugs when edge cases are hit. I may, indeed, need to create an Address class to replace "string address" parameters if there is validation logic inherent to the existence of an email address in my code. If there isn't, then the base type of string would do just fine, of course.

_pmf_ 9y ago

If you have only done greenfield development and source-based extension (instead of having to either provide 3rd party extension points or use them), your opinion on modularity is invalid.

smadge 9y ago

Patterns exist whether or not you are aware of them or give them a name. Most nontrivial programs will end up recreating patterns whether the programmer is conscious of them or not.