Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How best to learn software design principles?

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 100 posts

Re: Ask HN: How best to learn software design principles?

#81

Post by walshemj »

jalfresi wrote: post #72
kenbot wrote: post #71

Earlier quoted context omitted.

There's certainly great value in reading application source code, but it has nothing to do with physical Architecture. I do wish people would let go of this tired and completely wrong metaphor.

Personally, I think the metaphor is quite apt. Obviously it is a metaphor so there isn't a complete mapping, but where do you feel the impedance mismatch is between the traditional architecture metaphor and software architecture? I'm genuinely curious to know, because I have found the metaphor to be strong enough that I read traditional architecture books to help me understand architecture and design in general in so…

it's a shockingly bad metaphor for software development.

I used to work for a top5 consulting engineer - architects some times just do the very high level design the consulting engineers actually turn this into a practicable design which is then built by the contractors and the navvy's.

And I am sure that my dept boss Dr Shair (one of the pioneers of the cable stay bridge design) would consider him self an engineer and not an architect

Re: Ask HN: How best to learn software design principles?

#82

Post by prometheuspk »

jimbokun wrote: post #39
prometheuspk wrote: post #24

Earlier quoted context omitted.

Would you say that FP itself (not the thought process it generates) would benefit me in mobile application devlopment. It's mostly gaining data and then setting it.

Are you developing for iOS? Swift seems to introduce a lot of FP concepts.

Mostly Android. I was thinking about maybe using Scala just to make something meaningful while learning FP.

Re: Ask HN: How best to learn software design principles?

#83

Post by kenbot »

jalfresi wrote: post #72
kenbot wrote: post #71

Earlier quoted context omitted.

There's certainly great value in reading application source code, but it has nothing to do with physical Architecture. I do wish people would let go of this tired and completely wrong metaphor.

Personally, I think the metaphor is quite apt. Obviously it is a metaphor so there isn't a complete mapping, but where do you feel the impedance mismatch is between the traditional architecture metaphor and software architecture? I'm genuinely curious to know, because I have found the metaphor to be strong enough that I read traditional architecture books to help me understand architecture and design in general in so…

They have almost nothing in common, and it's accidental when they do. For instance:

- Designing software in minute detail beforehand is generally neither necessary nor possible.

- It is impossible for someone to be a capable software "architect" unless they are an experienced software "builder".

- It is impossible for someone to be a capable software "builder" unless they are also capable of designing it.

- Software can be reused once built, and this matters while building it.

- Software is rarely "finished", but continues to grow over time.

- Software can be used by an unbounded number of users at the same time.

- Software can be reproduced infinitely.

- Software can be forked and incrementally changed.

- Anyone can design and build their own software, given some talent and a computer.

- The business motivations for software development are fluid, and often change rapidly over the course of a single project.

I could go on and on. As with many (most?) metaphors, it offers some superficial familiarity, but is ultimately harmful to your understanding.

Software is software. Understand it by reading about software and writing software.

Re: Ask HN: How best to learn software design principles?

#84

Post by pessimizer »

kenbot wrote: post #83
jalfresi wrote: post #72

Earlier quoted context omitted.

Personally, I think the metaphor is quite apt. Obviously it is a metaphor so there isn't a complete mapping, but where do you feel the impedance mismatch is between the traditional architecture metaphor and software architecture? I'm genuinely curious to know, because I have found the metaphor to be strong enough that I read traditional architecture books to help me understand architecture and design in general in so…

They have almost nothing in common, and it's accidental when they do. For instance: - Designing software in minute detail beforehand is generally neither necessary nor possible. - It is impossible for someone to be a capable software "architect" unless they are an experienced software "builder". - It is impossible for someone to be a capable software "builder" unless they are also capable of designing it. - Software…

Other than the top 3, these seem to be differences between software and buildings rather than software designers and architects. In addition, I don't think the first three are true. Lastly, these are distinctions without any actual difference in the context of the metaphor, where "architect" could have been replaced by 'novelist' or 'cabinetmaker' and no information would have been lost.

edit: to be more specific about the top three; the first rests on the word "minute" which can be as large or small as you want, depending on what you're trying to prove. The second may be true now, but that's largely because we lack a specific language of high-level software abstraction, so the only way to learn it is to build a lot of things (the general point of the original passage, btw.) The third is just wrong - plenty of people are useful for building parts of software who would have no ability to design a large application. I suspect that those people are a majority of the industry.

Re: Ask HN: How best to learn software design principles?

#85

Post by mtdewcmu »

mattgreenrocks wrote: post #18

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 r…

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

Re: Ask HN: How best to learn software design principles?

#86

Post by mtdewcmu »

kenbot wrote: post #83
jalfresi wrote: post #72

Earlier quoted context omitted.

Personally, I think the metaphor is quite apt. Obviously it is a metaphor so there isn't a complete mapping, but where do you feel the impedance mismatch is between the traditional architecture metaphor and software architecture? I'm genuinely curious to know, because I have found the metaphor to be strong enough that I read traditional architecture books to help me understand architecture and design in general in so…

They have almost nothing in common, and it's accidental when they do. For instance: - Designing software in minute detail beforehand is generally neither necessary nor possible. - It is impossible for someone to be a capable software "architect" unless they are an experienced software "builder". - It is impossible for someone to be a capable software "builder" unless they are also capable of designing it. - Software…

Architecture is about designing buildings that not only serve their function, but are beautiful to look at. I think that's exactly why some people like "software architect." But, to me, "software architect" evokes grandiose, ornate software design, which serves no purpose, because no one sees it. Users see the software's UI, and the UI ought to be beautiful, but trying to make the internal design beautiful is not only unnecessary, it's counterproductive, because it gets in the way.

Re: Ask HN: How best to learn software design principles?

#88

Post by seanewest »

I sincerely believe that programming has gone through a couple of paradigms over the decades. For instance it used to be a good thing to never be scared of architecting a solution from the ground up (and the best often did) whereas nowadays our ecosystem of libraries and tools are so vast that it much more often is overkill, and the architect mentality often a handicap. (This is obviously just one person's opinion)

Sounds principles are sometimes tied to these paradigms. For instance in past years one could maybe say "never use a tool that you don't know well" whereas nowadays with all of the layers of technologies that you are forced to work with it may have changed to just knowing why you have to use a technology and knowing well the aspects that you are using it for.

Also, there are by now many generations of programmers, and we might not want to admit it but the people that grew up on assembly do tend to have different sensibilities than the people that grew up on scripting languages. With these generations often come ingrained mentalities that are tied to paradigms that are tied to principles which in fact are still subject to change.

Re: Ask HN: How best to learn software design principles?

#89

Post by mtdewcmu »

mtdewcmu wrote: post #85
mattgreenrocks wrote: post #18

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 r…

Articles 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 lect…

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

Re: Ask HN: How best to learn software design principles?

#90

Post by mattgreenrocks »

mtdewcmu wrote: post #89
mtdewcmu wrote: post #85

Earlier quoted context omitted.

Articles 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 lect…

Replying 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…

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

Post reply on HN