# Thursday, September 03, 2009
« Tip of the Day: Getting Table Counts | Main | Tip of the Day: A brief explanation of e... »

Next week, I’ll be starting a new project, which is always exciting for me. In this case, it will be a WinForms application, which I really enjoy working on.  Since everything is more web-oriented these days, there just aren’t as many WinForms projects. In fact, I haven’t done one in about two years where I built an application for a major phone system manufacturer which takes Oracle data/Excel spreadsheets, imports the data and generates a PDF price list.

I know a lot of people dread deployment of WinForm apps, which is one of many reasons web development has taken off. From my perspective, it’s an even trade because web development has many challenges.. scalability, security, browser compatibility, etc. Mostly, since WinForm apps are so rare these days, it’s going to be a fun contract to do something different for a change.

But that’s not the point of this post. I was thinking about how I approach a new project (in this case, it’s a re-write of an older application) and what I do to get it started.

In this case, it will look something like this:

·         Get oriented (passwords, system information, high-level project overview)

·         Get the environment set up

·         Get a high level view of what the project entails

From there, it’s time to dig in. In this case it’s a re-write, so one of the many questions I ask will be to find out what was lacking or has changed since the first application, and what the new desired features are. Ultimately, this may entail a semi-working prototype. I’ll also want to familiarize myself with how the old application works. This is important, as most people don’t like a lot of change unless it really improves the process, so it’s good to understand how they currently use it, and how they want to use it. You need end user buy-in to be successful, so it’s important that any change you make will be accepted.

So now we get to designing and ultimately coding. It usually involves a few things:

·         Architecting the application

·         Data Mining/design

·         Designing tests

·         Deployment Strategy

·         Post-deployment support

·         Documentation

To architect the application, I need to see if there are any existing architectures in place. Very rarely am I given free reign to build the data access layer, but it does happen. A lot of contractors really push this, or ignore current architectures, but that’s a mistake. I say this because you need to leave an application which your client can support. If I do change the existing practices in place, I make sure I know WHY, communicate it and document it.

Now come the tools. Some clients won’t allow you to bring your own software licenses. In that case, I may have to do a CodeSmith demo to help justify the purchase of the tool. I’ll look for opportunities to generate code and speed up development. I have had a LOT of push back on that from other contractors though, in that they feel you are losing billable time by generating all that code, but I disagree.  First, as a consultant, I feel I have a duty to save my client money and time where I can. Second, when you do quality work and it’s fast, I assure you that you’ll be either getting more projects or called back. In my 13 years of consulting,  almost every client I have has brought me back for subsequent projects for that exact reason.

I also bring things like my data mining queries in my other blog posts which help find what I need to find quickly. 

What tools/techniques do you use?