A hybrid post where I plan to wonder through different idea spaces (compared to going off on tangents while trying to keep to a single idea).
Anyway there seems to be more support in .Net 2.0 for smart clients with things like ClickOnce for deployment management etc. It just seems strange to me that anyone would do anything different. When the application has a known/controlled install base, anything other than smart/thin client based development seems like proposing a substandard experience.
The other related thing is I had an interview at the local HP office yesterday. The building looked really nice, they had plenty of parking and quite a nice view, but no pool. The ~3+ hour interview was fun. I had to implement a piece of software that was meant to be a web form (ASP.Net) but I have no experience doing web forms so they changed it to win form. The task was to build a simple customer management app. But I had two hours to get through as much of the feature list. Gosh writing a slap dash app is so against the ideas of clean application development. After patterns like MVC, frameworks for smart clients and unit testing, been asked to slap it together actually seems like the most worthless of tests. The only value I can see from the test is how much domain knowledge the interviewee has. Things like clean abstraction, commenting, unified event handling, get thrown out the window. It was more stressful than the algorithm programming on TopCoder. I think asking me to talking them through a design of what I would have done would have added more value. It would show I knew how I’d tackle the task and the fundamentals of client UI design. This would appear to be of more value than weather or not I could slap together code that followed none of those principles in a tight time frame. Especially when afterwards we discussed how so little time is spent coding, and the projects are well managed through a structured development cycle.
David and Juval at the beginning of the audio interview where discussing about how this is how software should be engineered. I agree with this. Big systems need big process. My problem is I’m not the biggest fan of big process. I’m a fan boy of prototyping stuff. Solving the “but you can’t do it” type thing. The skunk work projects. Working thought task lists that are planned out a year ahead is not me.