My company, DigitalCommons, was invited by Microsoft to participate in a program aimed to encourage and provide access to resources to ramp quickly on the new Small Business Accounting for MS Office. I have to say that MS seems to be getting much better at 1.0 releases, producing a polished, user friendly product with great dev support. Although I haven’t used OneNote much, it looks cool, is easy to get to know, and is extensible. SBA even goes so far as to use the very same API that they expose to ISVs and other developers.
I was at a hands-on lab in Building 20, the Platform Adoption Center, (I like to think of it alternatively as a brilliant showcase and some kind of opiate of developers), and in between grinding code for Intel, I was spinning some code to try out the API for SBA. I was stymied mostly by my shallow (mostly from evaporation, since I had a good course in accounting in college [ok only one, but how many do you need?]) of the basics of the science and practice of accounting. No one there could help me much except for a couple of devs from a company which does financial stuff. Fine. Let’s grep wikipedia:
List of accounting topics – Wikipedia, the free encyclopedia
Ah, there we are. I feel better about much of the API. A lot of my confusion about the design choices they made was due to my perspective. It is heavily biased by my varyingly deep understanding of numerous object models which define the APIs of most MS products (Office, .Net Framework, ADO, SQL Server components, MSI wrappers, ASDI… well, you get the idea). Object models have at least one root object, collections, and children objects. All entities are covered by objects (ideally). In the financial world, it is best to model items as classes (accounts), not objects, and just keep track of the quantity, since apparenly each item is identical and maintaining state (via properties) would be senseless. So the category is an object, not a collection. This was hard for me to overcome, but my desire to understand the domain helped me do it.
This leads me to reinforce my belief that the soul of good development is an understanding of the problem domain to at least the level of a lay-person, if not a journeyman. With this understanding comes some interesting inferences: niches for good software development will always exist, providing a good long term prospect for business, the offshoring movement will stablize or even reverse, open-source will only slowly migrate to areas which are now the staple of proprietary systems since there has to be incentive to develop a level of mastery over certain problem domains, whereas the incentive to build cool tools that have usefulness to the devs is inherent, and finally, developing software is a fast way to care about, and begin to master, a lot of various problem domains.
Because of the need (or compulsion, I suppose) to develop software for it, I have had to develop understandings of call-centers (help desks), exotic metal manufacturing and sales, product marketing through indirect channels, police dispatching and record keeping, tax assessment and property appraisal, 3D graphics and linear algebra, and vector calculus (for games, of course!). Now add accounting to the list. I hope to develop a campaign managment system for community development, and use SBA for the back-end. We’ll see if I can free up the time this summer, and inspire a few individuals to arise and assist me… I hope they like accounting. 😉
-rory