Does anyone have any good resources for learning how to better architect systems? Other than, say, The Architecture of Open Source Applications: <a href="http://aosabook.org/en/index.html" rel="nofollow">http://aosabook.org/en/index.html</a><p>Reading source code of prominent projects is a good way to get better, but it's hard to understand the architecture if you aren't aware of the design constraints/requirements that led it to be the way. Surely there must be a way to fast track this to some extent. Under the deliberate practice model by Anders Ericsson's (i.e. the 10,000 hour rule), simply reading and understanding code is suboptimal because of the lack of immediate feedback on your understanding. I think it'd be interesting to see tutorials/guides that showed how a system design has changed throughout its history as well as the reasons for those changes.
Bram hints at this, but doesn't quite make it as explicit as I would: the thing that distinguishes great programmers is the ability to understand <i>how the pieces interact</i>. Anyone can understand how one piece of code works, even if it's fairly complex. A good programmer can understand how one very complex piece of code works. However, any modern codebase of any significance is impossible for <i>anyone</i> to understand as a single monolithic whole. The key ability is to create a clean mental model of each piece, even if the actual implementation or interface of that piece is nowhere near so clean, and put those models together to understand all the "between the cracks" stuff. That's the key bit of genius behind BitTorrent, for example. It's not that the individual pieces are so special, but that the emergent behavior of those pieces interacting with one another is very beneficial.
Fascinating discussion in the comments about version control. This, in retrospect, is particularly good:<p>"If distributed operation is such a key feature, why is Subversion enjoying the amount of marketplace success it has?"
Why everyone has to write new code to learn?<p>I find best way to learn is to read existing code. When I find interesting project, I download source code and read it from top to bottom. I may even fix a few bugs before hitting compiler.
> My suggestion for learning software architecture is to practice. Obviously you can't practice it by doing hundreds of projects, because each one of them takes too long, but you can easily design a hundred architectures for problems which only exist on paper, and where you strive to just get the solution to work on paper.<p>But, how do you get feedback to tell you if you're making the right or wrong decisions?
Thanks for adding the 2004. I wondered why he was still bashing poor subversion and talking about codeville. Interesting thoughts otherwise. When I interview potential co-workers I ask what makes good code and it's interesting to hear the variety of answers. Definitely one of the best interview questions I have discovered. I think Mr. Cohen would pass my interview :-)
Changing things dramatically for the better always seems to involve "forgetting what you know", ditching everything, and starting from scratch, doesn't it?<p>In relation to the other post about the Core Infrastructure Initiative here, you could use that principle and realize that funding and improving OpenSSL, will still keep things more or less as "secure" as they've been until now. But to truly improve the security of the infrastructure of the Internet, we need to rethink things from scratch, and fund and adopt those, too (in browsers, operating systems, etc).
I'd also include knowing a lot about computers. Like how they work at a low level, how they represent numbers, low level networking protocol, how the operating system interfaces like interrupts, how processes and threads work. A computer science education really helps, but you'll also have to be able to solve problems and think about how theory and real physics world collide.