I'm a professional programmer.
I have never read Design Patterns and couldn't tell you the difference between a Singleton, a Factory, or a Roundabout.
I think UML is a great way to make pretty diagrams that don't mean shit and that any code created from a UML to class generator is going to be overly complex.
I think people who make flowcharts value form over function.
I believe that documentation is way more important than any of these.
This thought brought to you by the machinations framework, which I'm sure might make sense for other folks but just reminds me of all of these things rolled into one, with thie idea that we can boil everything down into simple and repeatable principles:
@craigmaloney you look like the sort of person who hasn’t had an ounce of joy in way too long
why not lighten up a little? play around, we’re all stuck at home together, let’s make some fun out of it
@craigmaloney All of these tools are misused in practice. They were intended to provide meaningful standards for different kinds of documentation. They turned into process by people who wanted to sell convention tickets and speaker slots. I wouldn't ignore their documentation value, but definitely do ignore everything else.
@craigmaloney I agree with @vertigo here. The software engineering discipline is corrupt and so are its organizations - that's why these tools don't work in practice. Basically what software engineers are missing is systems engineering. This stuff has already been figured out it's just people/businesses are too lazy/cheap to implement it.
@craigmaloney I've never used or even learned UML in my life as a computer professional (did not take CS in uni, picked it up the old fashioned way through privilege and nepotism)
@craigmaloney Design Patterns is a good book misused by drones, it's not recipes but "how to identify paths you've walked". It's meant to be read after Chris Alexander's books, not instead of.
UML serves some purpose, in large systems it's good documentation; they've saved my ass in J2EE projects. The visual programming part's not great.
Flowcharts were an incredibly valuable tool for ASM, BASIC, FORTRAN, etc unstructured languages. Still are, but I mostly do pseudocode instead.
@craigmaloney Documentation's a great idea. I've rarely seen it exist, comments are always wrong, most programs no longer have a user manual or even internal help. Mostly they say "ask in discord or stackunderflow".
I barely have any, and I know its value.
Design patterns are really great to deal with the shortcomings of Java, SmallTalk, Ruby and Python. For people stuck using those systems I strongly recommend them. The original Gang of Four, the goofy&commercial “Head First Design Patterns”, and the curious “A Little Java” are all books that have helped me.
Thousands of programs are built on the MVC pattern and understanding it is pretty key.
For other languages, those specific design patterns aren’t great but the general idea is. Or “paradigms” as Norvig calls them.
The design patterns community, or at least adjacent, also have refactoring catalogues and those are absolutely amazing and a lot more universal. Even lisp dorks can have something to learn from https://refactoring.com/catalog
Re flowcharts—remember that they came from the age of GOTO (and then a second wave—UML—with OOP). Obviously with modern languages and tools you don’t need them. But if you are stuck using an OOP language it can be somewhat good to get an UML overview so you can see how everything fits together in your architecture. Ideally you’d want to autogenerate it from code or vice versa instead of implementing everything twice. But UML / flowcharts are not necessary by any means.
@Sandra My biggest complaint with UML and Flowcharts is the "holding it wrong" issue, where the form is more important than the information it conveys. It's having to remember a bunch of things in order to use it when a simple line-diagram with text could convey as much information with less tools to make it.
And like others have stated, once the code starts flowing those diagrams suddenly become a liability as things change.
@Sandra I know they're useful for some but I've seen them wielded as a club more I've seen them used as a shovel.
Same with Design Patterns. I've seen more folks trying to get the jargon right than actually solving the problem.
I'll admit that I was late-night cranky and glib with the original post.There's definitely some value in these tools, but like others mention they have a mysticism and ritual to them that I feel can lead people to believe they're the only way to truly get it right. ,,,
@Sandra It's that mysticism and ritual that I find disheartening in our industry. Worse, it's also used for gatekeeping as a type of impromptu test that one can use to cred-check those who haven't put in the time to learn the ceremony.
This post was also brought on by a Game Mechanics (Design Patterns) book that I leafed through again and realized that we really do love our rituals and ceremonies when it comes to algorithms, regardless of their forms.
@Sandra (Thank you for your thoughtful reply. You gave me space to think more about this, and I appreciate it.)
that we really do love our rituals and ceremonies when it comes to algorithms
Constructing Lego pieces out of smaller Lego pieces, and then building bigger Lego pieces from those Lego pieces, is a sort of lever that can amplify human thinking. For good and bad.
I’m definitively not going to try to argue about both of those very serious caveats re diagrams. They are issues and risks you do need to be mindful of if you bring in diagrams.
But flowcharts and diagrams came from an era of languages like Pascal, Cobol, Fortrand, Assembly. Those languages can really benefit from an external tool — that can mean diagrams, or that can mean macros or code gen (I personally would probably whip up a DSL). I don’t fault someone in 1975 for doing a JSP diagram before opening the editor. Diagramming and structure visualization, carefully applied, have on occasion saved me months of work.
Design patterns, on the other hand, I will stand up for. Getting the jargon right is a legit way of solving the problem, rather than a side track. I mean, ultimately, it’s the human compiler at work, and if you used a real language you wouldn’t need Visitor or Template Method. Some patterns that are absolutely vital to get OK Java or Obj-C look like ridiculous jokes to a Lisp head. The Lisp solution is to extend the language programmatically instead of lexicalizing/codifiying idioms on the human/practice level. On the other hand, that is also a kind of design pattern, just on a different level.
Alexander’s original A Pattern Language is one of the best books I have ever read. Love it to bits.
@Sandra I really need to read "A Pattern Language". Do you recommend reading the first book in the series first (A Timeless Way of Building) or does it stand on its own?
@craigmaloney In one of my early software jobs I was officially the "software architect". I spent weeks creating highly detailed designs for modules and how they would interact, with neat diagrams. Part of my formal training in software had also been about doing this. You start at the high level and break the problem down into increasingly smaller chunks with well defined interfaces which can then be handed off to coders.
And of course as soon as the implementation started my neat diagrams went completely to hell. So it was really all time wasted.
A lot of my early reading about software was during the "mobot" period of the MIT AI lab, so my approach to software is similar to subsumption robotics. Software grows and has emergent properties. It's not like designing bridges or other classic civil engineering. It's more like gardening.
This is an old story, weaker developers follow cargo-cult behavior patterns they see in strong developers.
But thing is, this didn't occur in a vacuum, those of us who are 100% on top of our game need to take some responsibility for creating the culture where a novice is better off banging the table with their SingletonVisitorFactory flashy nonsense than admitting when they don't know how best to approach a problem.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!