Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Software Books Media Book Reviews

Professional Excel Development 318

r3lody (Raymond Lodato) writes "Over the years, I've read a number of books on Excel programming. Each one seemed much like the previous one, generally talking about writing macros and creating data-entry forms. Professional Excel Development takes the concept quite a bit farther. Rather than giving you the same old tired lessons, this book goes into detail on exactly how to build professional level applications. It even explains how to make your Excel-based application look as though Excel had nothing to do with it. Suffice it to say, this ain't your daddy's Excel book." Read on for the rest of Lodato's review.
Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft Excel and VBA
author Stephen Bullen, Rob Bovey, John Green
pages 936
publisher Addison-Wesley Professional
rating 10/10
reviewer Raymond Lodato (rlodato AT yahoo DOT com)
ISBN 0321262506
summary A remarkably detailed 'how-to' book on creating complete applications using Excel as a base.

The authors, Stephen Bullen, Rob Bovey, and John Green, show a level of sophistication well beyond the norm. They'd rather teach you the proper way to program instead of teaching you how to use Excel. In fact, the first thing they do is distinguish five different levels of usage: Excel users, Excel power users, VBA developers, Excel developers, and professional Excel developers. The book is written for the highest level, so expect a lot of depth.

Rather than simply show how to record a macro and reuse it, they start by talking about coding practices, naming conventions and application structure. That's followed by an entire chapter on worksheet design, including names, styles, validation, formatting and controls. After a chapter on add-ins, they launch into the topic of dictator applications, that is, applications that completely take over the Excel interface and look like a regular, non-Excel program.

The following chapters go into much more detail about wringing every ounce of functionality from Excel, and then turning to the operating system and Visual Basic for more help. After discussing data manipulation with databases, they talk about using XLLs and the C API, VB.NET, and writing Help files to complete the application. The entire structure of the book builds around a time-entry application that is developed from a simple spreadsheet to a full-blown, production quality program. A CD-ROM is also included with all of the source code and multiple examples that are scattered throughout the book.

Reading Professional Excel Development is not something to be taken lightly. The authors have done a fine job putting together a cohesive methodology for using Excel as an application development platform. I know of no other book that covers this platform in such depth. At times I found myself lost in the details, but I suspect a "professional Excel developer" (which I am not) would be delighted in the depth of description and copious examples provided.

I tried to relate a lot of what Stephen, Rob, and John discussed to OpenOffice Calc, to see if it could be ported to an open source environment. I was surprised by how much actually came across. Granted, items in OpenOffice are sometimes in different places, or named differently, than their counterparts in Excel, but most of the same functionality is there. Unfortunately, most of the examples are written in VBA, which doesn't translate cleanly into OpenOffice. Still, with perseverance, you would probably be able to develop most of what is described in the book.

Professional Excel Development is an extremely well-written book that covers the use of Excel to a depth few authors have dared to tread. The text gives you the tools to build applications that are much more than automated spreadsheets. Almost any program your imagination can devise can be created using the techniques given, which is a testimony to the power of Excel. Bash Microsoft if you want, but they do sometimes come up with a winner, and Professional Excel Development allows you to take full advantage of its capabilities.


You can purchase Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft Excel and VBA from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Professional Excel Development

Comments Filter:
  • excel?! (Score:2, Insightful)

    by petermgreen ( 876956 ) <plugwash.p10link@net> on Wednesday April 27, 2005 @05:34PM (#12364887) Homepage
    hmm excel? isn't that what everyone here complains about leading to a huge mess of macros backed onto a spreadsheet that was never intended for it.

    if you think something will grow beyond a triviality a database is a much better idea
  • by HyperChicken ( 794660 ) on Wednesday April 27, 2005 @05:35PM (#12364900)
    Excel book review? IRC chat log? "Converting Users to Open Source- Why Do You Care?"? Has Slashdot suddenly become not so Slashdot?

    This is throwing my entire perception of reality into question.
  • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday April 27, 2005 @05:36PM (#12364919) Homepage Journal
    I'm with you. "Because you can" is a poor excuse for attempting something like that. There are plenty of F/OSS and proprietary development environments that are infinitely more suitable for application development than a scripted spreadsheet ever could be.

    Put another way, I don't do accounting in Python - why would I want to write applications in Excel? Spreadsheets are the right tool for quite a few jobs, but this isn't one of them.

  • by Otter ( 3800 ) on Wednesday April 27, 2005 @05:40PM (#12364957) Journal
    Excel is a fantastically powerful, flexible tool, and also has a portability advantage when working with people who have Office installed, but not Perl or Python (i.e. pretty much everyone). The fact that people here don't know how to do anything more complicated than adding column A to column B doesn't change that.

    Now, if they'd only let me use a Mac at work, instead of making me run Excel on this hideous OS...

    Obligatory link to the god of Excel programming [plala.or.jp]...

  • by Jailbrekr ( 73837 ) <jailbrekr@digitaladdiction.net> on Wednesday April 27, 2005 @05:41PM (#12364968) Homepage
    To quote the first two:

    "Professional Excel Development? Isn't that an oxymoron?"

    "Professional Excel Development is like painting a house with tomatoe paste"

    The entire financial sector bases its existance on Excel. Brokers, bankers, and virtually every banking or stock related position has a deep dependance on Excel. Laugh all you like at the thought of a professional excel developer, but I highly doubt that these firms will simply drop Excel in favour of some smelly nerds coding in C#.

  • by Mantorp ( 142371 ) <mantorp 'funny A' gmail.com> on Wednesday April 27, 2005 @05:43PM (#12364998) Homepage Journal
    It's called the real world, based on the ridiculous comments thus far I suggest a visit.
  • by Anonymous Coward on Wednesday April 27, 2005 @05:45PM (#12365014)
    If you are using spreadsheets to do your accounting it sounds like maybe you still need to work on this "right tool for the job" thing (unless you've just written a fantastic double-entry system in VB for Excel).

    And I can think of lots of reasons to write applications in Excel. The best one being that you probably already have it on your machine (no need to purchase a development environment). Another good one being that probably most of your users will have the "platform" to run your application. What else? How about an insanely good function library, including some amazing graphing tools?

    I try to stay away from MS in general, but you can do a lot worse than developing in Excel.
  • by Anonymous Coward on Wednesday April 27, 2005 @05:48PM (#12365052)
    Well spreadsheets are not programs - but there is no reason not to attach behaviour to a spreadsheet. You probably are happy to write code that manipulates a database - just think of the spreadsheet as a noddy database perhaps.
  • by blincoln ( 592401 ) on Wednesday April 27, 2005 @05:51PM (#12365075) Homepage Journal
    Excel is a fantastically powerful, flexible tool, and also has a portability advantage when working with people who have Office installed, but not Perl or Python (i.e. pretty much everyone). The fact that people here don't know how to do anything more complicated than adding column A to column B doesn't change that.

    I'll give you that. You can do some cool stuff with Excel.

    But why use it as essentially an application runtime when you could be using .NET, or Java, or C/C++?

    If the advantage is supposed to be that it gives you a basis for storing data, my response would be that spreadsheets are not databases (as much as office workers like to pretend they are), and trusting production data to an XLS or CSV file is unwise.

    The idea of developing "professional" application in Excel seems to me like ricing out a base model Civic and pretending it's a real race car. You can do it, and the Civic will go pretty fast, but why not get an actual sports car instead of putting a ton of time and effort into working around the limitations that come from starting with a family vehicle?

    Years ago I worked at an internal corporate help desk, and I saw way too many people spending way too much time doing wack-ass shit in Excel when they could have used Access and done it all with a single SELECT statement.

    This is even more extreme: developers tying themselves to what is not only a proprietary platform, but one that will almost certainly break their app as soon as MS releases the next version.
  • Re:Programming (Score:4, Insightful)

    by poot_rootbeer ( 188613 ) on Wednesday April 27, 2005 @05:52PM (#12365087)
    Please don't let your students use basic or visual basic, it will destroy any chance of learning to write real code.

    Malarkey. I started programming in Tandy BASIC in the early 1980's, and it didn't instill in me any bad habits that I was unable to shake once I moved on to Pascal, C, C++, Perl, Java, etc. "GOTO Considered Harmful"? In modern high level languages, yes, we have more elegant syntaxes for branching. But in assembly, what is a JMP instruction anyway but a GOTO?

    Visual Basic, I have no experience with and do not wish to gain any.
  • Re:Uh, yeah.. (Score:5, Insightful)

    by ScentCone ( 795499 ) on Wednesday April 27, 2005 @05:53PM (#12365097)
    But it's certainly possible to approach the range of things that Excel can do (which are substantial, especially when you use ODBC, etc., to patch into huge databases, etc) with a professional set of skills and business sensibilities.

    A well-conceived Excel file can carry with it everything you need for a pretty elaborate bunch of data crunching and presentation, and that can hop from machine to machine very easily. Sales people in the field working up quotes, or managers chewing on inventory info before making a buying decision at a meeting - certainly they could just "use" a spreadsheet to do all of that, but having a purpose-specific UI sitting on top of it (without having to drag around other runtimes, etc) can really help when you're dealing with non-power-users.

    "Professional level" can also refer to presentation sensibilities. For example, wise use of font families and graphs can make the tool's output more useful in a wider variety of settings. A pro knows how to wrap it all up in a smooth package, even if some of the logic is very simple. But a huge, complex, what-if business plan package friendly to investor-type users... that's a very cool type of app, with Excel running under the hood.
  • by ion_ ( 176174 ) on Wednesday April 27, 2005 @05:56PM (#12365129) Homepage

    With some Excel(R) scripting, you can create sophisticated applications that really boost your productivity.

    Here are some programs I use daily:

    • Pacelman [geocities.jp]
    • Excellence(TM) [pouet.net] (sorry to wh.+ my own product -- but hey, it's open source!)
  • by Arker ( 91948 ) on Wednesday April 27, 2005 @05:56PM (#12365130) Homepage

    Umm no. The financial sector uses mainframes, minicomputers, serious database applications... and in many cases even the clients are on OS/2. You may see excel on the desktop of some mid-level folks in the sector, but claiming that 'the entire financial sector bases it's existance[sic] on Excel' is ludicrous in the extreme.


    The stereotype/gratuitous insult about 'smelly nerds' just adds confirmation - you haven't a clue what you're talking about.



  • by Decaff ( 42676 ) on Wednesday April 27, 2005 @06:23PM (#12365403)
    My advice is to not build huge applications in Office unless you have absolutely up-to-date versions.

    My advice is not to build any huge applications in Pffice, as sooner or later your versions won't be up-to-date, and porting this kind of thing between different versions of Office has been a huge and messy exercise in the past, and there is no guarantee it won't be in the future. There is a place for large amounts of code, and it is not tied to Office-type calculations. It should be in libraries which can then be accessed by any application. This is why Windows allows COM/ActiveX development.
  • by InstBrad ( 776890 ) on Wednesday April 27, 2005 @06:30PM (#12365476)
    Had the book been called "Professional OpenOffice Development", this crowd would have fallen all over themselves praising it.

    It gets real tiring listening to all the folks that couldn't say a nice word about a MS product if you paid them. Guess what folks... there are millions and millions of people that use Excel in very sophisticated ways. Why? Because it works well enough. With the help of this book, maybe it will work even better.

    There are many ways to skin a cat. You haven't got a lock on God's One True Programming Language.

  • by foobsr ( 693224 ) on Wednesday April 27, 2005 @06:34PM (#12365526) Homepage Journal
    Put another way, I don't do accounting in Python - why would I want to write applications in Excel?

    The client is willing to sign a cheque.

    CC.
  • Hmmm... (Score:3, Insightful)

    by Bozdune ( 68800 ) on Wednesday April 27, 2005 @06:37PM (#12365552)
    You complain that your customers -- financial analysts all -- are building stuff in Excel. According to you this is bad. I kinda line up on their side of the fence on this one, sorry. You'll have to rip Excel out of their cold, dead fingers, or replace it with something much, much better. And that ain't Calc, which is a me-too, not an evolutionary step.

    I would think you'd be happy at seeing someone try to help these people build manageable Excel models and simple Excel apps. Let's face it:

    1) They will continue to do this, it's fundamental to doing their job. If they need to analyze something quickly, they can't wait for a bunch of quiche-eating Java weenies to argue about the object model for the next six months.
    2) There's nothing you can do to stop them.
    3) Really. Nothing.
    4) So you might as well help them to do what they do, only do it better.

    Reminds me of a Steven Seagal movie:

    "Well, if I can't control you, I might as well use you, right, son?"
    "That's affirmative, sir."

    But that's probably too practical a viewpoint for this forum.

  • Re:Programming? (Score:2, Insightful)

    by Anne_Nonymous ( 313852 ) on Wednesday April 27, 2005 @06:45PM (#12365644) Homepage Journal
    I have spreadsheets that do more math in a second than your daddy could do in an entire day. That's what makes them useful.
  • by aurelian ( 551052 ) on Wednesday April 27, 2005 @06:45PM (#12365653)
    who is masochistic enough to even attempt writing a complex app in Excel?

    The mechanical engineers where I work for starters. Drives me nuts the ridiculous things they do with Excel when they should be using a programming language or something like Matlab..

    You see, because they don't know any better, they assume that there aren't any better ways of doing ANY calculation or programming task other than writing an excel macro. And so they create all kinds of mind-numbingly complicated spreadsheets doing things like Simpson's rule integration and finite-element modelling, and are proud of them.

    These guys are not stupid; they just have a massively greater tolerance for tedious & repetitive tasks than your average geek. In fact it's one of the main things that differentiaites geeks from non geeks, almost a sort of laziness, that means we would rather spend a day learning how to automate something with the proper tools, in a reusable fashion, than one hour doing it by hand each time.

  • Re:limits (Score:3, Insightful)

    by seatbelt123 ( 669131 ) on Wednesday April 27, 2005 @06:52PM (#12365733)
    That is the limit for displaying rows of data. Most users probably don't want or need to see that many records. You can use a pivot table to connect to an external datasource (oracle, text, xml, etc) without any limitations.
  • by ConceptJunkie ( 24823 ) on Wednesday April 27, 2005 @07:09PM (#12365951) Homepage Journal
    Yes, use a Microsoft tool because everyone has it. This is /., right?

    Excel is a very good tool (unlike Access which has no redeeming qualities), but based on my experience, any time you try to develop an application on anything but a real application development system, your app will be difficult to create, difficult to debug and look like crap.

    This includes Excel, Access, and as far as the looking like crap part, Java.

  • by slantyyz ( 196624 ) on Wednesday April 27, 2005 @07:11PM (#12365968)
    A lot of people don't realize that Excel is sometimes a political choice for software development.

    The very fact that Excel is considered a desktop application allows departments to get away (not necessarily rightly so) with creating applications in Excel without having to go through as many approval channels.

    The fact that Excel has an IDE that lets you do many of the things you can do in VB allows you to do sophisticated application programming that can slip under the nose of some bureaucrats.

    I spent a couple of years doing Excel programming after doing "Enterprise" development. It paid the same as my previous work, and for my client, Excel was the platform of choice, simply because the development effort didn't require the involvement of the IT department and its associated red tape. Once I got accustomed to the fact that I could do anything that I could do in a normal development platform, I quickly got over the fact that I was doing Excel work. I used to snicker at the thought of doing Excel and Access work before. But business logic is business logic, so I guess it doesn't really matter what platform you're working on.

    Obviously Excel isn't the programmer's first choice, but it is a capable platform. The business reasons for using Excel as a development platform may be misguided, but it doesn't mean you shouldn't use the same practices that you would use to write anything in any other dev platform. I would think that the goal of the reviewed book is to ensure that.
  • by cmacb ( 547347 ) on Wednesday April 27, 2005 @08:07PM (#12366593) Homepage Journal
    1. Programming is too hard. Why can't I do simple things without writing a program?
    2. Let's come up with something to do ordinary math, tables, reports and so forth.
    3. Let's add higher math function, trigonometry, just in case people need those too.
    4. Oh, a macro language would be nice for repetitive tasks, and fancy formatting, multi-page printing, multi-dimensions.
    5. That macro language doesn't handle all the new features very well, let's model it after a real programming language,
    6. and put API calls in so it can be called from outside, or call to outside,
    7. or interface with a DBMS, or web pages, or any I/O device.
    8. That macro language needs to be compiled, and have object orientation.
    9. Programming is too hard.
  • Excel is not a DB (Score:3, Insightful)

    by wiredlogic ( 135348 ) on Wednesday April 27, 2005 @08:52PM (#12366987)
    Repeat after me. Excel is not a database. Anybody with that many rows of data is likely not using Excel as a spreadsheet (performing calculations).

    If you do need to perform calculations on a dataset this large then either use a true database for storage and do the calculating in the client code or get a specialist tool like Matlab that can be used for numeric analysis.
  • by Stephen Bullen ( 879640 ) on Thursday April 28, 2005 @01:40AM (#12368638)
    That's exactly what drove us to write the book. Over and over again, we've been called in to fix such Excel applications. Rather than say "Don't do that", we recognised that a great many people *do* develop business-critical applications using Excel, but don't have the toolset and mindset to write code that is robust, maintainable, etc. This book attempts to teach much of the discipline and techniques that that we'd expect in 'proper' development environments.

    Regards

    Stephen Bullen
  • by hazem ( 472289 ) on Thursday April 28, 2005 @02:09AM (#12368749) Journal
    "Excel" and "development" don't belong in the same sentence.

    What... can't hack it?

    Let's put it this way. As an analyst (someone else here said that too), Excel is an indespensible part of my job. A lof of work I do is tedious and repititive. So, I write small macros to automate some of those tasks. The next thing I know, I've put a front-end on it and made an application out of it.

    I can't re-write it in some other development system because:
    1) I'm an analyst. And while I can program pretty well in a variety of languages, there is no budgetary justification for buying an IDE in some other language system

    2) Excel with VBA gets the job done quickly and well-enough

    3) I only intend to stay in this job for a year or two. The next person can use my app or leave it... but either way, they still have to manipulate the data on the spreadsheet.

    4) Ultimately, (tied to #3), it's the data and not the application that's important. Other people need to use the data in the spreadsheet, and I'll be damned if I waste a lot of time writing an application that inticipates everything they'll want to do with the data. They know how to use Excel to manipulate it they way they want.

    Uncommented coding in any language is a hardship, but it's also not exclusive to Excel and VBA. Lack of comments and poor programming practices are a symptom of a bad programmer, not a bad environment. And to be truthful, the VBA portion of Excel does, in fact, provide a decent development environment for a small-scale project. There are all kinds of facilities for structured programming - comments, functions/procedures, variables with scope and visbility.

    Really, it's not so bad. As somone else said, Excel is probably one of Microsoft's best products.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...