Done? Wow, not even close
Better User Experience??
Lately I've been hearing nothing but groans and moans every time a request to make the end user experience better is issued by the project manager. This has to do with a website we are building, and the groans from other developers working on the project. But the more I think about this the broader the term "user" becomes.
Webservice Clients/Consumers Are Users Too...Or Are They?
In an unrelated meeting about our new SOA initiative a question was raised regarding how we are to communicate errors to clients of our services. After some confusing discussions over the misunderstanded term "fault contract" and some other comments, it was suggested that we just not so gracefully communicate any and all problems through the use of this cool .NET technique called SEH, yep, the good ol' System.Exception. I kinda thought it was funny cuz I thought they were joking but they weren't.
That's fine, my issue(within the context of this post) isn't with how to communicate errors to webservice clients. My issue is that the question was a broad one. How do "we" communicate errors. The "we" in the previous statement are 13 groups(not really groups but it simplifies the actual players here). The "we" in the discussion about how to send errors back to clients are the handful of developers I work with, and that "we" makes up only one of the 13 groups. The other 13 groups are a mish/mash of java/.net/whatever shops, and they will be consuming our services and we theirs, hence SOA bliss! Yay!
How do the other groups send back errors? They all have different mechanisms, some send back malformed xml, some with an error node, some with a non-xml string error, whatever. One dev spoke up, clearly tired of trying to figure out a good way of communicating with others, said, and this is paraphrased: look, if they use our web service incorrectly, they're going to get garbage back and they'll have to figure out what they are doing wrong, after a couple of times they'll figure it out and they'll stop using the service incorrectly....
It's About the Attitude
The attitude behind the comment is what bugs me. Basically it was saying f*ck the user of our webservice.
So why are we developers? I can only speak for myself, but it's to make better software. What does that mean? That means the end user experience is better than it was before I did what I do, and on some rare occasions, even exceeds the expectations of end users. I continue to write some software that I'm not terribly proud of. Undocumented, convoluted, untested, I'm not perfect, I write my share of documentation and good tested software as well.
Every day I get up, I'm motivated by the potential to make things better. If it's about building a web interface, then I want to at least shoot for a good user experience even a great one if I have time. If it's software to be consumed by other developers, I try to make it's use and configuration simple. Object Reference Not Set To An Instance Of An Object is unacceptable for me. Sometimes it's hard to figure out which object was null. How about checking the args of whatever method that barfed for anything that's null and throw an ArgumentNullException specifying which arg was null?
Anyway, the point is that no matter where you are in the software stack, you want a good user experience.
Dog Fooding
I've almost got enough done with HyperActive that I'll be able to post the code. In the meantime, some devs I work with are initial testers for the code. In a nutshell, HyperActive generates Castle ActiveRecord classes from an existing database schema, in a very similar fashion to SubSonic/SubCommander. It has a build provider interface, web interface, and a command line interface, and there's a winform ui I'm conceptualizing right now. Anywho, I needed some ActiveRecord classes for a project and decided that I'd use my own HyperActive console app to gen the classes. Added it to my external tools list in visual studio, fired it up and voila! It did nothing I needed it to do. It stuck all of the generated classes in the wrong spot, had the wrong namespaces, no primary keys were generated, the experience sucked. So I fixed it. I want the user experience of that code to be at least as good as my experience has been with SubCommander.
Users Users Users
It's all about the user. A dev I work with used my generated code and told me he doesn't do foreign keys in Castle ActiveRecord classes the same way I do. I was on my way down the road to figuring out why he was doing foreign keys the way he was when it hit me like a ton of bricks. The entire reason I'm building HyperActive is to empower developers(read end users) to develop the way they develop, not the way I develop. Since I put quite a bit of effort into making HyperActive extensible, it was easy to come up with a simple way for the other dev to get what he needed and in turn I ended up with a better piece of software.