Hi again. Today was another good day at the conference.
User Experience Distilled
The first class I attended was a whirlwind tour of user experience. I was heartened to learn that I am not alone or crazy in recognizing that there are a number of disciplines that go into this thing we call UX, and the presenter, Jeff Patton, also recognizes that actually virtually every role in developing software has an effect on UX, which is also something I have come to the conclusion of (as I hint at on IG's UX area). I develop the idea more explicitly in an unpublished paper I'm working on. (I'm hoping the inputs I get from this conference will help me to finish that out.)
I actually think that all of this UX stuff falls under the architect's purview because (in my mind at least) he or she is primarily responsible for designing the software as a whole. This means that architects need to have a conversational familiarity (at least) with the different disciplines that people traditionally think of as user-oriented disciplines, but I'd take it a step further and say that the architect needs to be the chief experience officer, as it were, on a software project. The architect needs to ensure that the appropriate expertise in user-oriented disciplines is brought to bear on his or her project and also needs to understand how the other aspects of software design and development impact UX and optimize them for good UX.
That discussion aside, Jeff had a pretty clever graph that showed how the kind of software being developed affects the perceived ROI of expenditure on UX. His talk also was about as effective an introduction to UX that I can imagine. He dealt with what it is, why it's important, and then offered a high-level overview of key bits of knowledge for people to make use of. I want to steal his slides! :)
Global Teams & Outsourcing Agilely
The keynote during lunch today was done by Scott Ambler. It was nice to finally see/hear him in person since I've heard so much about him. I got the feeling (from what he even admitted) that he was presenting stuff that wasn't just his--he was from what I could tell presenting an overview of a book that IBM publishes (related) on the subject. But that didn't take away from the value of the knowledge by any means. I'd definitely check it out if you're going to be dealing with geographically distributed teams.
Usability Peer Reviews
In my continuing quest to learn more about UX (part of which is usability), I attended a class by Larry Constantine about lightweight usability practice through peer review/inspection (related paper). I was actually surprised because he has a very formal methodology for this, which means he's put a lot of thought into it but, more importantly, he's used it a lot in consulting, so it is tested. I personally am not a big fan of being too formal with these things. I understand the value in formalizing guidance into repeatable methodology, but I've always felt that these things should be learned for their principles and less for their strictures. Of course, that runs the risk of missing something important, but I guess that's a trade off. Regardless of if you follow it to a T or not, there's a ton of good stuff to be learned from this technique on how to plug in usability QA into the software process.
Applying Perspectives to Software Views
After that, I slipped over to another Rebecca Wirfs-Brock presentation on applying perspectives to software views in architecture. (She was presenting the subject of this book.) To me, the key takeaway was that we should figure out the most important aspects of our system and focus on those. It echoed (in my mind) core sentiments of domain-driven design, though it used different terminology and approach. I think the two are complementary--using the view approach helps you to think about the different non-functional aspects. Using strategic DDD (in particular, distilling the domain) helps you and stakeholders to focus in on the most important aspects of the system from a domain strategy perspective, and that will inform which views and perspectives are the ones that need the focus.
This approach also echoes the sentiment expressed by Evans yesterday that says you can't make every part of the system well-designed (elegant/close to perfection). Once you accept that, you can then use these approaches to find the parts of the systems where you need to focus most of your energies. I really like that this practical truth is being made explicit because I think it can help to overcome a lot of the problems that crop up in software development that have to do with the general idealistic nature that we geeks have.
After the classes today, they had the expo open. In terms of professional presentation, it was on par with TechEd's Expo, but certainly the scope (number of sponsors) was far smaller. That said, I popped into the embedded systems expo. That was a new experience for me. It was interesting to see almost every booth with some kind of exposed hardware on display. As a software guy, I tend to take all that stuff for granted. They even had a booth with specialized networked sensors for tanks of liquid. This stuff stirred recollections of weird science and all the other fun fantasies that geeky kids have about building computerized machines. The coolest thing there was the Intel chopper, which apparently was built by the Orange County Chopper guys, but it had a lot of fancy embedded system stuff on it. I didn't stick around to hear the spiel, but it was pretty cool.
After the expo, I bumped into a guy at Cheesecake factory. We started chatting, and it turns out that he's in the process of becoming a Roman Catholic deacon. Pretty cool coincidence for me! We talked about two of my top passions--my faith and software development (as exemplified here on dotNetTemplar!). It was a good dinner. He works at a company that does computer aided engineering; sounds like neat stuff with all that 3D modeling and virtual physics. Way out of my league!
As I said, another good day here at SD Best Practices.
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.
Thanks to the good folks at dasBlog!
Copyright © 2017 J. Ambrose Little