Rewrite or not?

We face this question, “Rewrite or not?” with customers every year.

“We have a custom software application written by [ABC company or programmer] in [XYZ technology]. It works but it has problems. Should we keep it alive and continue modifying it? Or should we start from scratch again and rewrite it?”

That is a very good question. This question of keep alive or rewrite the software has been addressed by others in our software industry. This specific article references the recent rewrite from scratch of the well known project management tool Basecamp by 37Signals, and a timeless article by Joel Spolsky on the same topic but with the opposite view.

The summary of the two opposing points of view are:

  • Rewriting is good because the old product was well done but was written for a different time, with a different frame of mind, and with old technology. Everyone will be better off with better application.
  • Rewriting is bad because “You are wasting an outlandish amount of money writing code that already exists”…the loads of code debt or bad code can be fixed, a rewrite isn’t necessary.

These are both solid, well supported lines of argument. But I think they are addressing different situations. Jason Fried of 37Signals doesn’t talk about Basecamp being a bad application with bad code, just that it was great, but can be better. And let’s face it, if you follow the software company 37Signals you know they’re not hurting for money and can afford to do a complete rewrite.

Joel Spolsky addresses the other type of software application, the ones with problems, bad code, slow performance, etc for the large, widely distributed applications. He says all of those things can be fixed and the cost to the fixing is much, much lower than the rewrite. He’s write…err, I mean, he’s right.

What I like is the clarification by the blog post author, Garry Robinson, that the software application should be rewritten if either the database design really poor, or the code is really poor because the developer(s) didn’t know what he/she was doing, or both.

Garry is essentially saying it’s a matter of severity; if it’s really bad, rewrite. I agree. Issues can be fixed if the problems aren’t endemic throughout the code and database. But if they are, rewrite.

In fact we are facing that exact situation with a customer’s application. An application was built by an internal person years ago with Microsft Access and SQL Server. On their own those are fine tools to use for this situation, and a great custom software application can be written with them. But the way it was written was…well, it was not good (an understatement). The application is really hard to support, especially in some specific feature areas.

We are now working with the customer to do a complete rewrite. It will give them a solid application that won’t have the frequent issues it had before. The customer will also get new features and capabilities they couldn’t dream of with the old application.

How to Get QuickBooks Data in Microsoft Access

Wouldn’t it be cool to have your great Microsoft Access database application have some reports displaying data from your QuickBooks file? It is possible without much work and, in some cases, even less money.

I’ll briefly discuss a couple products you can use to work with QuickBooks data in an Access database. But keep in mind that there are many ways to do this.

One of the quickest and easiest is to use QODBC. It is a product developed by FLEXquarters.

To keep this post relatively short, I’ll leave the detailed explanations to the authors. But in short, you can create a DSN to get ODBC access to the QuickBooks data as linked tables in your Access database. Then you can query and report to your heart’s delight.

Their web site has a good introduction to what QODBC is, how to install QODBC, a couple things you have to do the first time you use it, and how to use QODBC with a Microsoft Access database.

Another good product, and in some ways a better product than QODBC, which enables you to work with QuickBooks data in an Access database is AccessBooks RealTime by Synergration.

Again, I’ll leave the details of explanation to them. But the summary of this product is that you install an application, point it to your QuickBooks file, and tell it to synchronize. It then creates an Access or SQL Server database and loads the QuickBooks data into the database. You can then work with the QuickBooks data that have been put into this new database. And you can synchronize whenever you want.

You can also take things a step further, getting your changes into QuickBooks with AccessBooks Updater.

These products aren’t free or cheap, but they’re also not really expensive. If you have a decent business need to create your own reports of QuickBooks data, or work with QuickBooks data and your own, etc, then these are good products to consider. Don’t forget there are also other products out there that allow you to integrate your custom database applications with QuickBooks. Maybe I’ll discuss those in a future post.