Have I overextended myself with this project?

Question

I'm currently rewriting our company's database app, which is an Access-VBA frontend for a SQL Server (Express) backend.

I've been managing the application for 4 years or so now and when I started here it was a single *.MDB-file on a network share (which got corrupt on a weekly basis).

Since then I changed the DB to a multi-user *.MDE, later I migrated the data to a SQL Express Server as an *.ADE.

Since then the application runs smoothly and is very reliable.

But, of course there are some drawbacks using Access (no source control, dependent on Office version, etc etc), So I suggested to my boss to rewrite the frontend in C# & WPF.

I did a bit of Java and C++ a few years ago, but thats it. Now I've been working on this project for 3 months or so and the going is very tough. Just for such simple tasks as filling a combobox I have to search the net and read a lot of stuff.

I really want to learn C# (and also have learned a lot of stuff since I started!) and I find this a great opportunity, but maybe I have overextended myself, starting with a real LOB application as a single, junior developer?

Answer 1

Picking a technology for a project because you want to learn it is always a risk. I'd also concerned about WPF. For one, it's not a proven technology (in the same sense that Winforms is). It's still rather new. The second is that it puts potentially problematic limits on what systems it can run on. Vista/Win7 or I think XP SP3. That may or may not be an issue.

The good rule of thumb is that you should ship early and ship often. Break off a piece of functionality and deliver that. For a time you may have the users using both apps for different tasks. You're far better off doing that than trying to swallow the whole thing in one go.

Also, and I think you're discovering this, complete rewrites are nearly always a mistake. It's a lot of work for not much gain, you're giving yourself a lot of opportunities to introduce bugs in things that already work and you lose a lot of domain knowledge (and working code).

Answer 2

I almost always agree with cletus but im gonna play both sides and say where does one draw the line? do you keep maintaining that project that got handed to you from late 1903? When should one bite the bullet and rewrite the system? I think when given an project as disjointed as what you are describing, you should fragment the system into features, milestones that you what to achieve and test test test, tests that validates the feature you are rewriting.

Answer 3

Obviously I don't know you, but I think you should be able to handle it. On an abstract level, you can keep a lot from the old application (like: general layout, which forms do what, etc.) which makes it much easier not to get completely lost in a ever-growing forest. You can also use that to judge your progress: How many forms (procedures etc.) does the old application consist of, how many of those are already rewritten?

Sure, you have problems with the details in the beginning (like the mentioned combo-boxes) but once you overcome that and get some routine (and some source files to copy-paste from), it won't be harder for you than for anybody else.

Answer 4

ship early and ship often.

I agree with cletus () on this. "Ship It!" is a quick read with some good advice on this subject.

The big risk with working on a rewrite is that you spend a lot of time on it and then the project either gets canceled before it's anywhere close to finished, or shipped with 100% of the functionality in a 50%-working state. If your rewrite is in the hands of some users then the project is less likely to be canceled, and the users will drive the functionality that they need next. It may turn out that the old application has a lot of functionality that isn't used much, so that you can get most of the value into the hands of the users in much less time than it takes to do a full rewrite.

Once your code is in production you will feel happier and be even better motivated, and this will help you to work faster.

Just for such simple tasks as filling a combobox I have to search the net and read a lot of stuff.

Are you dissatisfied with your rate of progress (or "velocity" in Agile-speak)?

Obviously if you could produce more every day then the task might seem less overwhelming. There is a big difference in productivity between the best programmers and the average (see Peopleware or the Mythical Man Month), so anything you can do to make yourself a better programmer could make a significant difference.

In your case I wonder if some training would help? I'm not usually a big fan of classroom training, but if you don't have many experienced people around you to learn from, this would give you a jump start. If training isn't an option, do you have a local C# user group? If there are more experienced developers in your company, could you go to them for advice? Or just pick their brains at the water-cooler?

One big problem with working on your own is that sometimes you get stuck on something very simple, that somebody else would spot straight away. Sometimes just explaining a problem to someone else helps you look at it in a way that helps you to solve it. If you could work with someone else for even a short time every day, this might help your productivity.

Do you have (and use) all of the tools you need? The absolute minimum is: a. A version control system. b. A bug tracking database. c. A good development environment e.g. Visual Studio d. A better development environment than Visual Studio! e.g. Resharper.

See link text for a better list.

Good luck!

Answer 5

I would say chuck whatever you've done in C# and go back to your Access app.

You're building a database front end to a SQL Server back end. Access is perfect for that -- that's its entire reason for existing.

For source control, there's Visual SourceSafe (though I don't quite understand why you'd need it for a one-person project). In regard to Office version dependence, that's not so much of a problem any more since Access 2000, though ADPs are very version dependent in that they don't behave the same in all versions of Access. And for that matter, MS has been deprecating ADPs for the last several years in favor of MDB/MDE front end linked to SQL Server via ODBC.

I think you've thrown the baby out with the bathwater and should go back to Access for your front end. Do you want a working app? Or do you want to say you're a C# developer?

Can you quantify the actual return on investment for rewriting the front end? If so, I think you'll find that staying with Access is going to be a vastly better value than a wholesale rewrite.

Answer 6

If you want to learn a major new technology you are not advised to start with a major rewrite of a mission critical system. That is almost a stereotypical mistake — the kind of thing that ends up getting 250 votes here on Stackoverflow under a question like "What's the biggest mistake you ever saw in upgrading a business application?"

You would be better advised to do your own project in .NET first, even a small one. For instance, to get my feet wet with jQuery, I recently wrote the game of Memory (where you flip over two tiles at a time looking for matching pictures). You could do something like that, or a simple checkbook program.

If you absolutely must do actual business work on your company's main application as a learning project, select a small and discrete (separate from the rest of the application) unit of work and do that as a test project. It should not disrupt the existing application, just add a stand-alone piece of functionality. Based on that experiment you and your boss can decide whether it's worth going forward with the next, slightly larger, unit of work.

Answer 7

You can use SourceSafe with MS Access, it integrates quite nicely. I would recommend this whether or not this is a one person project, it's saved my bacon a couple of times...

I'm not sure that WPF would be a suitable choice for a first app, it's steep learning curve and the benefits for a line-of-business app are far from compelling in my opinion. C# or VB.Net with data-binding can be powerful and quick to build but it's not clear to me what that would offer over and above your current app which is already 'very reliable'. The use of SQL Server as a back-end removes many of the objections (performance, scalability etc) raised about the use of Access for a business critical application, indeed we have Access front-ends to SQL server databases with hundreds of simultaneous users which work fine.

I'd save the .Net for the next app.....