tags:

views:

333

answers:

7

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?

+10  A: 

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).

cletus
On the one hand, yes WPF is unproven. On the other hand VS 2010 is built with it and highly impressive....
RCIX
The utility of WPF for vanilla data pushing applications is a moot point too.
Benjol
VS2010 reactions are mixed: http://blogs.ijw.co.nz/chris/index.php/2009/07/visual-studio-2010-10-is-the-new-6-but-not-the-way-they-wanted/
cletus
"complete rewrites are nearly always a mistake" - according to a talk given by Greg Wilson "If more than 20-25% of a component has to be revised, it's better to rewrite it from scratch." http://www.slideshare.net/gvwilson/bits-of-evidence-2338367
Jonas Elfström
Î have of course read Joel's opinion on rewriting code (and I can follow that argumentation). The point is: once I decided to use a "real" programming language like C#, its nearly impossible to reuse the code from VBA and I definitely wan't to get rid of MS Access.
MAD9
@cletus: Why do i have the immpression he was running it on an oudated machine? It worked great for me in B1 and even better in B2. The only time WPF will perform bad (barring some bizarre bug) is if the system isn't equipped to handle it, much as is the case for a lot of games. The decision to use WPF came down to this: "Most average programmers have a decent graphics card nowadays, so why not use it?" (not the exact words of Rico Mariani, the main architect for VS 2010 i think). I agree, it's a controversial decision, but so was Aero and most people like it now.
RCIX
The requirement is WPF requires XP SP2, vista or Win7. There are still businesses operating at older OSes than that. Win2k is a prime example.
cletus
We only have 6 clientcomputers which all run XP SP>=2, so thats not a problem here.
MAD9
+1  A: 

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.

almog.ori
"..the application runs smoothly and is very reliable." Dealing with source control and Office versions are trivial to a rewrite.
Jeff O
My point was to break the overwhelming task into smaller bite sized chunks and validate your assumptions with tests, it frees you to change something over there when you know that it still works over here.
almog.ori
+1  A: 

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.

ammoQ
+2  A: 

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!

richj
I use a version control system (VisualSVN + TortoiseSVN), but I have no Bug tracking DB (can you recommend a free one?) and I'm currently using C# Express. If I deliver a really nice product, I might get a better IDE, like Visual Studio (Standard should be enough I guess?)
MAD9
There is a good comparison of bug and issue tracking systems here: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systemsJIRA, Bugzilla and Trac are all open source, widely used, and have Subversion integration. I can't recommend one of these myself because I use FogBugz 6. FogBugz isn't free, but it is excellent and there's a hosted Student and Startup edition that is free for teams of one or two people. You don't have to be a student or a startup to use it, the terms are here: http://www.fogcreek.com/FogBugz/StudentAndStartup.html
richj
Resharper adds many extra productivity features to Visual Studio 2008: http://www.jetbrains.com/resharper/features/ComparisonMatrix_R4.htmlIt is an add-on for Visual Studio 2005/2008. Express edition isn't supported, but it looks like Standard edition is.Even if your company doesn't have a large budget for software tools, this one is worth considering because it will pay for itself in time and productivity very quickly.
richj
+4  A: 

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.

David-W-Fenton
this might not be the answer you wanted to hear, but I think David gave the perfect answer. Access front end connected to SQL Server, with SourceSafe for version control is the setup at my work (though not what I work on directly). Is there a solid business case for taking what you already have, and giving back essentially that (but with New Technology Compliance(TM) )?
Steven Adams
Thats really not what I wanted to hear, right =) But I forgot to mention one thing: I'm working here as a part time job while I'm visiting college (Information Technology). My boss knows, that I don't know much about C# yet and that this whole project means, first and foremost, a lot of learning for me. I asked the question more from a personal point of view, than from a business and ROI point of view. (I of course don't get paid for reading stackoverflow all day)
MAD9
Seems to me that there's a major cost to the end users and whoever is doing your testing. How long would you have to run in parallel to verify that your new app replicates the functionality of the old? There are huge costs beyond your own time, especially if you make mistakes (and you *will* make mistakes -- even very programmers with very long experience with a development platform make plenty of mistakes).
David-W-Fenton
The more I think about it, the more I think I'll dump this project ... First I'll do, is check out Access of the latest Office Versions. Maybe some drawbacks of the version we still use (2000) have been resolved. Maybe I keep working on the C# thing in my spare time. Thanks for ur feedback!
MAD9
A2003 is vastly superior to A2000. And it doesn't require massive patching to get it to a reliable version. I'm not sold on A2007. The UI is so completely different that I'm still struggling with it (I only recently started working with it), and I don't want to be giving that to my users.
David-W-Fenton
+2  A: 

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.

Larry Lustig
+1  A: 

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.....

Simon