I want to get a list of books (about 6, at least 2) I can purchase
which are aimed for SW development managers. (I want to purchase
preferably 2 books)

I need it to be applicable to open source and/or commercial
development (I will need to mix these two) on Unix platforms
(Linux/Solaris/etc).

        - requirements gathering, deciding on technologies, planning,
          allocating resources, estimating schedules, staffing,
          budgeting
        - Human Resources (HR) practices, hiring procedures related to
          SW developers - how to hire highly skilled SW engineers
          which will fit (ie. I do not want a general HR book)
        - (If language specific, then C, Java, Perl apply; Microsoft
          technologies probably don't apply)

I want to get links to brief overview and/or table of contents of such
books so that I can see they are at least partially related to my
topics of interest.

I probably prefer to buy from http://amazon.co.uk/ , so that I prefer
to get links from their site or from http://slashdot.org.

What I already have:

  I've already decided to buy The Mythical Man Month: Essays on
  Software Engineering (
  http://slashdot.org/books/980805/1148235.shtml )
  as it is heavily propagated ( search for 'Mythical Man-Month
  site:slashdot.org' to see ) by various people on http://slashdot.org
  which is the site having my respect. I prefer books recommended on
  Slashdot.

  Also, I think (I didn't read it yet) I like the book The Executive's
  Guide to Information Technology
  http://books.slashdot.org/article.pl?sid=03/04/05/
>0553202&mode=flat&tid=126&tid=187&threshold=5
  http://www.amazon.com/exec/obidos/tg/detail/-/0471266094/ref=lib_rd_ss_TC01/002-5330781->8424039?v=glance&s=books&vi=reader&img=5#reader-link
  If we find a similar book on software development, I would be
  probably happy.

If a different category or price for this question would be
appropriate, pls let me know.

Thanks in advance.

---

Request for Question Clarification by mathtalk-ga on 27 Apr 2003 14:18 PDT

Hi, edie99-ga:

I was trying to answer the earlier version of this question.  I'll
unlock it because I'm unclear whether you really mean to have both
questions open.  You may want to cancel the earlier version, or
(conceivably) you wanted two opinions.

I'll await your clarification.

regards, mathtalk-ga

---

Clarification of Question by edie99-ga on 27 Apr 2003 14:31 PDT

I'm sorry for confusion.

I closed the first version of the question. Please take this one and
feel free to finish it. It is exactly the same question.
 
The reason I did it because I was confused - I've read that the system
allows to lock a question only for two hours and this one was locked
much longer. And I've read that system locks all the questions which
contain the name of this system... Never mind. Sorry for
inconvenience.

Hi, edie99-ga:

I lead off with my top two recommendations.  The first is almost a
required book in my mind, the classic analysis of successful software
project teams:

Peopleware: Productive Projects and Teams (2nd ed.) 
by Tom DeMarco & Timothy Lister (Dorset House Publishing)
http://www.amazon.co.uk/exec/obidos/ASIN/0932633439/qid=1051496559/sr=1-1/ref=sr_1_2_1/202-5265960-1674256

Tom DeMarco and Timothy Lister wrote the original book by this title
in 1987, and updated it with additional chapters in 1998.  Their work
spawned commentaries by such industry lights as Ed Yourdon and Larry
Constantine, and its insights (such as "jelled project teams") have
survived becoming cliches.

My second recommendation is aimed at both technical and non-technical
readers who want to understand the Open Source software movement and
the basis for its surprising appeal in the business community:

Embracing Insanity - Open Source Software Development
by Russell C. Pavlicek (Sams)
http://www.amazon.co.uk/exec/obidos/ASIN/0672319896/qid%3D1051497268/202-5265960-1674256

This book opens with a bit of history of the movement and finishes
with a what's what catalog (now slightly dated) of Web sites and Open
Source packages one needs to be aware of.  In between the author does
an especially good job of explaining the cultural mores of the Open
Source movement and how they are tied to its success.

At this point I'll make a couple of admissions of weakness.  First,
all of the books I'm going to mention here are in my personal library.
 While this is somewhat good, in that I'm making first-hand
recommendations, it is also evidence of a parochial selection. 
Readers be warned.

The second admission is a corollary to the first.  I will not have any
recommendations for books on hiring software engineers per se or the
HR aspects of this business, partly because I don't have any books on
the subject.

I do have several years experience with this, e.g. eight years at an
HR consulting firm as a software developer/project manager, but
apparently it's not the sort of thing one can write about
successfully.  Given your preference for the UK version of Amazon, I
suspect you are on the far side of the "pond" from me.  I also suspect
that economic and regulatory circumstances being as they are, advice
about HR practices for software engineers grows dated rather rapidly.

To make up this glaring omission, I'll append a short essay about my
own philosophy on recruiting programmers as a Comment below.

Now back to book recommendations.  I feel very confident of the value
of the two books above, based on your wording of the question.  The
rest of these are perhaps books you should acquire later on, or maybe
ones simply to know about for the time being.

The third recommendation is the first of a series of books on a
software project management philosophy called eXtreme Programming:

eXtreme Programming eXplained: Embrace Change
by Kent Beck (Addison Wesley)
http://www.amazon.co.uk/exec/obidos/ASIN/0201616416/qid=1051499701/sr=2-2/ref=sr_2_3_2/202-5265960-1674256

I don't know how "mature" your software project organization is, but
there's something in this book to offend everyone!  I mean this in a
very positive way.  The eXtreme Programming philosophy is a sort of
medley of outmoded systems development concepts and cutting-edge "just
in time development" ideas, which hang together surprisingly well.  It
might be just the thing for a firm, "young" or "old", embarking on a
project relationship with a new client, a way of revisiting and
possibly revising old shibboleths and sacred cows.

For a more "feet on the ground" nuts and bolts approach to project
management, I'll make my fourth recommendation:

Project Management: How to Plan and Manage Successful Projects
by Joan Knutson and Ira Bitz (AMACOM)
http://www.amazon.co.uk/exec/obidos/ASIN/0814450431/qid=1051501045/sr=1-3/ref=sr_1_0_3/202-5265960-1674256

Broader in scope than just software development projects, this is
still quite a valuable book for delineating the project roles,
scheduling, client management, and a host of useful techniques for
minimizing risk and generating success.

My fifth recommendation is by the champion of the Capability Maturity
Model and focuses on the critical issue of measuring what you want to
succeed at:

Applied Software Measurement
by Capers Jones (McGraw Hill)
http://www.amazon.co.uk/exec/obidos/ASIN/0070328269/qid=1051501624/sr=1-4/ref=sr_1_0_4/202-5265960-1674256

Unfortunately Amazon/UK is reporting this book as having "limited
availability", and slashdot.org's book section does not list it.  If
something of this nature appeals to you, let me know and I'll look
into alternative sources.  It's a book that tries to statistically
document topics where others are content with anecdotal evidence, such
as defect removal by project phase and staff availability factors.

My sixth recommendation is (ummm) a pair of books.  One is something
like a parody of the other, but in a drop dead seriously funny way:

Design Patterns - Micro-architectures for Reusable Object-oriented
Software
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison
Wesley)
http://www.amazon.co.uk/exec/obidos/ASIN/0201633612/qid=1051502292/sr=1-2/ref=sr_1_3_2/202-5265960-1674256

AntiPatterns: Refactoring Software, Architectures, and Projects in
Crisis
by W. H. Brown, R. C. Malveau, H. W. McCormick III, T. J. Mowbrau
(Wiley)
http://www.amazon.co.uk/exec/obidos/ASIN/0471197130/ref=pd_sr_ec_ir_b_h_/202-5265960-1674256

Where "Design Patterns" targets description of useful models for
solving common programming issues, esp. in multi-tier architectures,
"AntiPatterns" goes after the much juicy issues of traps we all fall
into and assigns these "examples of what not to do" humorously
memorable names like "Poltergeist".  Both books contain much
constructive analysis of different kinds of software reuse.

That's it for now, though I still owe you an essay on hiring
practices.  Let me know if something I've said (or failed to
acknowledge) requires clarification.

regards, mathtalk

I got exactly what I wanted with more info than I wished.
And I like the essay mathalk wrote for me. I still keep it in my mind,
it's extremely useful. mathalk definitely has an experienc and is
willing to walk the extra mile... I appreciate it a lot.

Hi, edie99-ga:

Some notes on hiring developers/programmers/software engineers.

In the planning for team resources, one needs to have a budget and/or
forecast of project requirements to work from.  Ordinarily the
"account manager" and "team manager" will sit down to work up these
estimates.  As projects become more committed, esp. once someone
assumes the role of "project manager" or perhaps a "client
relationship manager" associated to the project, it is important to
have the developers available to participate in the initial stages of
project planning.  One of the observations in Peopleware is that
developers are much more committed to time estimates that they have a
hand in formulating than to estimates that are foisted on them by
"management".

So ordinarily the hiring process is somewhat anticipatory in nature,
at least for projects that involve new development (maintenance
projects are somewhat more predictable and often less urgent, so that
a combination of both can help to even out the workload and staffing).
 Depending on the nature of adopted development frameworks
(architectures), the division of labor in project teams can usually be
articulated in fairly simple terms.  E.g., we need a documentation
analyst, a database designer/programmer, a user interface developer, a
business logic programmer, etc.  Initial work estimates can be based
by a project manager on similar project work in the past, or (as often
happens) if there are no good models, then by brainstorming with a
designated system architect.

It is important to hire folks who can work productively with existing
staff, so involving the staff in interviewing candidates is something
I believe in.  However a great deal of homework has to be done
beforehand, and that's what I'd like to drill down on.

Different firms go about locating and screening candidates in a
variety of ways.  An ad in the newspaper or on an Internet "job board"
is apt to produce a large number of responses, and in many cases the
regulatory burden of evaluating each of these in an equal manner can
pose a substantial adminstrative burden.   Therefore it is often
decided, even by firms with substantial HR departments, that the best
use of resources is to "outsource" the initial screening process to a
recruiting agent.

Let us assume that you would be the hiring manager for a set of
positions on a single project, and furthermore that either the HR
department or a recruiting agency has screened out a manageable number
of candidates, based on rather simple descriptions of the technical
skills and depth of experience required.  In the latter respect I also
like to stick to simple (broad) categories, say entry level (which
would range from fresh out of school to perhaps a year of work
experience), mid-level (which would be from perhaps 2 to 4 years of
experience with increasing levels of resonsibility), to senior level
(5 years and up with consistent success in a variety of projects).

Your first step in evaluating the candidates is a close reading of
their resumes.  I find a lot of resumes are constructed around very
dense listing of computer acronyms.  No doubt this is quite useful to
candidates in getting through the evaluation by HR personnel or by
recruiters, since the understanding of requirements at that level is
necessarily limited.  However a good resume will, in my opinion,
reveal something about the candidates communication skills and also
their level of interest in assignments.  The field of software
development is rife with steep learning curves, and innate curiousity
about making programs work is often a critical asset.

For a given position or role, I would pick perhaps five candidates to
do a telephone interview with.  As a hiring manager you may want to
delegate this task to one or more technically minded subordinates,
sufficiently senior so that they do not feel much compulsion to find
fault with the candidates merely out of a sense of self-preservation. 
If you do this, though, give weight to the feedback obtained through
your subordinates.  I have seen a number of poor hiring decisions made
against the advice of technical personnel, where presumably a
non-technical manager was swayed by the confidence and manners of
relatively inexperienced candidates.

The phone interviews should continue until there are at least two, but
preferably three candidates for each position.  This may be overly
conservative in some narrow circumstances, and it may prove
insufficient in others.  But it seems to me one would rather have the
problem of too many excellent candidates to choose from than not
enough.  The time spent in careful search and evaluation before making
a hiring decision is much more rewarding than time spent in devising
"performance plans" and documenting shortcomings of hires that do not
work out.

These 2 or 3 candidates are then ones that I would bring in for a
half-day round of on-site interviews with the existing team members. 
It is certainly not necessary to have everybody meet everybody, but
you will benefit in the long run if the candidates have an opportunity
to discuss their favorite projects with some team members that they
would work with, to demonstrate their ability to ask good questions,
and to do a bit of thinking on their feet.

A good format would be for a candidate to meet separately with one
interviewer who has been given the candidate's resume at least a day
in advance.  The interviewer should understand the role that the
candidate is being considered for, and perhaps one or two designated
points growing out of the resume or the telephone interview that it
would be good to drill down on with the candidate.

As the hiring manager you will probably want to get a little bit of
feedback as the interviewing progresses.  On rare occasions you will
have a "find" on your hands, a candidate who knocks everyone's socks
off and whom you want to make an offer before they walk down the
street to another appointment.  But in general you will want to be the
first and last person (possibly with the exception of an HR person)
that speaks with the candidate, and to reserve any job offer until all
the people who did the interview have a chance to discuss the
candidate.  They can then informally present the results and any
recommendations to you for a final decision.

Once you've identified someone that you want to hire, the process of
negotiating a rate of pay or salary (depending on how they will be
compensated).  It's always good to know what the candidate's
expectations and work history is like, but this is perhaps not the
most important data.  You should know what other developers with
similar skills are paid in your area (esp. in your company!), and this
is again an occasion to get assistance from the HR department and/or
any recruiters working on this assignment.  Sometimes the best
qualified candidate for a position is just too expensive for your
budget.  A great developer can do a lot to earn their keep, especially
on complex projects that have a substantial risk factor.  But in many
roles there is an opportunity to use promising developers with less
experience, saving some money and giving yourself a chance to grow the
talent later on rather than paying for the experience up front.

If you will be the person presenting an offer to a candidate, make
sure that you are clear with them about the informal nature of any
verbal discussion, and the formal nature of a written offer to follow
(done under the auspices of HR).  It would be normal to set a fairly
short period of time for the candidate to give you a decision,
although here if the candidate has a convincing reason for delaying a
decision (perhaps a spouse is awaiting a job offer, etc.) and this is
someone that you really want, there can be room for flexibility. 
Where too much flexibility can really harm you is by giving one
candidate so much latitude to bargain with your offer, than another
viable candidate slips away.

I wish you luck in your new role(s), if that's what you are tackling. 
Let me know if I can clarify my answer posted above.

regards, mathtalk-ga

Eddie,
All the topics you requested are discussed on the following web site
as well.
http://www.c2.com/cgi/wiki?WelcomeVisitors
(The interface of the Wiki Web may seem a bit confusing at first, but
it's well worth exploring and participating in.)

On the topic of books, I believe the book "Design Patterns"
recommended by Mathtalk is nice to have, but it's probably overly
complicated for most people new to this concept. Instead of "Design
Patterns", I'd recommend "Design Patterns Explained:" by Alan
Shalloway. It's not as complete, but it's so much easier to understand
-- it's actually a pleasure to read.
http://www.amazon.co.uk/exec/obidos/ASIN/0201715945/qid%3D1052897847/202-3405229-8555833

As to the rest of the books, the rest of my recommendations will
probably seem like a drop in the ocean compared to all the
recommendations you'll find on Slashdot, Amazon, and the Wiki Web --
so I'll just make one last non-book recommendation and then I'll
excuse myself.

On the topic of recruiting and prescreening software engineers, I'd
recommend you participate regularly in meetings of several local
user/discussion groups in your area. Personally, I find that nothing
beats the physical proximity and the social networks of my peers.

Here are a couple of links to get you started:

Assuming you're in the UK,
http://servlet.java.sun.com/jugs/europe/gbr 
http://www.ukuug.org/

Assuming you're in London,
http://www.xpdeveloper.com/ 

Hopefully, you'll find a couple of good groups in your area,
Good luck.