As I sit here on the train home, I've been thinking (and writing) about a lot of stuff. But I figured I should put this post together for completeness and finality, even though I only made it to one session today before I left early. Last night I was shocked and somewhat dismayed to find that I had somehow managed to book the train for return on Saturday afternoon rather than today. I looked at my reservation email, thinking surely the ticket was misprinted, but nope, the reservation says the 22nd clearly in black and white.
Now, those who spend much time with me know that I tend to be sort of the absent-minded professor type. I often have trouble keeping track of the details of day-to-day things (but I can tie my shoes!). I like to think good reasons for this, but whatever the reasons, that's me. So I can totally imagine that somehow I tricked my brain into thinking that the 22nd was the day I wanted to return when I booked the train.
That said, I think this is a good opportunity to observe a way in which the UX of the reservations system could be improved. If it had simply said somewhere that the return trip was on SATURDAY and not just used these obscure things called numeric dates, I'd immediately have seen and avoided my mistake. But nowhere online nor in the email nor on the ticket does it say Saturday. In fact, there is SO MUCH GARBAGE on the ticket, that the non-initiate has trouble finding anything of value. So think about that if you're designing some sort of booking system--show the day of the week, please. :)
Lean Process Improvement So this morning, on top of being tired because I stayed up late writing, I was late for the class I wanted to attend, one called Agile Architecture. Unfortunately, it was in the smallest room in the conference (same one as the manager meeting yesterday), and unfortunately, the planners didn't anticipate attendance to that session correctly. Plus, this room had this odd little old lady who felt it was her duty to prevent anyone from attending who had to stand.
Yesterday, I watched her try to turn away (a few successfully) quite a few folks, even though there was plenty of room on the far side to stand. She kept saying "there really is no room," but there was. What made the whole scene kind of comical was that she refused to go sit OUTSIDE the door, so rather than simply preventing folks from coming in and causing a distraction, she let them come in, then animatedly tried to convince them to leave, causing even more distraction.
Well, when I peeked in the door this morning, saw the full room and saw her start heading toward me, I knew I was out of luck. I just didn't have the heart to muscle by her and ignore her pleading to go stand on the other side, and besides, I don't like standing still for 1.5 hours anyway. So I was off to find an alternative.
I knew there wasn't much else I wanted to see during that hour, but by golly I was there and this was the only slot I could make today, so I was going to make it to a session! After two more failed entries into full sessions and studiously avoiding some that sounded extremely dull by their titles, I finally found one that sounded nominally interesting and had a lot of open space. I really had no clue what I was getting into...
It ended up being somewhat interesting. It was about applying the "lean process" from the manufacturing space to software development. I'm personally not really into process and methodologies, particularly when they come from disciplines that are only marginally like our own. But this did sound like it could be useful in some situations, particularly in software product (i.e., commercial) development.
He talked about value stream mapping, which is basically modeling the process flow of specific activities in product development from beginning to end (so you'd do one for new feature dev, one for enhancements, one for hot fixes, etc.). It sounds like it does have potential to be useful as long as you don't spend too much time on it. Particularly if you think you have a problem in your process, this method can help you to both visualize and identify potential problems. If you do product development, it's worth a look.
Final Thoughts After that session, I made off to go to the 12:05 mass at the chapel outside the convention center. My deacon friend had let me know about it, and I was glad of it. And he was there, so after mass, we went back into the conference to grab lunch together. Talked more about the usual, and then I had to run off to catch my train.
Looking back, I feel that this is definitely a conference worth attending. Of course, your mileage will vary. I wouldn't come here to go to a bunch of sessions on topics you're already an expert on. But the nice thing about this conference over others I've been to is that it really is focused on best practices. It's not really focused much on technology-specific stuff (though there was a bit of that), so you can derive value whether you do Java, C/C++, .NET, or whatever.
Also, it is a good place to come to meetings of minds from other technology experts, so you get some more exposure than you might normally to how folks are doing software outside of your technological community. And one interesting thing I noticed is that there is a tangible presence of software product developers, and that's a different and valuable perspective for those who are more used to, say, standard custom/consulting/corporate IT software.
Overall, if you look over the sessions and see topics that you haven't had a chance to explore in depth or maybe you want to just get exposed to other ideas in the software space, this seems like a good conference for that. I really enjoyed it.
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