Code Mash session: A Programmer's Guide To User Experience

• Look for most experience, honest, and knowledgeable people for coming up with UX
• When "interviewing" people for what they're looking for in the app, need to have a conversation.  Given through scenarios: "Process a credit card", "Answer a support call"
• Put all scenarios into a very high level view into a specification document
• Give a one-sentence description of what the app does
• Group features together into sub-projects.  Go over these sub-projects with the users to see if they really fit together and make sense to the user.
• "Is this REALLY something we're really going to need?" <-- feature that you might want to take away/never show to the user
• "Is this something we CAN'T do without?"
• "Maybe we need it..." <-- nice to have's
• Use a sharpie marker for designing the interface so you don't get into the nitty-gritty details
• No laptop during the design phase.  Gets you really thinking about the UI from the user's perspective
• Use native controls for web pages because people know what the controls look like and know what to do with them.
• Typography is extremely important.  Serif fonts are useful for print/small text sizes (< 14pt), San Serif more important for headers.
• Black on White is not always readable.    Use a dark gray #333 or so
• 1.5em line spacing helps improve readability
• Whitespace is helpful because it improves readability
• Blur the design.  Can you still tell what the point of the design is?
• Designing interfaces is the same as Agile methodology.  Iterations are necessary to build them out appropriately.
• Great way to verify usability when you toss the UI in front of the user
• Watching a user sometimes provides the best way to find out if the UI is really working.
• Paper prototyping can be the most useful that doesn't end up costing too much in terms of development time.

Overall the session was pretty decent.  A little short on length without the Q&A though. 

Code Mash Keynote #3: JavaScript Will Save Us All

The keynote was given by Eric Meyer.  After a few days of getting up MUCH earlier than I'm used to, I was mostly awake for keynote.  So overall here's some notes from it:

• "How I learned to stop worrying and Love the DOM"
• Typeface.js
• Squirrelfish - JS engine in webkit.
• The canvas tag can do amazing things.  IE doesn't support canvas, but there's a JS that will convert it to VML
• dean.edwards.name/ie7 - fixes CSS issues of IE5 & IE6
• Bluff - JS port of Graff graphing engine from Ruby
• Web browsers can soon become "Speaking Browsers" in that they will read off the content to the user
• Microformats are useful, but they're generally invisible to the user.  There's a Firefox plug-in that will pick them up, but it groups all of them on a page together and it isn't always obvious for the user to keep an eye on the bar.
• Processing.js is an interesting project that makes use of the canvas element
• Objective J came about as a way to carry Objective C to the browser
• 280slides.com is a presentation software that's entirely web based
• IETF is the group that takes the "Innovate first, standard second" as opposed to W3C which is "Standardize first, innovate second"

Code Mash Open Space Session: Getting Started in Speaking

Really great information from a group of about a dozen people including myself.  There was definitely a mix of people that have done several talks before, including larger conferences; some that have maybe spoke in front of coworkers or their user group once or twice and just wanted some more tips; and then those that like the idea of being a speaker, but not sure where to start.  Some keys points that were touched on:

• Be passionate about what you're speaking on.  It's picked up on really quickly by the audience
• When writing up your abstract and bio, it's a difficult balance to make it interesting and show that you're a trusted source that is worthy of the audience's time
• Make sure to practice the speech, as well as prepare for possible failure points (bad hardware, code doesn't compile, etc.)

Code Mash: Guerilla SOA on the WCF

Presented by Joshua Graham. Part of Thought Works

Thought Works -> Twist - Collaborative Test Automation

• SOA -> Same old architecture?
• ESB -> Erroneous Spaghetti Box?
• Agility -> Embracing change, designs that don't anticipate everything but facilitate change, enabling people to get things done
• Simple, Incremental, Planetary Scale, Integration Architecture
• SOAP was okay, but it had a LOT of downfalls because of tight coupling, versioning, etc.  It's why so many people go to REST
• Many people approach WCF the same way the approach DCOM.  There's a remote object I'll call methods on, get it's state, etc.
• Dynamic type of integration binding helps out a bit, but there's still a lot of overhead.
• Syntactic binding allows a more open connectivity between service and client
• What we wanted
• Not exposing domain model types
• Flexible content model
• No types mirroring content model
• consumer-driven contracts
• light XSD
• Schematron-style validation and message comprehension
• [MatchAllEndpoints] attribute on a service class?

Overall not that great of a session.  The only "cool" part of the presentation is that he's using a Java client to talk to the service hosted in IIS.  Basically he presented a 100% pre-built solution that doesn't really go into the framework that much because it has one method that creates it's own SOAP message.  The one method processes the message and based on attributes/nodes that are present it will processes the message a certain way.  Defeats the purpose of using WCF because it does a lot of the work automatically.  Guess I'll have to hit on those points when I give my own presentation in March.

Code Mash Keynote #1: Venkat Subramanian

So far there's been several shuffling from the printed schedule, including the order of the keynote speakers.  So the morning keynote for day 1 of Code Mash is Venkat Subramanian with the topic "Pointy-Haired Bosses and Pragmatic Programmers: Facts and Fallacies of Everyday Software Development."

Here's some summary points from the keynote:

• The semicolon abuses the pinky.
• Often head fallacies as Best Practices.  Generally a good sign it should be questioned.
• Emotion, stress, bias, ignorance, impatience, past events, and intolerance all lead to fallacies about technology
• Asking the question "Why?" will help fix issues.  In general it helps to ask it about 5 times a day to really learn something.
• Fallacy: "More money & time will solve our problems".  Having clear goals for a project is the best way to get things done.
• Service Packs sound much better than Patches.  You don't have a "problem", you have a "challenge".  Technologies aren't "stupid", they're "interesting"
• The longer the project goes, the more prone it is for failure.  By 3 years it is almost certainly dead
• Big companies can afford to be stupid by spending and spending without shipping software.  Government is the only "company" that can afford that model
• "If your objective is to build what your customers wanted, you will fail.  You need to build what they still want"
• Fallacy: "It's got to be good because it's from this large vendor"
• "Using software because it's free is like getting into arranged marriage for the sake of money.  Where real love?"
• Molding-Colossus Problem: we complain that software is old so we ask vendors to fiddle with it.
• RDD - Resume Driven Design.  Using software because it will look better on your resume than what a project really needs
• Infatuation is fitting the technology to the problem
• Standardization before Innovation == BAD IDEA!
• Fallacy: "We're off-shoring because it will save us money."  The gap in cost is closing in on 1:1.  Companies figured out they're methods are already failing, so they figured they might as well fail-for-less
• Huge turnover in staff in India off-shore companies
• "Hire smart skilled developers who can learn fast".  "Small team of highly capable developers is better than large teams of below average developers".  Off-shoring isn't bad, just take advantage of great talent world-wide.
• Fallacy: "Dynamic Languages are not safe."
• C programmers are generally excited and say "I can't wait to get to work and see what this crap does today!"
• Java's 13 years old.  What do you expect of a 13 year old???? (in reference to having "2.0 - 1.1" result not be 0.9, but Groovy it works despite being on same JVM engine)
• Generics in Java is screwy because of the backwards compatibility.
• Royal Gorge Bridge is 1000ft above the Arkansas River.  It has a sign that says "No Fishing From Bridge"
• "Humans have a natural tendency to complicate and confuse".  Especially noticeable at Starbucks with coffee sizes.
• Developers are like prehistoric cave artists.  As soon as the creator walks away, any special meaning to the symbols lose all meaning.
• "My code is not testable" == "My code and design sucks!"
• Unit testing == exercising

Overall really good stuff, but his use of video, changing color schemes/fonts kind of hurt it.

Code Mash Precompiler (Day 0) review

I already posted about my TDD in .NET session from the beginning of the day.  It was really good information to pick up.  It didn't trigger the light bulb for fully understanding TDD like I was hoping for, but it definitely brightened the topic quite a bit for me.  Guess I'll have to start digging into that more to grok it much better.

In the afternoon there really wasn't really any particular session that seemed absolutely appealing to me.  I've apparently haven't spotted where the Open Spaces sessions are happening so I took the law-of-two-feet approach.  I started out in the Kanban 101 session presented by David Laribee.  Decided on that one because, well, David Laribee is notably known for naming ALT.NET (not creating it, but giving all the principles a collective name).  Overall the session didn't provide me much additional knowledge.  The biggest useful piece of knowledge came from him giving a cursory overview of Mary Poppendieck's Value Stream Mapping session.  That's definitely a topic I want to spend more time digging into as it helps analyze a process and point out where bottlenecks are in resources, be they human or material.  It provides good documentation to take to management when you're fighting for additional resources to increase value in a team so more revenue can be brought into the company.  The other part of that session I caught dealt with setting up and using a Kanban board to track progress of items in the backlog.  I've seen this before and understand how they work, so while the in person explanation was interesting, it didn't help out that much.

While floating in and out of the Kanban session I wound up in the Windows Azure session.  Basically caught enough information to see that the UI for managing your slice of the cloud isn't impressive nor crappy; that the technology aspect of Azure is pretty solidly laid out and growing, but the political aspect still has a LOT to take into account before pricing & SLA's start being defined; that Azure was another one of Microsoft's "we've been toying with this idea, what do you developers think?" sort of programs; and all the examples they were going to run through are available from Azure's website.  The only useful piece of information I walked away with from the session was what steps to take to get your named bumped up in the queue of people being let into the closed testing of the live cloud.

By the end of the sessions most of the sponsors had started showing up and getting things set up.  And they're evil I tell you.  Pure evil.  They had Rock Band 2 set up.  Here's a picture of people getting into it after I rocked out a few songs.

After the dinner Carl Franklin and Richard Campbell got things set up for recording the panel discussion for an episode of .NET Rocks.  Richard gave a great retelling of the story of Goliath and the magnets it had in it (first told on an episode of Mondays).  I can't find which show it was, otherwise I'd link to it because it's a great story.  Then began the panel discussion on RIA.  The funny part was keeping an eye on twitter tags for Code Mash (#codemash and #codemash2009) you could see that every one of the panel guys had sent at least one tweet while the recording was going on.  And they were given a bottle of bourbon as a gift which they started off started drinking during the show (I'm sure it will be in the show when it's published).  The part you'll miss out on when you listen to the show is that when there was a few glasses worth of bourbon left in the bottle Carl kept looking around the audience and gesturing for people to have a glass.  That was too funny.

To finish off the day I made my way around the sponsor booths again and surrendered my contact information to even more companies.  Hey, they have awesome swag that'd be cool to win, but having about a 1/400 chance of winning I doubt I'll actually win anything.  And had another go at Rock Band.

I'm looking forward to the sessions tomorrow, which I'm sure there's going to be much more to cover since there'll be 5 sessions to attend.

Code Mash 2009: TDD in .NET

This will start my "blogging on the go" posts with primarily notes from the sessions I'm attending.  This class was pretty useful for digging into TDD if you're at least familiar with unit testing.  The lecture was primarily less than an hour with the vast majority of it being a really large pair programming session.  The instructor was Phillip Japikse.  Really good stuff

* 2 main type of testing: state-based testing; interaction-based testing

* "Software Defect Reduction Top 10 List" IEEE Computer January 2001

* state-based - initialize, provide initial data, interact with it, assert something changed (or did not), must test for both Happy & Unhappy paths

* Interaction-based - verify behavior of SUT, mock the object, ensure behavior acts

* Code Coverage - rough measure of what's tested.  Just another metric.  Roughly 80%

* Dependency Injection is also known as IoC.  Doesn't really cover the differences though.  Basically covers it's for separating instantiation/implementation.

* Constructor Injection; Setter Injection; Interface Injection

* SWAG = Scientific Wild Ass Guess

* Pre-requirements for TDD: Need requirements, ready access to the Product Owner, Source Control System

* no bugs, write opportunities for other developers to fix

* when refactoring, eliminate duplicate code or anything that isn't self-documenting if it's complex.

* writing tests - Name should describe the action of the SUT

* Add the correct Assertions

* Flush out the code to enable the build

* keep list of tests close to workstation - useful to write ideas about other tests on piece of paper (To Do items).  Keeps focus on current work.  Go for easiest ones first.  fresh sheet of paper every day, with not-done items as first items

* possibly leave the last test in a failed state to get you back into the mindset.  Helps jog the memory

* TDD should be applied to any code you actually write.  TED should be for Generated Code (somewhat...)

* FTW: QA team can actually come up with value-adding issues.