The folks at Heroku have the 12 Factor App https://12factor.net
Ask HN: CS papers for software architecture and design?
41–50 of 104 posts
Re: Ask HN: CS papers for software architecture and design?
#42For me, it would be: 1. actor model of computation ( https://arxiv.org/abs/1008.1459 ) 2. map reduce ( https://research.google.com/archive/mapreduce.html )
On the industrial side, Jim Gray's paper complements Hewitt's nicely. http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf (On second thought it helps to have Armstong's thesis on Erlang as a bridge between them, but I can't find an easily downloadable link at the moment.)
I also like the set of slides Paranoid Programming - Techniques for Constructing Robust Software [1] from Stratus Computer. They were discussed here earlier this year [2]
[1] http://ftp.stratus.com/vos/doc/papers/RobustProgramming.ps
Re: Ask HN: CS papers for software architecture and design?
#43In general, CS (the science) does not often concern itself with the kind of architecture decisions day-to-day programmers deal with.
Instead, the field tends to offer architecture advice in particularly hairy areas (DB design, distributed FT consensus, etc).
In my opinion, that’s how it should be - the goals of academics are very different to those shipping code in the real world. A great developer will be aware of when to turn to academia and when to turn to industry best practice - too often developers are not aware that they are wondering into a hairy area, and end up re-inventing flawed and inefficient versions that are well understood.
Re: Ask HN: CS papers for software architecture and design?
#44I used to be very interested in Software Architecture, in fact I've read many of the papers cited here.
When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product/customer side of it.
The last couple of years I've been de-emphasizing software architecture as an interest, and have been paying much more attention to how product teams build successful products, what the patterns are, etc. I was lucky enough to work at Facebook for a while and got to see (and learn) a very successful working model of product development.
So, while I'm not saying that software architecture is not important (it is), also pay attention to the product/customer side: what choices (software, organizational, hiring, business) allow you to move fast and iterate, to release early and often, to run A/B tests, etc.
I think good software engineers are just as much product guys (and data guys) as they are software guys.
-
Re: Ask HN: CS papers for software architecture and design?
#45I used to be very interested in Software Architecture, in fact I've read many of the papers cited here. When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product/customer side of it. The last couple of years I've been de-emphasizing software architecture as an interest, and have been paying m…
Agreed, good architecture doesn't come into play until you need to add a lot of complex features or scale significantly. Initially architecture doesn't really mean squat. I would concentrate on making the codebase flexible, but that's about it. I've regretted making some of my software with a cool but complex architecture when I should have been focused on what the product does.
Re: Ask HN: CS papers for software architecture and design?
#46I'm surprised no one has mentioned the David Parnas papers: "On the Criteria To Be Used in Decomposing Systems into Modules" is an all-time classic [1]. Much more philosophical than most of the suggestions here so far, but this paper really drove home to me the importance of abstraction in software design. (Also covered in the Morning Paper [2].) [1] https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit... . […
Another excellent Parnas paper: "A Rational Design Process: How and Why to Fake It"
Re: Ask HN: CS papers for software architecture and design?
#47I'm surprised no one has mentioned the David Parnas papers: "On the Criteria To Be Used in Decomposing Systems into Modules" is an all-time classic [1]. Much more philosophical than most of the suggestions here so far, but this paper really drove home to me the importance of abstraction in software design. (Also covered in the Morning Paper [2].) [1] https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit... . […
An excellent textbook that teaches Parnas' approach is "Software
Engineering: Planning for Change" by David Alex Lamb. The
chapter Detailed Design is especially pertinent to this thread. The book is from 1988. I once wrote the author
to ask if there would be another edition. He replied, "publishers aren't interested because it isn't object oriented". In fact, its lessons are as relevant to object-oriented programs as any others.
Re: Ask HN: CS papers for software architecture and design?
#48I used to be very interested in Software Architecture, in fact I've read many of the papers cited here. When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product/customer side of it. The last couple of years I've been de-emphasizing software architecture as an interest, and have been paying m…
Could you elaborate on the insights you gained ?
At least on a high level . It would help a lot of people here .
Re: Ask HN: CS papers for software architecture and design?
#49Earlier quoted context omitted.
I read this more than 5 years ago, I think from a recommendation on HN. But I must have gotten something different out of it than most people. It is advocating a particular architecture. But that architecture is essentially LAMP, as far as I can tell. It's what we ALREADY do!!! From the paper: FRP is currently a purely hypothetical approach to system architecture that has not in any way been proven in practice. It is…
FRP is like excel or well constructed makefiles in that the runtime understands the data flow. Then on updates to any data, you walk through the dataflow graph, running pure functions to update each node.
I think you're talking about functional reactive programming, which they are not talking about. See page 42:
[16] Not to be confused with functional reactive programming [EH97] which does in fact have some similarities to this approach, but has no intrinsic focus on relations or the relational model
Re: Ask HN: CS papers for software architecture and design?
#50Earlier quoted context omitted.
I read this more than 5 years ago, I think from a recommendation on HN. But I must have gotten something different out of it than most people. It is advocating a particular architecture. But that architecture is essentially LAMP, as far as I can tell. It's what we ALREADY do!!! From the paper: FRP is currently a purely hypothetical approach to system architecture that has not in any way been proven in practice. It is…
FRP is a constrained environment, which makes it easier to reason about. PHP is comparatively unconstrained, so when reading code you can’t make as many shortcut assumptions. Of course you could write in PHP in accordance to the rules, but subsequent maintainers, including the future you, cannot trust this self-imposed discipline. In other words, you wouldn’t argue that assembler is just fine because through vigor an…
I probably shouldn't have said PHP, since people have reactions to that language that may confuse the issue.
I should have said stateless Python front ends. Not even CGI/FastCGI, but just plain HTTP front ends. Many large websites use this architecture (YouTube, Instagram, etc.)
An example of something that doesn't follow the architecture is a stateful node.js or Go server.
I would say that the typical web architecture is similar to what they are talking about, with the benefit of existence :)
But you're right in the sense that they are trying to be more strict, starting on page 50:
- benefits for state -- avoid useless accidental state. This is the same philosophy behind SQL.
- benefits for control -- They are being more strict here, but I think it is missing a lot, because sometimes you need control flow.
- benefits for code volume -- I would need to see a real system to evaluate this claim. It's not fair to compare systems that exist with ones that don't :)
- benefits for data abstraction -- SQL agrees here. You don't abstract data. People sometimes make this mistake in their OOP languages, but's incidental.