The lack of ownership bothers me, because what happens with those projects now? I would sure like to know! I spent long hours and some late nights on them, sometimes I was the only one working on them. Unfortunately I can’t see what happens now because those unfinished programs belong to my customers.

So (now that I am between unfinished projects) I have started working on some projects of my own. This has led me to learn some new things about myself. Working from home on my own projects requires so much discipline it is almost like learning a new job. I do allow myself opportunities to work on home projects, but I have to be really careful not to let things get out of hand. I don’t want to end up with more unfinished projects!

I’ve also been setting goals for myself as a new company. I’m hoping to start earning revenue through other streams besides just consulting. This is a daunting shift for me, especially because I’m not earning revenue while I’m developing right now. Hopefully some projects will start earning recurring money soon though. That means I have to set priorities.

I’m also giving myself some time every morning to evaluate or re-evaluate my goals and to setup tasks to achieve those goals. This is a little different from what I do while consulting for clients, when I would simply set tasks for the day or week in order to get the project done. Now I am taking an even bigger picture look at the future of my career and the future of my company. I’ve still got a lot to look at, work on, and learn – but it is exciting.

I’m also hoping that the next contracts I will work on will be for longer-term contracts. The last few were under six months, I’m hoping to find work on 9 month+, multi-developer contracts from now on so that I will not only have time to finish them but also work on some larger teams and take more of a leadership role rather than be the sole developer.

I’m also going to keep in mind that not every change is permanent! I’ll be evaluating what I’m working on daily to see what is working and what isn’t. It’s a sort-of “agile” way for me to treat my business, career and life! I’m excited and looking forward to the future.

Oh, and one more goal is to blog at least twice a week. I’ve made that promise to myself before, but this time I’m giving myself time to do it instead of trying to find time to do it in.

This project was a pretty good one.  Even though we put the application into production, the customer didn’t have enough money to keep me on long enough to finish the project in a state I would have been more happier with.  There were a few reasons for this I think: 1) the customer did not have a clear enough spec, in his mind, before I started, 2) the customer was too busy with other projects to give me enough attention and direction with the design, 3) the customer was too busy to help me get the application into a User Acceptance test site earlier than two days before the contract expired.  If we had a little more time, maybe one more month I think we could have turned the application into something excellent, and I could have seen it in use long enough to know if my design assumptions were good ones.

That said, I did spend a lot of time with one of the Users who was a database modelling expert.  I did learn a lot from him, and he really helped me understand more about what they were expecting as a customer.  Unfortunately he worked in another building, so access to him was severely limited too.

Another success was that this was my first ASP.NET MVC project to be deployed.  It was also my first use of NHibernate, which I also thought was very successful.  I also used jQuery and jQuery UI extensively for Web 2.0 stuff like dialogs (death to window.open!) and AJAX.  Those things were a lot of fun.

I also got to use a of new architectural planning and design (Domain Driven Design) pattern that I learned from a talk given by Donald Belcham (aka The Igloo Coder).  I’ve been reading the book by Eric Evans as well.  This definitely seems like the new way to go.  DDD is about modelling your application and also about understanding the client’s needs.  I’m really impressed and eager to use it in future projects and products as well.

I was using some cool features of jQuery to do AJAX instead of using UpdatePanels, but when The Intern wanted to do some AJAX he got totally lost. In the end I taught him to use both jQuery and (despite how dangerous it is), Ihow to use UpdatePanels.  In the end I encouraged him to use the UpdatePanel with his pages, read on to find out why.

1.  Updating the DOM using jQuery and Web Services is an Advanced Skill

Oh yes, both you and I can look at the code and figure out exactly what is happening.  We see the JS file linked in the ScriptManagerProxy control, we can follow the JavaScript code to the webservice call, and even more, but it is a very advanced skill.

2.  Updating the DOM using jQuery and Web Services Reduced Maintainability

Even with all of my knowledge, it’s still a long, messy trail of code until you get to the end (the web service). You’re crossing several files, including C#, ASPX, JavaScript, and ASMX files.  In my opinion this drastically decreases maintainability and makes the code much less readable and obvious to other .NET developers, even those who have read Encosia’s article.

3.  Using UpdatePanels Doesn’t Change the ASP.NET PostBack Model

The UpdatePanel is just another ASP.NET tag.  The PostBack model is retained, you still have Button OnClick events, you still have TextBox.Text, Page_Load etc. All of the code is still retained within one ASPX/ASPX.CS file pair. Almost any .NET developer, no matter how junior, should be able to follow this code. That makes the code maintainable.

In the end, even though jQuery will be shipping with future versions of ASP.NET, the .NET Framework, and Visual Studio, it’s still a relatively new concept. We need to proceed with it, but this is new ground so we have to blaze a trail that the slower movings guys can follow.

One of the big benefits we have as .NET developers is the MSDN Library. I like to use MSDN as a scale for maintainability. If it is in MSDN then I consider it general knowledge that a new developer should know or be able to find easily. Otherwise I have to document it really well so that at least a mid-level developer should be able to figure out my application.

We have to be careful that the people maintaining the code behind us know what we’ve done, otherwise our awesome code gets rewritten by newb developers who can’t figure it out. If we can write maintainable code then hopefully the developers behind us will learn something and eventually become more advanced in their skills too.

I’ll be spending the summer looking for work, working on stuff around the house and on personal programming projects under Hoffsoft Consulting Services Corporation.