

Things Every Software Architect Should Know - alrex021
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

======
swombat
There are no such thing as "best practices". What's "best" always depends on
circumstances.

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?

~~~
kailashbadu
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.

------
smikhanov
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".

------
edu
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!

~~~
swombat
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.

------
CalmQuiet
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).

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

~~~
Deestan
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.

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

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

------
vchakra
One thing every blogger should know: short lists.

------
dmix
#98 Use Appropriate line spacing if presenting content over 96 lines long

