Development Style

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 I just finished listening to the latest audio interview on Roy Osherove’s blog between David Platt & Juval Lowy. I enjoyed this interview, and one of the highlights for me was Juval describing how intranet development should be done with smart clients not with web forms. This has been a pet peeve of mine since Microsoft started pushing .Net 1.0. A large focus of the technology drive was “every thing should be a web form” which to me missed the whole advantage of a sand boxed/managed environment that .Net/Java gave you. The idea of doing user interfaces in HTML (or what ever) and using lots of JavaScript to manage the user experience is awful. To me this represented an extension of JavaScript from what it was designed for, to the realm of “well it stretches that far.”

The coolest thing to me about Java (before .net) to me was the idea of applets. Sort of what ActiveX should have been but wasn’t. So when I heard about .Net I naturally thought of a pretty version of Java applets. Because you knew the UI widget set was going to be uniform with the user system. Anyway, one of the local companies I interview at >1 year ago, where so proud of building a .Net app for their remote users. The Engineer talked about web forms, and I sat there with him while he described writing more (and more needed) JavaScript to do the maths (scheduling of advertisements and cost modeling) on the client side to get “better performance” I just knew they didn’t get it, and I didn’t want to work there. It just seemed such a crime of developer’s time, and a really poor solution delivered to the customer.

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.