In October of 2007 I started work on a project to convert and extend an older True BASIC data processing program. Early this year, after releasing several versions, work on this project ended and I thought it would be interesting to share some thoughts and experiences. I do not consider myself a ‘master programmer’ and these notes are not intended as ‘expert guidance’ – so why post them? Because I have enjoyed similar posts from other programmers!
Overview:
Platform: The requested target for the project was a Windows desktop application. Windows desktop applications do not get much love/hype these days and at various times during the project we talked about doing a web version. But with no existing server/host to use and without manpower/budget to acquire and maintain a server/host a desktop application was a good choice. Application installation and updates can be a challenging part of a desktop application – but in this case we only ran into a few support issues and it was really not a problem.
Programming Language/Platform: C#/.NET (eventually 3.5)/Visual Studio (eventually 2010). Since Windows desktop was the target and we had existing experience with this stack we did not seriously consider other choices…
Gui: We started the project in WinForms and later moved to WPF. The WinForms version worked fine, but I find WinForms hard to love – in particular I dislike the GUI designer and generated code. It was refreshing to move to WPF, working with XAML for the UI is quite nice and I have found WPF to be a quicker, easier and more maintainable way to create UI (I have used WPF for several other projects as well). I would hesitate to start a new project in WinForms – but I have started to strongly suspect that UI technology/framework matters less than I would have guessed several years ago. My personal experience has been that many technologies have reasonable basic functionality – you are going to be able to get a decent/basic UI built without too much time/pain. But it seems like that in every technology it is going to cost quite a bit of time to tweak/create/craft all of the details needed to make the UI something you would actually want to use (UI hints to help users solve their problems, help for beginners, understandable error messages, good editing, great validation, smart interaction with the database, attractive visuals, great layout, etc…). WPF seems like a step forward compared to WinForms – but not a big enough step forward to make creating good UI easy or to make achieving your vision uncomplicated… I would pick WPF over WinForms for a new project – but certainly not with the illusion that a great UI can be created quickly in any technology.
Data: We used Microsoft SQL Server Express for this project (2005 and 2008 versions). For this project a carefully constructed schema helped us to enforce rules about the data, catch errors and query the data much more easily than a non-relational store would have. We did 95% of our data processing with SQL queries – for this project that turned out to be a very pleasant way to work.
Version Control System: We started this project in 2007 and used Subversion and Trac at hosted-projects.com. While I currently do not have much love for Subversion I did realize after switching to Mercurial that it is easier to explain, understand and use for simple scenarios – a great benefit in some situations. About two years into the project we moved to Mercurial and Assembla. Mercurial is fantastic – my experience has been that Mercurial has quite a few benefits (easier check-ins, faster access to history, nicer branch/merge, quick cloning of the entire repository for experiments) without any additional hassles once you get over the initial learning curve. We stayed with Mercurial for the rest of the project but did move from Assembla to Fogbugz and Kiln. Moving to FogBugz was nice – we found that the default FogBugz setup worked better for us than a default Trac setup (we were not interested in spending time customizing Trac). Moving to Kiln was FANTASTIC – I love the features that Kiln provides for working with Mercurial repositories. The ability to maintain and organize multiple repositories made it much easier to work simultaneously on different releases and features. We took advantage of the 2-person Student/Start-up (free) plan. I really like FogBugz and Kiln, but I do wish they had some additional pricing options – while these services are certainly ‘worth’ $30 per person per month that could be tough to justify for smaller/experimental/less profitable endeavors with more than two developers.
Details:
LINQ to SQL – For a simple strongly typed data access this was great! Creating the data layer via SqlMetal on the command line was a nice part of our workflow. But I am very glad that we did not try to do all of our data processing via LINQ – when we experimented with trying to do everything in LINQ we quickly found that complex queries were more readable, easier to create and faster to change done directly in SQL. While LINQ to SQL is still supported by Microsoft I think it is fair to say all their energy is going into the ADO.NET Entity Framework and I don’t think I would choose LINQ to SQL for a new project.
SQL Server Compact – As noted above we ended up going with SQL Server Express – but our original intention was to use SQL Server Compact edition as the primary database and include an option for advanced users to use an existing SQL Server instance. Unfortunately my ignorance killed the SQL Server Compact part of our plans – I was developed for months via Sql Server and had written hundreds of lines of SQL before I realized that some of the syntax that I had used was not available in SQL Server Compact edition. At that point we felt it would have taken too much time to rewrite the SQL and we went forward with just SQL Server Express. This was a learning experience for me about the differences in SQL databases…
Importing Data – We, of course, ran into problems with users supplying invalid data – but I think that is always true of user input. The more interesting problem we ran into was that we underestimated the user’s ability to understand and fix the problems in their data. For the second version we added a validation layer that gave us a chance to both catch errors in the data AND give the user detailed/helpful error messages – it was certainly not perfect but it helped quite a bit to have detailed user targeted error messages.
Conclusion:
Like any project if I was going to do this again I could do a better job – but we managed to produce a working application that we were able to maintain and constantly improve for several years! I think most of our choices were reasonable given the goals and resources – but certainly database and desktop application would be two things that I would consider carefully if were starting again from the beginning.
CM
