Series on Programming Practices

Brian Harry

This is the first post in a series I’ve decided to write on my Programming Practices.  I’m not trying to say everyone has to do it the way I do it but I figured it might be interesting to talk about how I do it and have some fun, if sometimes controversial, discussions about it. A little before Christmas, when I decided that I really wanted to understand the Beta 2 performance issues first hand, I picked up a programming project that I’d been kicking around and started to get serious about it.  My job doesn’t really afford me the opportunity to spend a lot of time writing code any more but I’ve gone out of my way to really set aside some time to do it.  Over the past few months, I’ve probably averaged 10-20 hours a week of dedicated coding time. As I was coding I decided to watch myself closely and try to observe what practices I naturally follow with the goal of eventually sharing them more broadly.  I’ve generally always been very proud of the productivity, organization, performance and quality of my coding.  Once you see it, you can decide for yourself whether you like it, dislike it or just think it’s stupid 🙂  I’m sure the practices don’t apply to everyone or every application type.  I have always done commercial software and much of it at a fairly low level “systems” level.  I’m not sure how much of what I’m going to describe will apply to someone who is primarily a jscript/html coder.  You can judge for yourself. The project I picked up is a new version of TFSServerManager.  It’s particularly interesting because it has many components.  It has a client GUI, written in WinForms (I’ve played with WPF but I can’t say I’m proficient at it enough to feel particularly competent – once I finish this project, I think I’m going to try a full WPF/Silverlight app).  It also has a web service that runs on the TFS server and augments TFS with a few capabilities that aren’t available “out of the box” – doing some SQL access.  There’s some ASPX pages for lightweight user interaction for a few things (more on that later).  And lastly there’s a command line installation utility.  A fairly diverse technology set in all. I also took this project as an opportunity to explore asynchronous rich client programming a bit more.  It pains me that the TFS client makes so many web service calls on the UI thread causing the IDE to “pause” if the server is ever slow to respond.  It ended up this way because we didn’t lay out a great pattern for all of the developers to follow up front and stuff just kind of unfolded the way it did because it’s easier to put all the logic on the UI thread than it is to partition it.  So as part of this project I set out to have every single server call occur on a background thread and create an architecture that would make it easy to do.  My goal is to make it no harder to program this way than putting all the logic on the UI thread.  That goal is a bit harder to achieve with WinForms because it does not lend itself to good presentation/computation separation (e.g. MVC – Model View Controller or one of the variants).  When I start my WFP project, I’m going to adjust the pattern for MVC and I think it will get even better.  Anyway, through the course of this series, I’ll share with you the architecture I created. I won’t be surprised if it takes me weeks, or even months, to get through the whole series.  I’ve got a lot of thoughts and I think it’s going to be a pretty big investment for me to make them all intelligible 🙂 I hope you find it useful,

Brian

0 comments

Discussion is closed.

Feedback usabilla icon