Today I stumbled into Barnes & Noble (because it had the nearest Starbucks), wandered into the notebook section, and was reminded that my current Moleskine notebook was almost full. Silly me, I still have two back at the office, so I thought it must be fate for me to go ahead and restock while I'm here. I highly recommend Moleskine; I like the small, book-like ones without lines because small is convenient enough to put in pocket and I don't like to conform to lines or have even the suggestion that I should, but they have all kinds. Good, tough little notebooks, and supposedly they've been used by some famous people. This has not been a paid advertisement for Moleskine. Now we return you to your regular program.
Applying Perspectives to Software Views (Cont'd)
Yesterday I talked about Rebecca Wirfs-Brock's session on software views. There's a lot more to what she said than what I communicated, but I'm just propounding what stuck with me. Looking at my notes, I forgot to mention another key thing, which is that you should model these views and model them in a way that effectively communicates to the stakeholders that their needs are being addressed. She threw up some UML diagrams, commenting that they're probably not good for most business folks. (I think UML is not good for most technical folks either, but I'm a rebel like that.) The point she made, though, was regardless of what notation you use, provide a key that let's people know how to unlock the meaning of the model. Good point for sure.
Actually, this reminds me of Beautiful Evidence, by Edward Tufte. I recommend Tufte for his area of expertise, though I'd suggest skipping the chapter on Powerpoint (which sadly was released as a separate booklet) because it's not his area of expertise and it shows. Anyways, when he is sticking to the realm of visual communication, he is excellent, and Beautiful Evidence is a pretty easy read that helps you start thinking about how to communicate "outside the box" as it were. I bring it up here because applying his ideas in the area of modeling software, particularly to non-technical audiences, is something we should explore.
Now, back to Day III.
The first session I made it to kind of late (and it was absolutely packed--standing room only) was a session on tips for being a good technical/software manager. Having become one of these this year, it is definitely a subject of interest, and I'm always on the lookout for more tips, though I must say that I think management books (as a rule) are really bad about regurgitating each other. You get to where it becomes increasingly hard to find new, good insights the more you read them.
But I thought this session would be good since it is specifically focused on managing technical teams. Some of her points were standard managerial stuff, but it was nice to have it focused in on the IT industry. I always end up feeling a bit guilty, though, because I know I've already made numerous faux pas (not sure how to pluralize that). I hope my guys know I love them even though I screw up being a good manager at times. :)
One recurring theme I keep coming across is having regular 1-1s with your peeps. I've heard weekly and bi-weekly, but it seems like both of those would be overkill for my group since we have daily meetings, often go out to lunch, etc., so I'm going to try monthly first. It'll be better than nothing!
I have to say that managing well is at lot harder than I expected it to be. For those of us who aren't natural people persons, it is definitely an effort. I'm sure it is tough regardless, but I gotta think that it'd be easier if I was naturally more a people person. Anyways, I keep tryin' for now at least.
Designing for User Success
Went to another Larry Constantine session around UX. This one was really good. He, like Patton, affirmed that "user experience is about everything." Again, it's nice to know I'm not crazy, and it takes a burden off me knowing that I won't be a lone voice crying out about that. It seems that maybe just those who don't know anything about UX think it is "just another term for UI." Of course, these "UX professionals" are naturally focused in on their areas of expertise (usability, information architecture, human factors, human-computer interaction, visual design, interaction design, etc.), so maybe I'm still a bit odd in my contention that architects must be the chief experience officers on their projects.
Anyhoo, this session focused in on "user performance" as a distinct focus, meaning that you are providing the tools to get the best performance out of people. Though none of the session was spent explicitly justifying the importance of a focus on UX, implicitly the whole session was an illustration of why it is important. I have a ton of good notes from this session, but I won't bore you with them (you can probably get most of it from his slides or other presentations he's done). If you get nothing else, though, it's to change the way you think about designing software--design from the outside in. If you're a smart person, you'll realize this has huge implications. And also, recognize that you won't make all parts of your system perfectly usable, so prioritize your usability efforts based first on frequency of use and second on severity of impact (i.e., those things that will have serious ramifications if not done correctly).
Human Factors in API Design
The next session I hit was one related to UX for developers. Here are some salient one-liners:
- Consistency is next to godliness.
- API = Application Programmer Interface
- When in doubt, leave it out. <-- More specifically, unless you have at least two, real use cases, don't stick it in your API.
- Use the Iceberg Principle. <-- This means what people see of your code should only be the tip of the iceberg--keep it small, simple, and focused.
This session actually seemed to be a blend of general UX guidelines (yes, they apply here, too, not just on end-user interfaces) and more general framework design principles that only had varying degrees of pertinence to ease of use. Some highlights:
- Default all members to private; only raise visibility with justification.
- Prefer constructors to factory/builder pattern, and setup object fully with constructor where possible.
- Use domain-specific vocabulary.
- Prefer classes to interfaces. Amen!
- Prefer finality (sealing) to inheritance--minimize potential for overriding.
There's a good deal more, and I'm not offering the justification he proposed (for brevity's sake). I agree to varying levels of vehemence with most of what he said, but one area where I think I have to disagree is his advice to only refactor to patterns. I can imagine where this comes from--because patterns can be abused (paternitis as he said). But I think saying refactor to patterns shows a big misunderstanding of the point and value of patterns. This is why it's important to pay attention to the context and rationale in a pattern--so you know when to apply it. But patterns should be used where they apply--they're known, established, tried and true ways of solving particular problems in particular contexts! If consistency is akin to godliness, using patterns is ambrosia.
One last interesting note from this session was the admonition to consider using or creating a domain-specific language where it helps with the usability of the API. His example was around JMidi and JFugue, where JMidi is a terribly verbose API, requiring the construction of and coordination of a host of objects to do something simple like play a note, JFugue offers a simple string-based DSL that is based off of musical notation to let you place a whole series of notes very compactly. Good/interesting advice.
The last session I went to today was one based on practical pair programming. I was actually on my way to a class on Business Process Modeling Notation, which would have been potentially more intellectually stimulating, but I walked by the room with the Pair Programming session on it and had a sudden feeling I should attend it. When I thought about it, I figured that I'd put off giving the idea fair play long enough and that I should take the time to hear it in more depth. I figured it'd have more immediate relevancy to my current work situation in any respect.
I won't belabor all the points because I suspect with good reason that they're all the standard arguments for pair programming along with a good bit of the "how" to do it in real situations. He actually has a number of patterns and anti-patterns to further illustrate good/bad practices in pair programming. It was an interesting extension of the pattern-based approach (to people). Suffice it to say, I think if you can get buy in in your organization it is definitely worth a try. There are numerous difficulties with it, chief one being it is hard to do effectively in a non-co-located environment, but I think I'd try it given the opportunity.
One thing that I've come to the conclusion on being here is that TDD seems to be unanimously accepted by those who have actually tried it as a best practice. The API guy went so far as to say that he won't hire devs who don't have TDD experience. (I think that's a bit short-sighted, but I take his point.) It's something to think about for those still hesitating to adopt TDD.
I met up again with the same fella I met last night. We were both in the pair programming class at the end of the day; he's been doing pair programming on a few teams at his company for years and is a fan, though he definitely attests to the difficulty of dealing with prima donnas, which apparently are more tolerated in his LOB (because they have very specialized knowledge that requires PhD level education). So he wasn't able to carry XP to his entire company. He also said that pairing (which was echoed by the presenter) is a taxing process; 4-5 hours max is good.
We also had a good long chat about things Catholic. It's good to know that we Catholics will be getting another good, solid deacon in him. I imagine tonight won't be the last time we talk.
All in all, another great day. Learned a bunch. No sessions I regret going to thus far, which is I think a big compliment for a conference. :)