Office Development for real developers

  • Article

Do you recall a time when ...

the messages from Microsoft about letting us writing the infrastructure and you as a developer can customize applications by writing the glue?  The glue turned out to be the UI to collect and validate the data, business objects that defined business rules, and process flow (and more validation), and then the code to save the data somewhere in a database.  OK we saved you from writing the database and MTS/COM+ did a lot to save your from writing distributed transaction coodinators and object pooling servers.

Do you recall a time when...

Office development was for developers to junior to do real VB or C++ development.  So the junior developer was assigned to writing Word and Excel macros.   In some cases it was the non IT guy who was a hero to his department because he could write macros in Office (mostly made a mess of things), but he did not have enough discipline to write real desktop applications.  No serious developer would admit there primary focus was to develop office solutions (in other words, VBA and macro development).

I really think we are getting closer to not making your write so much custom code in each tier.  However we have to take a serious look at the tools we have today and get rid of the old mentality of not built here and I am not writing VBA/macros for office for the rest of my career as a developer.  All that said it was just to make me feel better about the amount of Office developemet work and presentations I have been doing over the past months <smile>. 

I have been doing a lot of InfoPath and Office development and presentations lately, so I encourage you to keep an eye on the following technologies if you develop rich clients.

Combine these technologies with SharePoint and BizTalk to reduce the amount of custom code we write today tasks such as capture customer information [think InfoPath], transform it into a language that can be used from application tier to application tier, and/or across platforms [think XML and native capabiltities in Word and Excel to consume XML].  In addition reduce the amount of custom code we often write to present data when we are not in the context of our line of business applications; say for instance when we are reading or creating documents, spreadsheets, and other types of unstructured data or business documents  [Smart Document, Smart Tags and IBF].

Check out John Durrants blog on some of these topics https://blogs.msdn.com/johnrdurant
Also the Office development center on MSDN https://msdn.microsoft.com/office

Happy coding :-)

Ed