Artful Independence

If you design things from the start with testing in mind, then your finished system will be both stronger and easier to maintain. One way to accomplish this is to provide a "testing" checkbox (or menu pulldown) in your user interface. Doing so causes a complete design cascade in how you think about development.

It sort of provides you the same comfort level as if you were slipping behind the wheel in a Driver's Training car. It feels like authentic driving but with the added safety that if you forget to step on the brake you actually won't damage anything, as the instructor is watching out for you anyway.

It also allows you the wonderful opportunity to test production interfaces with a development-version of the backing database. Using this practice also promotes looser coupling between components. Of course, make it abundantly clear on the interface (say by changing the global form background color) when the client is in test mode.

This design method does incur some additional logical overhead. Usually you will set a "Testing" Boolean and have places where you evaluate it to set, for example, the database connection strings. This means you also have to provide both the production and development paths and parameters in your config fie.

The saving grace with this approach is that it pretty much clears you from the embarrassment of the all-too-frequent mistake of accidentally copying the development parameters into the production installation. So declare your independence from installation woes: code for testing from the outset and make the development configuration selectable from the interface.

The Art in Two

I've found that you can add a considerable amount of value and "cleanliness" during construction by designing and developing your software on two separate computers. Not simultaneously, but rather in an occasionally alternating fashion. The main point of this is to assure that you have enough of the referenced dll libraries in your project (along with any ancillary files) without constantly cranking around the older useless modules.

Make a full copy of your project folder, clear out the post-compile (and debug) junk, and then zip it up. Mail it to your other computer. Now on the receiving end unzip that puppy and see if you can compile it into something reasonable.

If you use two vastly different computers for this process, say a laptop running Windows10 and a wide screen desktop running Windows 7, you'll get the added quality checkpoint of verifying that your interface is presentable across platforms.

Yeah you need to install your development environment on both computers but this has some subtle advantages as well. Go ahead and square off your development: use the power of two!

Artful Purchasing

When you are charged with buying a software package for your company you will brave the pressure of many conflicting forces. Of course the vendors and their employees have a near manic desire to have you select them over their competitors. Be very wary however of vendors who make the first effort to contact you... I mentioned one such salesman horror-story in an earlier post. It's always better to be at the "selecting" end of the vendor relationship than at the solicitation end.

Your staff may have their preferences based upon their own familiarities or tastes. Yet considering the fiduciary responsibility you owe your employer, your overriding role would seem to require you to execute due diligence to evaluate the vendors on a level playing field.

Begin with some exploratory internet searches to find software with keywords representing some of the more specific requirements. This will give you a clue to the names of the main contenders. Then run a query with the top three package names, along with the words "comparison" or "review." This should retrieve some industry zines with a more thorough examination of what the vendors offer.

Now create a spreadsheet for yourself with "weighted" line-items for the characteristics you need. Remember to add lines for Vendor stability and service record: you're not just buying software, you're buying a service relationship with a company. How are they run? Are they stable? How is their customer service? It can easily take a few days to conduct a thorough review.

After you narrow the field ask the top two choices if you can get a demo. Since the actual folks in your company who will be using the package day-to-day may not all have the skill levels to be comfortable with the software, allow them time to examine it and gather their impressions.

Large purchases may require considerably more effort in the review, including issuing formal RFPs, evaluating the impact of any BPR that may need to occur, and determining how you will integrate the new purchase into existing systems. Don't be shy to retain professional assistance for larger selection efforts.