4 ms·
Don't feel too bad; the pop culture side of programming (a lot of HN) is profoundly anti-design of any type. This is likely a reaction to perceived overdesign o
by mattgreenrocks 12y ago
Don't feel too bad; the pop culture side of programming (a lot of HN) is profoundly anti-design of any type. This is likely a reaction to perceived overdesign of years past, such as in Enterprise Java. Thus, you don't see as many articles about the topic. (I also sense a bit of nerd-indignation over the fact that this is a squishy subject and nobody's completely right).
Read the AOSA book, read Design Patterns, and read something like Domain-Driven Design. Realize that no-architecture is frequently chosen due to ignorance ('pragmatism'). Know SOLID back and forth. Understand why people strive to isolate things when doing TDD. Recognize and know how to decrease coupling, and what the costs of that are. You can practice these concepts every day, and you should, if only to develop the necessary element of taste.
You'll go through a phase where you adhere to these ideas religiously, then eventually assimilate the knowledge so that it becomes almost unconscious.
Best of luck.
- napoleond 12y agoDon't feel too bad; the pop culture side of programming (a lot of HN) is profoundly anti-design of any type. I think that's a surprising characterization; it doesn't jive with my own perception (as subjective as that may be). I think the past decade has (rightly or wrongly) seen a reaction in our industry against enterprise-style "architecture astronauts" but that doesn't equate to being "anti-design". (I'm thinking of the emergence of Rails-like frameworks vs. the JEE stack, and then the emergence of micro-frameworks like Flask/Express/Sinatra after that.) Simple/reduced structure is a valid design choice (of course there are trade-offs that come with that, and of course they aren't always appropriate, but I don't think that means it's popular to be "anti-design").
- jalfresi 12y ago" but that doesn't equate to being "anti-design" I agree fully. I feel that the shift has come about because there has been an unconscious recognition that restricting your tools to one particular problem domain is a valid constraint to make on a design. Enterprise scale, "architecture astronauts" and the like were trying to build tools with which you could build anything, for anyone. And it's clear from the results that this is just a vector for complexity to creep in. Focused tools, from libs to frameworks unashamedly limit themselves to one particular problem domain, or at least used to. I've certainly noticed a shift in that these hard learnt lessons are being ignored in order to add features to frameworks etc; which increase their applicable scope, with the increase in complexity that arises. The primary driver of which appears to be the younger generations desire to use the same tools for different purposes rather than learn a new set of applicable tools for a different problem domain. A good example is the shift from v1 Zend Framework to Zend Framework 2 which just appears to be so heavily "Java/Enterprise" influenced I simply refuse to use it; its far far too complex a framework for what is essentially a framework for building web sites. Building web sites is simple. These modern frameworks make it massively more complex than it needs to be.
- mtdewcmu 12y agoArticles on software architecture are extremely boring. HN tends to vote up articles that are eye-catching and fun to read. Software architecture is focused on giving advice about things that are peripheral to programming, so by nature they are not lively reading if you not steeped in it. And it is opinions. It's all arbitrary, and it changes with the latest fad. Not least, it is patronizing. It's like getting a lecture on proper handwriting or the correct pronunciation of words, and being grimly informed that half of your letters are written incorrectly, and this is unacceptable and must change. Frankly, HN would have to change culture entirely to cover design advice, and I would stop reading.
- mtdewcmu 12y agoReplying to myself/no edit link: The kicker about software architecture is that it gives bad advice about writing software. Now, it's true, the individual bits of advice are all over the map. They don't all agree. But the premise was to prevent bad code from getting written by syntax changes and style conventions, hopefully stopping bad practices in their tracks and encouraging good practices in their place. I think the premise failed -- bad code hasn't stopped -- but the experiment continues, and the net sum of all the advice and conventions has been to encourage more complexity and more code, while simplicity is what yields good software.
- mattgreenrocks 12y agoWhich is why simplicity remains the ultimate sophistication in software architectures. At some point, you cannot continue writing code without structure. Then you slowly and deliberately introduce meaningful abstractions along the necessary dimensions. And no more. Abstractions are also useful to separate the arrangement of work from the actual work itself. These boundaries are useful for dividing up work among colleagues.
- mtdewcmu 12y agoKnuth argues that programming is a form of writing. I agree. Therefore, you should organize code like a book or article, since those are forms of writing that have benefitted from centuries of use and refinement. Even books and articles on complex subjects are fairly light on structure.