Things Every Software Architect Should Know(97-things.near-time.net)
97-things.near-time.net
Things Every Software Architect Should Know
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book
14 comments
Agreed.
The key is to avoid slavishly following a rule. You should not shy away from breaking a rule, provided you have good reasons for the violation. First learn what the good rules are (as applicable in majority of cases) and then learn when to break them. The best practices are not supposed to be carried over verbatim into every development project.
The key is to avoid slavishly following a rule. You should not shy away from breaking a rule, provided you have good reasons for the violation. First learn what the good rules are (as applicable in majority of cases) and then learn when to break them. The best practices are not supposed to be carried over verbatim into every development project.
I think the problem with this book is not about recipes it gives, and way how it approaches the problem, but the problem itself. I spent 8 years working in different software companies, and never met a person with the 'architect' job title, whose job would be different from one of either developer or manager.
Therefore, I personally do not believe in 'software architects'. And this book supports me in this! I went carefully through the list, diving inside some specific topics and it seems that all of them (or overwhelming majority) lie in the field of responsibility of someone who could be described by job title other than architect. "#12 There is no one-size-fits-all solution" -- fine, development issue. "#17 Business Drives" -- fine, management issue. And the the brightest gem of all: "#80 Dont Be a Problem Solver".
Therefore, I personally do not believe in 'software architects'. And this book supports me in this! I went carefully through the list, diving inside some specific topics and it seems that all of them (or overwhelming majority) lie in the field of responsibility of someone who could be described by job title other than architect. "#12 There is no one-size-fits-all solution" -- fine, development issue. "#17 Business Drives" -- fine, management issue. And the the brightest gem of all: "#80 Dont Be a Problem Solver".
I stopped reading after One line of working code is worth 500 of specification and It's never too early to think about performance.
I thought this philosophy was proven flawed!
I thought this philosophy was proven flawed!
Nothing's proven flawed. Both of those pieces of advice work under the correct, narrow circumstances.
If you're building a web start-up, forget specifications. Write code. There is no way to have the slightest clue what you need to specify anyway. Write something that does something useful and put it in front of some users. Go from there. In different circumstances, of course (e.g. while building the software for a major Stock Exchange), this is the absolute worst thing you can do.
If you're building your start-up, it's almost always too early to think about performance. You need to have some vague awareness of whether it will be possible to optimise your code later and keep it clean and simple so that it remains possible, but ultimately I've found that it pays to optimise at the last minute - i.e. optimise when there are performance problems, not before. On the other hand, going back to the major stock exchange example, performance there is likely to be one of your major challenges, so you need someone on the team who is performance-minded and has built a stock exchange before, so that they know where the bottlenecks will be and can ensure those are avoided.
If you're building a web start-up, forget specifications. Write code. There is no way to have the slightest clue what you need to specify anyway. Write something that does something useful and put it in front of some users. Go from there. In different circumstances, of course (e.g. while building the software for a major Stock Exchange), this is the absolute worst thing you can do.
If you're building your start-up, it's almost always too early to think about performance. You need to have some vague awareness of whether it will be possible to optimise your code later and keep it clean and simple so that it remains possible, but ultimately I've found that it pays to optimise at the last minute - i.e. optimise when there are performance problems, not before. On the other hand, going back to the major stock exchange example, performance there is likely to be one of your major challenges, so you need someone on the team who is performance-minded and has built a stock exchange before, so that they know where the bottlenecks will be and can ensure those are avoided.
It's never really too early to think about performance. All you have to do is try not to act early on that. A lot of architecture ideas we have (sane URLs, caching servers etc) are rooted in performance considerations.
There is a difference between things that an architect needs to worry about and the things a developer needs to worry about.
That difference is due to scale - the architect has to think about the application holistically where a developer needs to think atomically.
That difference is due to scale - the architect has to think about the application holistically where a developer needs to think atomically.
Well, O'Reilly recently reported that sales of of computing books in general were off something like 28% for 2008. So starting a new occupation (software archhitect) or pandering to those who'd aspire to the "title" may be a marketing strategy.
According to Amazon (http://www.amazon.com/isbn/dp/059652269X) the book was to be released Feb 13. I put it in my Amz shopping cart so I can let the reviews thereon tell me whether it's at least worth skimming it at Barnes & Noble (all that's available to me locally).
According to Amazon (http://www.amazon.com/isbn/dp/059652269X) the book was to be released Feb 13. I put it in my Amz shopping cart so I can let the reviews thereon tell me whether it's at least worth skimming it at Barnes & Noble (all that's available to me locally).
97 conventional wisdom recipes in an awful, screaming font, linking to explanations. I didn't read them all so maybe there are some gems, but I highly doubt it.
I skimmed through a few. There are a lot of platitudes in there, but a few of them are useful reminders or elaborations of things we know "in the bone", like #18 and #24.
It's not 97 gems. It's 97 screaming headlines. #7: Stand Up! I did that this morning to go to work. My software doesn't seem any better.
Rule one: Rules don't always work.
Rule two: Follow the rules.
The challenge is to know which rules to follow and what "works" means.
Rule two: Follow the rules.
The challenge is to know which rules to follow and what "works" means.
One thing every blogger should know: short lists.
#98 Use Appropriate line spacing if presenting content over 96 lines long
As such, this is perhaps useful as a list of advice to software architects (basically senior senior developers, in my experience), but only with a huge disclaimer that you must figure out for yourself which bits to apply in your current circumstances.
Why is that disclaimer always missing from list of best practices, even when those lists (like this one) contain self-contradictory examples?