80 / 20 Development

That old Pareto rule applies to software development: you can get 80% of the user's desired functionality for 20% of the effort needed to produce a proper application. One iteration of the rule means that you get 96% of the requirement for 36% of the total effort, which is pretty much as far as most people go. Especially when the application is being developed in Office.

There's an excellent essay called From Windows to Cocoa in which Peter Bright describes three kinds of programmers. The first kind are really business analysts, the second are the guys working your company's big programs, and the third are the real craftsmen. Here is Peter's description of the first kind:

“...basically business analysts; they're using Access or Excel or VB6 to write data analyzing/number crunching applications. These things are hugely important in the business world, totally unexciting to anyone else, and the people writing them aren't really "programmers." I mean, they are, in the sense that they're writing programs, but they're not especially interested in programming or anything like that. They don't really care about the quality of the libraries and tools they're using; they just want something simple enough that they can pick it up without too much difficulty. They'll never write the best code or the best programs in the world; they won't be elegant or well-structured or pretty to look at. But they'll work. Historically, as I said, these are the kind of people who Access is made for. Access is a great tool, quite unparalleled. Sure, it's a lousy database engine with a hideous programming language, but the power it gives these people is immense. So Access and VB6 and Excel macros are where it's at for these guys. ”

That's pretty much me and all the people around me. Except there are two levels within this first group. There's the 80/20 developers and there's those of us who try to write robust applications. What's an 80/20 developer? He's the one who writes 80/20 applications.

An 80/20 application dumps you into the middle of the VBA editor with an error message like “Get Range method of current object failed”. When you call the guy (have you ever met a girl who cuts VBA?) who developed it, he says: “You should have removed the “?” from the data” or “Oh, you can't do that with this, it doesn't make sense”.

An 80/20 application has user forms where all the buttons are active and have names that don't quite describe what they do. It is possible to push one of these buttons and get obscure error messages and not be able to get back to where you were. When you call the guy he says “you can't press that button until you've loaded the csv file and entered the magic password. I did explain that.” That's not how a user interface is supposed to work.

An 80/20 spreadsheet has range names that don't describe what the range is for or has in it; it has un-commented code, functions that replicate something that there's a method in the object model to do, non-descriptive variable names, no error-trapping, no exception-handling... and it's hell to maintain.

Sure the 80/20 application does what the users want it to do. Almost. If treated with kid gloves and fed only carefully-prepared data.

For reasons I don't understand, people think that just because it's Microsoft Office, they don't have to read anything. There is more to learn about the Excel object model than there is in the usual first-year undergraduate course of mathematical methods. Learning Java with all its main libraries as well as finding your way round Eclipse or NetBeans will fill up more space in your head than a geology degree. There are 700-page books full of the tricks and annoyances of Excel, Access and Word.

You need time to develop an application which will let you find your way round the object models. That's what you don't have. Bash this report out, run that simulation, cut that query, attend this meeting, make up that presentation. Busy work that benefits nobody. We're not here to learn things, we're here to fill in forms, work processes and make the company money.

Well, you can't do what you don't know how. You can't be innovative if you don't get time to think, read and talk with other people. You can't do things smarter if you're permanently dumb.

Steve McConnell's Code Complete is pretty much everything most people will need and want to know about good programming style. Buy, read, enjoy and digest. Even picking three things from it to improve your programming will help.