Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Software Books Media Book Reviews

Professional Excel Development 318

Posted by timothy from the mah-daddy-don't-have-no-excel-book dept.
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 More

Professional Excel Development

Comments Filter:

  • Professional Excel Development (Score:5, Funny)

    by ShaniaTwain ( 197446 ) on Wednesday April 27, 2005 @04:32PM (#12364852) Homepage
    Isn't this like painting a house with tomato paste?

    you could do it, but why?
    • 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.

      • Re: Professional Excel Development (Score:5, Insightful)

        by Anonymous Coward on Wednesday April 27, 2005 @04: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.
        • 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).

          Eek! People purchase development environments?!

          Only teasing, but I guess the point could be made that you already HAVE purchased one if you're using excel. :)
        • 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.

          • Yes, use a Microsoft tool because everyone has it

            Where I develop on Excel is at work, so yes everybody has excel. I mainly use excel for process automation type stuff on an application server actually - I can use perl and lots of other FOSS on my workstation, but getting approval to use it on a production server is another thing entirely.
            The reason I use excel is because I can do just about anything I want (using a nice library of API function wrappers I've written) and it doesn't cost anything - they wo

        • Well, did you ever hear of free software, and that it does have development environments?

          Excel is nice for quickly hacking something together, and I understand that at some point people will get the idea to do more complicated stuff with it, but that doesn't change that it isn't the right tool for anything that ever requires to be changed when working large-scale with data. I see you can use a lot of VB, and add a Form, but then there isn't really much of Excel left that you work with, except maybe the SUM
      • 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.

        Don't think of it as a spreadsheet program. Think of it as a feature-rich set of APIs that are widely distributed... A runtime library, if you will.

      • Re: Professional Excel Development (Score:4, Insightful)

        by foobsr ( 693224 ) on Wednesday April 27, 2005 @05: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.

      • Re: Professional Excel Development (Score:5, Insightful)

        by slantyyz ( 196624 ) on Wednesday April 27, 2005 @06: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.
        • It's why I use Excel/Access - because I can't get the OK to use anything else on a server. We're just setting up a new server and I'm having to get Office put on it to run my xls and mdb hosted precessing. It's a bit depressing to me that I need MS Office on a server, but I do.

          Have you found anything you can't do in VBA that you can in VB? Any limitation I've found I've got round by using the win32 API and/or creating my own objects to replicate whatever I find I need.

      • I do work for some University Profesors in the Forestry department. For this work, excel is often the best tool for the job.

        The main reasons being:
        1. All there colleges/clients already have it.
        2. Most applications involve applying arbitrary sets of data generated by clients to a model generated by us. By packaging our models in excel, users can simply copy/past there data into the input form and hit go.
        3. All of our clients have there own data, and don't want anyone else but them to see it. So we can just

    • Re: Professional Excel Development (Score:5, Insightful)

      by Otter ( 3800 ) on Wednesday April 27, 2005 @04: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]...

      • Re: Professional Excel Development (Score:4, Insightful)

        by blincoln ( 592401 ) on Wednesday April 27, 2005 @04: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.
        • 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.

          The problem there is Access is part of Office Pro, Excel comes with basic Office.

          Excel as part of an overall app can be quite powerful. Data stored in some more stable backend, excel to do the caculations, output elsewhere.

          • Not to mention that Office Pro: Mac doesn't have Access, either, regrettably.
          • The problem there is Access is part of Office Pro, Excel comes with basic Office.

            Ah, I was not aware of that. In our environment, every desktop has the suite that includes Access.


            Excel as part of an overall app can be quite powerful. Data stored in some more stable backend, excel to do the caculations, output elsewhere.

            Right. That's what Excel is for - importing data and transforming it. It's not designed to be the source of data itself.

            Part of my confusion about the premise for this book is (like
            • Right. That's what Excel is for - importing data and transforming it. It's not designed to be the source of data itself.

              Last I checked, Excel was a spreadsheet, not an ETL tool. Excel is a great tool for data entry, because so many people know how to use it without retraining. You don't even need to use a vb form to get data.

              All of the form crap is easily handled with VB.NET, which you can get for super cheap.

              You neglect to consider that you have to send out installers to all the users of the appl
        • "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 only so true . . . this is also why I believe OpenOffice has the potential to really improve productivity in this area (drag 'n drop database creation integrated into the spreadsheet).

      • In your example, you site portability as a benefit of Excel. I would think that the cost of deploying perl/python/whatever on desktops would be trivial compared to the cost of a business setting that supported the long term creation, maintenance, and use off Excel applications. If new development was done as part of a web application, there woudn't even need to be desktop software roll out.

        As a side, if you can do something in a normal programming language as opposed to excel in roughly the same amou

  • Professional Excel Development? (Score:5, Funny)

    by Shant3030 ( 414048 ) * on Wednesday April 27, 2005 @04:33PM (#12364864)
    Sounds like an oxymoron to me.
    • Professional: n.
      Engaging in a given activity as a source of livelihood or as a career: a professional writer.
      (dictionary.com)

      Excel: n.
      Something people use to run their business.

      Development: n.
      Determination of the best techniques for applying a new device or process to production of goods or services.

      Since there will always be a new version of Office, there will always be development to do. And since so many people are stupid enough to pay for it, being a professional developing with it is a

  • limits (Score:2, Interesting)

    by vinnythenose ( 214595 )
    So as long as the spreadsheet it's based on never has more than 65536 entries.... or has that limitation finally been removed?

    • Re:limits (Score:2, Informative)

      by steve6534 ( 809539 )
      Nope.. It's still there in Office 2003

    • Re:limits (Score:3, Insightful)

      by seatbelt123 ( 669131 )
      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.

    • Excel is not a DB (Score:3, Insightful)

      by wiredlogic ( 135348 )
      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.

  • Experience helps too (Score:4, Interesting)

    by chris09876 ( 643289 ) on Wednesday April 27, 2005 @04:34PM (#12364878)
    Although it's necessary to get a good idea of how the tool (any tool) works, you really can't replace good experience working with a spreadsheet.

    Knowing how the technology works is one thing, but knowing how to set up your tables and the data they contain is key. Depending on your use of the spreadsheet, and what you hope to get out of it, there are different ways you can organize worksheets/data. ...without doing things a number of times and thinking through how the system you're going to be building will be used, you'll likely end up with something inferior. Only experience can help you out there. coding practices, naming conventions and application structure are a good start, but that's about it.

  • excel?! (Score:2, Insightful)

    by petermgreen ( 876956 )
    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

  • Programming? (Score:4, Funny)

    by daeley ( 126313 ) on Wednesday April 27, 2005 @04:36PM (#12364911) Homepage
    My daddy didn't need Excel to make grocery lists, nor PowerPoint to give a speech, nor Word to send a letter.

    My daddy also called "spreadsheet programming" "math" and did it in his head or with a slide rule. ;D

  • This better be for Office 2003 (Score:4, Informative)

    by MrAnnoyanceToYou ( 654053 ) <dylan@NOsPam.dylanbrams.com> on Wednesday April 27, 2005 @04:36PM (#12364914) Homepage Journal
    My advice is to not build huge applications in Office unless you have absolutely up-to-date versions. There are certain points in Office 97 / 2000 where you get to a critical load area of your code and suddenly die. Function calls are in the help but don't quite work properly. Old products aren't supported. I'm buying this book because I need it, but building an app with older tools - something many office users are relegated to - is not that great an idea.

    Note: this could all change in Office 2003.
    • 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 c
      • Good point.

        I can't imagine wanting to develop a huge application in Office. I've been modifying one that was built before I got here for the last three months, and it's been.......... frustrating. I've started spending too much time on Slashdot.....

        Anyways. Office is a decent tool to a point, and after that it drops off sharply.
    • In the near future the VBA runtime will be dropped in favor of .NET. They want ALL development, from scripting in the CLI to enterprise apps, to be running on .NET. They were going to release an Office.NET (in 2004?) until they realized it would take them much longer to rewrite Office in .NET or integrate current Office code with .NET - probably cause interrop sucks. At the moment only 3rd party tools can link .NET with Excel in any useful way. So the latest version may be best... for now. But be prepa

  • Amateur Access Development (Score:2, Funny)

    by Anonymous Coward
    I fear that becoming pro will render my qualification for the upcoming Computer olympics void.

    Damn that Olympic committee!

  • God help us (Score:4, Informative)

    by oniony ( 228405 ) on Wednesday April 27, 2005 @04:39PM (#12364945) Homepage
    Heaven forbid any of the traders in the investment bank I work in get a hold of a copy of this. It's bad enough as it is trying to get them to move over to the manageable, scalable applications we build for them without encouraging them to build more spreadsheet solutions.
    • Yeah, but when you're looking for more work, won't some "requirements development"
      in an .xls be just the "God help us" boon you seek?
    • I'll drink to that. Building spreadsheet applications that do things only a spreadsheet can do, is one thing. Building entire databases in excel is another. Sometimes I'd rather see them do it in Access *shudder* than use excel. "But that's what we're familiar with". Let's become more familiar with my friend, Mr. ClueBat (He's french).

      And guess who has to fix it when they screw up?

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

      by Bozdune ( 68800 )
      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

      • Re:Hmmm... (Score:3, Informative)

        by New Breeze ( 31019 )
        Yup, people do it, you just can't stop them.

        Last month I worked on a solution that automated the production of analysis spreadsheets that had previously taken 1 person 20+ hours a week to enter data into. We're talking monsters that have 30000+ formulas in them, you have no choice but to turn automatic recalculation off. They're now done automatically and waiting for them when the users come in now.

        What did the customer do? Grin from ear to ear, and start building more spreadsheets that will need to be

  • all hail the ignorant masses! (Score:4, Insightful)

    by Jailbrekr ( 73837 ) <jailbrekr@digitaladdiction.net> on Wednesday April 27, 2005 @04: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#.

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



      • Are you serious?

        bFinance house:

        Back office: Provide accounting and valuation methods. Typically work off a c-tree database system. Little reason to reinvent the wheel in this role, the scope of back office has been covered by 20 years+ by existing systems.

        Middle office: Provide performance and risk analysis. This may be abstract benchmarking to defined verification of back office. Work tends to be more 'ad-hoc' than back office, may use a variety of systems, often likely to include linking t
    • I personally work for an S&P 500 company whose primary role is as a bank, and providing financial services to other companies.

      I whole-heartedly agree that excel is used a lot when it comes to sharing data amongst colleagues or when providing reports.

      But the serious number crunching, the real work and administration is done mostly with Mainframes and Oracle databases, which are accessed by Delphi, J2EE, and proprietary C++ apps.

      Not that my experiences invalidate your assertion. I just figured I woul

  • Papa? (Score:3, Funny)

    by blueadept1 ( 844312 ) on Wednesday April 27, 2005 @04:41PM (#12364974)
    Suffice it to say, this ain't your daddy's Excel book. You know what, it's generalizations like this that make me sick. My father is a professional Excel developer, and he would be VERY disgusted to hear this comment.

  • I'm happy for the authors and the glowing review of their work, but I continue to wonder that "production" apps be written with that tool (but then, I wonder about VB apps, too). Amazing apps can be written using Excel (I know, I've written some, but only for me) but I think there is a danger in granting spreadsheets the imprimatur of "production". Not because Excel isn't up to the task but more because of the casual treatment of the world of spreadsheets in IT. I don't believe I've ever seen project man

    • I did one time-management application for a small group of people
      where an MS Abcess database published .xls files for people to track time usage.
      Files were returned to an "inbox" folder on the network, and periodically merged to the .mdb for reporting.
      The .xls was the moral equivalent of an HTTP form, and the whole system a beautifully retro batch application.
      Of course, even such a dert simple tool still can have problems; this one was perceived as PHB-ware, and I haven't heard whether or not it ever a

  • I know where they use excel (Score:4, Insightful)

    by Mantorp ( 142371 ) <mantorp 'funny A' gmail.com> on Wednesday April 27, 2005 @04:43PM (#12364998) Homepage Journal
    It's called the real world, based on the ridiculous comments thus far I suggest a visit.
    • It's just a spreadsheet. But FFS use a real programming environment to produce applications. Hell, even use an MS programming environment. "Developing" an application on Excel is the height of short sightedness, it's positively myopic.

    • Just because a certain tool is used in "The Real World(TM)" a certain way doesn't necessarily mean that it is the best tool for the job.

  • but what I really want (Score:3, Interesting)

    by Soong ( 7225 ) on Wednesday April 27, 2005 @04:46PM (#12365033) Homepage Journal
    Is a light weight Free/free spreadsheet either written in Java or otherwise ported to MacOS X. I specifiy "light weight" because OO.org seems just as bulky and bloated as M$-ware.

    • Well, Gnumeric [gnumeric.org] could be possibly ported to Cocoa in Mac OS X because the core portions of Gnumeric are written in C. However, since Gnumeric is a GTK application, it may take some time moving all of the graphical-related stuff to Cocoa.

      As for a Java spreadsheet, I haven't seen a FOSS Java spreadsheet, but it is very possible. Maybe somebody could look at the sources for Gnumeric [gnumeric.org] and OpenOffice [openoffice.org] or xspread as some inspiration

      (While they're at it, perhaps a spreadsheet could be written in GNUstep; I'd like

  • it's called VSTO. You can creat a full expandable, scalable application with it.
    I know, I am doing it now.
    It doesn't use macros, or VBA. You can write clean OO code.
  • I've seen a hell of a lot of spreadsheets but these ones are brilliant. Space Invaders and Pacman coded in Excel [geocities.jp].
    Each cell represents a pixel.

  • 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!)
  • Well, despite the fact I'm a little dubious about using excel as a programming language/platform, it reminded me of a program I had seen many years ago that was 'interesting'.

    It's called Baler and basically took a Lotus 1-2-3 spreadsheet (with macros) and compiled it into a self executing exe. (Yes it was that many years ago that 1-2-3 was the dominant s/sheet under DOS :-/ )

    So I did a quick google and found there is a visual baler. Check out
    http://the-ciba.com/vbaler/vbaler.html [the-ciba.com]

    Knock yourself out, if
  • Kind of reminds me of that time Kif programmed that Holo-Shed program in just 4 million lines of BASIC.

  • He picked the wrong title (Score:5, Insightful)

    by InstBrad ( 776890 ) on Wednesday April 27, 2005 @05: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.

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


      MS would like to tho. And if you use their products, your data and 'programs' are pretty much locked into MS. Single vendor is always and continues to be a bad idea.
  • Yes, it's an MS product and yes there are better ...

    however, consider how widespread Excel really is and you will see more people doing more, which in turn requires more administration and infrastructure ... the very things geeks get paid to build and maintain, oh, and then there's the matter of America's overall increased productivity

    mostly it's good because there's a blind barrage of dummies books, but so few deeper ones that hit the mark ... indeed, I always seem to be looking for a better one
  • Didnt we just have a story about how bad of an idea it was to use a spreadsheet for this sort of thing?

  • Cheaper at Amazon (Score:3, Informative)

    by Arkham79 ( 219828 ) <<ten.drofremoc> <ta> <mada>> on Wednesday April 27, 2005 @06:26PM (#12366139) Homepage
    This book is $32.99 on the Amazon site - save yourself $17 and get it there instead. Here's the link [amazon.com] (no value add for myself)

  • Excel is a great "Swiss Army Knife" (Score:3, Interesting)

    by Anonymous Coward on Wednesday April 27, 2005 @06:27PM (#12366148)
    Excel is reasonably powerful, very customizable, and, most importantly, very accessible to the normal user.

    Case in point - I served as a Mormon missionary for two years in South America. Five months of that was in the mission office making sure things ran smoothly (running logistics, renting apartments, materials, mail, etc.). The mission consisted of roughly 200 people.

    It didn't take long for me to realize that our office of four people was overstaffed and that two of us could be replaced if we used our technology resources more efficiently. Due to the widely different conditions missions around the world operate in (it's impossible to run 300+ units in more than 100 countries the same way), the church does not provide much in the way of standardized software - missions are left on their own.

    I was charged with creating programs to track inventory and missionary statistics (baptisms, contacts, etc.). I COULD have written the whole thing in C or C++ (only languages I knew at the time), but I opted for Excel and Visual Basic for Applications because I knew that it was very unlikely that there would be a steady stream of missionaries in years to come that could code in C or modify things if necessary. But, I was able to teach myself enough VBA in 24 hours to create programs that could do everything I wanted them to do, and they're still used today. They also turned out to be flexible enough to be used elsewhere - I hear that four other missions are using variants of the software I created almost 3 years ago. In the end, our office staff was cut down to two, and even those without great technical knowledge can be used to fill the jobs.

    Excel really is like a Swiss Army Knife - not really the best at anything, but versatile and easy enough for anybody to use.

  • Programming is too hard... (Score:4, Insightful)

    by cmacb ( 547347 ) on Wednesday April 27, 2005 @07: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.
  • Yes, at home, I'm a *nix guy. At work, I use excel. It all started with estimate sheets. It was a simple way to look at a large number of data and have it mean something. Hours on the bottom, materials and subcontractors on the top. Multiply by amounts and markup, and you have a number. Sum the column, and you have the total job cost.

    But when figuring out how much material is needed, it works nice. I take the sign size and add 6" to each side(for large signs) and that gives me a nice rough square fo
  • So many (frankly) BS comments about Excel's relevance to development....

    Where I work we have a team of ten people working with Excel directly supporting about double that number of traders (more than that if you look at our strategic projects). Every other software development group in our firm has more developers than traders paying for developers. We use Excel because it provides a UI that is unrivaled (and because of its rather good - but still not quite good enough for us - recalc engine). We're not id

  • The facts of life (Score:3, Informative)

    by Stephen Bullen ( 879640 ) on Thursday April 28, 2005 @01:37AM (#12368887)
    Firstly, thanks for the review!

    Lots of the comments here have been about whether or not it is 'right' to develop applications based around Excel. As one of the authors of this book, I think that misses the point. The simple fact is that in the real world, there are lots of people who do develop such applications and really need to know some techniques that can make their programs much more robust, maintainable, etc.

    When teaching our children about the facts of life, we can lecture them about abstinence, let them know about lifestyle choices that might or might not be relevant, or we can teach them how to be prepared (physically and emotionally), safe, considerate and responsible. The latter is the attitude we've taken towards Excel development, while also teaching some advanced techniques that might help their activities.

    FWIW, more information about the book and a few sample chapters are available from my web site at http://www.oaltd.co.uk/ProExcelDev [oaltd.co.uk].

Slashdot Top Deals

news: gotcha

Close