Let's assume that your requirements really are unique. You have developed back office procedures that make your cost of doing business lower and customer satisfaction higher and all you need to do is automate your ideas.
Congratulations! You now get to start Step One of software development: Analysis and Design.
There's an old story in software development. If people built airplanes the same way some people build software, they would build an airplane, fill it full of people, shove it off a cliff, and then start building another one. This story is usually told by people who believe that it's possible to design a system so carefully and completely that the code can be written just once and every question the programmer might have is answered in the design documents.
But those of us who have tried it know better. There really is such a thing as "analysis paralysis" where the code never gets written and sometimes, the best way to develop software is to write something that works "well enough" and then improve it. Amazon.com's system sure didn't work perfectly the first time.
But there are other reasons for doing formal analysis and design.
Divide and Conquer
Your office "system" is really a bunch of interlocking subsystems. For some, it might be fairly easy for you to write the code yourself. Others might require the skills of a specialist. You might be able to buy software for some and software might not exist for others. The best way to know is to spend some time actually describing your system in real documents. (Not just in the back of your mind.) Draw some flow charts with inputs, outputs, and process boxes. Think about where the data actually is. (In file drawers? On thumb drives?) And then think about which part of your system will be improved the most with some improved software support.
Documenting your analysis and design can pay off even more if you decide to hire an actual programmer to do the work. You're going to have to tell this programmer what to do somehow. You can do that by talking while the programmer writes down what he thinks you said. Or you can hand him some design documents. As a programmer, I know which method I would rather use.
Thanks ... but you're not answering my question ...
... I hear Jacques saying. He wanted information about Excel VBA macros and I'm dragging him through Econ 101. OK ... Let's get more specific.
Jacques wrote that Visual Studio 2010 didn't work for him. Based on his description of what he does (document formatting, printing a work order) I'm not surprised. Visual Studio and .NET are highly technical tools that, today, are really designed for use by professional programmers to create the backbone of software systems. There really are few tools built into Visual Studio that will help with Jacques' needs. Excel and Word are the tools that will do what he needs and he will need to stick with them - in some way - to do what he wants.
In previous years, Microsoft has offered VSTO - Visual Studio Tools for Office - but that idea crashed and burned like one of those airplanes shoved off a cliff. (You can read my original analysis here, here and here.) Starting with Visual Studio 2010, they have a totally new idea that I actually haven't investigated yet. The Professional and above versions of Visual Studio 2010 have a whole section of "Add-In", "Template", "Workbook" and "Document" projects for selected Office 2007 and Office 2010 products . Hopefully, this will get them back on the right track. Perhaps an About Visual Basic reader will contribute their experience with these new Visual Studio 2010 tools.
Motivated amateurs can write their own software using todays VB.NET, but in my experience, it takes years of effort to actually get good enough at it to write the code for a sophisticated professional system. But don't let this stop you from trying. Who knows? You might try it and then decide to switch to a new business: Software Developer!"
