Jon Kern from TogetherSoft, doing this since the 80′s.

Trick Q: How is software built? What’s the most important piece? Requirements? Customers? A problem? A: 1. People 2. Process, and 3. Tools

Q: How do we start? Use cases? Architecture? Domain? Just start coding? Is architecture emergent? A: It can be … [...]]]> Notes from TheServerSide Java Symposium March 2009

Jon Kern from TogetherSoft, doing this since the 80′s.

Trick Q: How is software built? What’s the most important piece? Requirements? Customers? A problem? A: 1. People 2. Process, and 3. Tools

Q: How do we start? Use cases? Architecture? Domain? Just start coding? Is architecture emergent? A: It can be … as long as the right amount is “emergent” soon enough, lest you end up with a lot of wasted efforts and excessive refactoring.

Typically 10% of the project time is architectural.

His talk has a lot of good information in the slides, that only partially coincides with his conversation. His main point is “balance” in architecture — never let one area of activity get too far ahead of others. You don’t need all requirements prior to defining architecture.

Then he discusses several example cases. I guess mostly it seemed fairly obvious to me.

Link to the presentation here.