I can't speak to "Professional Excel Development", but I can vouch that
Walkenbach's books are excellent references. They aren't teaching you so
much "why to do something a given way" as to simply providing actual
solutions to real world problems.
I think your own assessment of the book "I've taken that phrase to heart."
speaks to whether or not you think it is is a reasonable approach. If the
processes it expounds are working well for you, then whether or not anyone
else in the entire world is using it matters not one whit.
Actually you'll probably find things in any defined process that some folks
'in the trenches' find too restrictive or as not fitting into their working
model. I've been working professionally with Excel and other Office
applications since the days of Windows 95, and what was it? Office 4.5 on 26
3.5" floppies? I'm sure I'd find some things not to my liking - but that
doesn't make them wrong. In point of fact, many small development groups
have woefully inadequate defined processes in place. If you look into the
Carnegie-Mellon Software Engineering Institute's CMMI processes, you'll find
that most such organizations are at the "chaos" Level 1 stage of that system.
If the processes defined in the book put you close to being Level 2 CMMI
compliant, it's a good thing.
To generalize some of the requirements for CMMI Level 2, I'll give you a
short list of things to consider, and if the processes you've developed based
on what you've read in the book fill these needs, then it's been well worth
the money you've paid for it:
Are your requirements for an application/project well defined before
beginning work on it? Have you and the customer agreed on what the goals are
to be achieved with it? Are these requirements actually documented?
Do you have a defined process for evaluating and incorporating requested
changes into the original requirements in place? This means actually writing
stuff down even if you usually only work with phone calls for such things.
Do your test procedures actually test the product to make sure it meets the
requirements? Each test process should tie directly back to one or more of
the active requirements for the product.
Is your development project managed? I.e. do you have some good form of
configuration management in place that is actually used. Doesn't have to be
Visual Source Safe, but that's getting to be a good tool to use. Especially
critical if you have two or more coders working in the same area of a project.
Do you have documented coding standards? If you do, is code written by team
members examined/evaluated to ensure that it meets those standards? This
isn't just talking about things like naming conventions or the way
indentation is used in a code module - it relates to the entire
organization's set of standards regarding getting things done in code. Let's
say you code in C. If your standard is "the" standard for incrementing a
variable as X++ then does everyone use X++ or is someone using X= X + 1?
That kind of thing.
If the book hasn't covered these areas, then it's not what I'd consider a
book on total professional development. It may have thoroughly addressed
coding and design issues within Excel, but it has not addressed the larger
picture of professional product development. The areas I mentioned earlier
are applicable to any software development project, not just Excel. Your
goal should be to make your entire process a managed process with
reproducable results, not just use a single tool within that process well.
But using the primary tool of the process well is obviously a very important
part of it.
And yes, many of the 'requirements' to achieve a Managed Process would be
derided by many small shops - especially the one or two person shops.
Although if they're successful shops they've probably got 80-90% of the bases
covered without even knowing it.
