reviews/gold_rush.xml
<?xml version="1.0"?>
<page title="After the Gold Rush" keywords="">
<item>
<p>Authors: Steve McConnell</p>
<p>ISBN: <isbn>0735608776</isbn></p>
<p>Publisher: Microsoft Press</p>
<p>Reviewed by: <a href="http://www.unixdaemon.net/">Dean Wilson</a></p>
</item><item>
<p>
One of the things that I used to find puzzling was how Microsoft Press
released some of the best books on software engineering and
application development while maintaining the level of quality they
are famous for. I eventually realised that it was simple, all of the
best programmers were writing books instead of code.
</p><p>
When your sitting in front of a screen looking at another bluescreen
cyou may argue with this being a good thing but if you've ever read any
of McConnell's other books such as Code Complete you'll find the trade
off to be acceptable. After the Gold Rush is a book not so much about
how to engineer software as to where the author sees the profession
heading and his views on how we should get there. The book itself is a
brief read coming in at a mere 156 page of actual text and for people
who have read Code Complete the lack of hard technical details may be
off putting. If on the other hand you are planning to make a career
out of developing software then it raises some important points that
bear consideration.
</p><p>
The basic premise of the book is that software development is
currently stagnating in the realm of being a craft where a number of
people have reached and stumbled in to a tar pit. Effort is wasted
pulling all night coding runs in 'code and fix type projects' instead
of being used for sensible planning that allows a lot of the reworking
to be avoided. To a large extent I agree with the author (I may be
biased coming from an engineering background...) in that software
engineering needs to become more of an engineering discipline and less
of an art form where reliability and failed deadlines run riot[0].
</p><p>
The book is broken up in to three sections,
1 The Tar Pit
2 Prospecting
3 Through The Pillars
</p><p>
The first section of the book gives good coverage of where we
currently are and has weathered the three years since the books
release quite well. In-depth explanations and market gathered figures
show how the average project hits trouble due to the JFDI[1] attitude
and then has to go to ridiculous lengths to try and right itself.
Chapter 3 is notable as it delves a little way in to the personality
of a developer and makes both entertaining reading and illustrates the
point that 30 year-old coders with a family are less inclined to work
double hours without a pretty good reason.
</p><p>
The second section of the book is the one I enjoyed the least. It's a
gathering ground of proof on why where we are now is a bad place and
covers some of the suggestions on why the average project techniques
and the best ones are such a world apart and how we can bridge the gap
moving forward.
</p><p>
The third part of the book will either strike a chord with you or
leave you in complete disagreement with the author. The author's views
on why he believes software engineering as a profession needs to have
certification applied to it are presented to the reader. This is a
topic that most people have a view on and while this book gives some
good reasons why it may be needed I doubt it alone will sway many of
the people against certification.
</p><p>
This is followed by the current plans of different States (The author
uses North America and Canada for most of his examples) in regards to
the licensing of software engineers. The emerging plans for software
engineers to be treated in similar ways to other professionals such as
Attorneys and Nurses is intriguing reading and also lightly touches
upon the point of software liability but does not explore it in any
depth, especially from a Free Software point of view.
</p><p>
A short diversion in to the influence and increasing irrelevance of
higher education in the world of high tech jobs rounds out the third
section. Some valid points are raised about the diffusion of good
practises and how one of the most successful practitioners (The US
Agricultural Extension Service) has managed to make so many
large-scale changes quickly and what we can learn from them.
</p><p>
In general I liked the book and it made me think about where software
engineering as a profession could head in the future and my views on
whether I'd still like to be involved. A short, cheap read on where
one of the luminaries of the trade sees us heading.
</p><p>
6/10
</p><p>
[0] I don't expect everyone to agree with that point.
</p><p>
[1] Just Friggin Do It
</p>
</item>
</page>
reviews/gold_rush.xml
<?xml version="1.0"?>
<page title="After the Gold Rush" keywords="">
<item>
<p>Authors: Steve McConnell</p>
<p>ISBN: <isbn>0735608776</isbn></p>
<p>Publisher: Microsoft Press</p>
<p>Reviewed by: <a href="http://www.unixdaemon.net/">Dean Wilson</a></p>
</item><item>
<p>
One of the things that I used to find puzzling was how Microsoft Press
released some of the best books on software engineering and
application development while maintaining the level of quality they
are famous for. I eventually realised that it was simple, all of the
best programmers were writing books instead of code.
</p><p>
When your sitting in front of a screen looking at another bluescreen
cyou may argue with this being a good thing but if you've ever read any
of McConnell's other books such as Code Complete you'll find the trade
off to be acceptable. After the Gold Rush is a book not so much about
how to engineer software as to where the author sees the profession
heading and his views on how we should get there. The book itself is a
brief read coming in at a mere 156 page of actual text and for people
who have read Code Complete the lack of hard technical details may be
off putting. If on the other hand you are planning to make a career
out of developing software then it raises some important points that
bear consideration.
</p><p>
The basic premise of the book is that software development is
currently stagnating in the realm of being a craft where a number of
people have reached and stumbled in to a tar pit. Effort is wasted
pulling all night coding runs in 'code and fix type projects' instead
of being used for sensible planning that allows a lot of the reworking
to be avoided. To a large extent I agree with the author (I may be
biased coming from an engineering background...) in that software
engineering needs to become more of an engineering discipline and less
of an art form where reliability and failed deadlines run riot[0].
</p><p>
The book is broken up in to three sections,
1 The Tar Pit
2 Prospecting
3 Through The Pillars
</p><p>
The first section of the book gives good coverage of where we
currently are and has weathered the three years since the books
release quite well. In-depth explanations and market gathered figures
show how the average project hits trouble due to the JFDI[1] attitude
and then has to go to ridiculous lengths to try and right itself.
Chapter 3 is notable as it delves a little way in to the personality
of a developer and makes both entertaining reading and illustrates the
point that 30 year-old coders with a family are less inclined to work
double hours without a pretty good reason.
</p><p>
The second section of the book is the one I enjoyed the least. It's a
gathering ground of proof on why where we are now is a bad place and
covers some of the suggestions on why the average project techniques
and the best ones are such a world apart and how we can bridge the gap
moving forward.
</p><p>
The third part of the book will either strike a chord with you or
leave you in complete disagreement with the author. The author's views
on why he believes software engineering as a profession needs to have
certification applied to it are presented to the reader. This is a
topic that most people have a view on and while this book gives some
good reasons why it may be needed I doubt it alone will sway many of
the people against certification.
</p><p>
This is followed by the current plans of different States (The author
uses North America and Canada for most of his examples) in regards to
the licensing of software engineers. The emerging plans for software
engineers to be treated in similar ways to other professionals such as
Attorneys and Nurses is intriguing reading and also lightly touches
upon the point of software liability but does not explore it in any
depth, especially from a Free Software point of view.
</p><p>
A short diversion in to the influence and increasing irrelevance of
higher education in the world of high tech jobs rounds out the third
section. Some valid points are raised about the diffusion of good
practises and how one of the most successful practitioners (The US
Agricultural Extension Service) has managed to make so many
large-scale changes quickly and what we can learn from them.
</p><p>
In general I liked the book and it made me think about where software
engineering as a profession could head in the future and my views on
whether I'd still like to be involved. A short, cheap read on where
one of the luminaries of the trade sees us heading.
</p><p>
6/10
</p><p>
[0] I don't expect everyone to agree with that point.
</p><p>
[1] Just Friggin Do It
</p>
</item>
</page>