There’s a big difference between #1 and #2. Compare David Beckham vs. Landon Donovan; Hey Jude (#1 hit 1968) vs. Love is Blue (#2 hit 1968); iPod vs. Zune. Oftentimes the #2 is functionally superior, but for some reason #1 still wins. According to Spolsky, it comes down to three elements:

1. They make people happy.
2. They obsess over aesthetics.
3. They observe the culture code.

On “make people happy”, Joel talked about how helplessness is actually a form of depression (“learned helplessness”). Humans by nature want what’s called agency – a feeling that we can make things happen. So when things don’t happen, we get frustrated, depressed, and give up. There have actually been studies on this.

Basically, people feel happy when they have agency. So what should you do? Put people in control.

Example: Abercrombie order page (wizard style process, no user control of when and where in the order process you are at) vs. Amazon order page (you are in control, click anywhere until you hit the order button).

“Put the user in control”. Give positive feedback – click and something happens. Make sure it’s instant feedback.

Also, for fun on this topic: http://www.theonion.com/content/node/34156.

On “Obsess over aesthetics”, look at the MacBook Air vs. the IBM Thinkpad. Or the iPhone vs. the new Verizon iPhone-like phone. Joel says, “The iPhone looks like you can swallow it like a pill it’s so smooth”. He mentions how Apple changed the manufacturing process of their laptops in order to eliminate one seam and one screw in the MacBook Air design. They are that obsessed with aesthetics, and the results show.

Another example: Dunkin Donuts vs. Starbucks. Dunkin much cheaper, but people still pay “$4 for a coffee”. Why? Joel says “color”. Dunkin screams at you. Starbucks is inviting. It’s the aesthetics.

To address aesthetics, bake it into your design process. Don’t “skin” it. That’s lazy, not obsessive. If you want to be #1, then aesthetics has to be part of your design.

On “observe the culture code”, this term was invented by Clotaire Rapaille in a book called The Culture Code. He says there is something in culture that gives a feeling of safety (actually relates it back to mothers, using words such as “round”, “soft”, “warm”).

The culture code is a product’s emotional, cultural space. The Ruby language is a good example of this, as its start created an emotional appeal. It was a culture code that brought passion and made people fall in love with it.

• Do the Right Things: Adapting Requirements Practices for Agile Projects by Ellen Gottesdiener – This session was probably good for people who either haven't lived through or studied some level of requirements derivation and analysis practices, but for me this was a painful session to sit through. Once I realized that the session wasn't going to offer anything new I probably should have moved on, but instead I think I pulled out my laptop and answered emails instead. The gist of the session was about techniques for eliciting, deriving, and analyzing requirements and balancing the techniques between agile processes and (let's call them) less agile processes. No new home run methods of requirements management – just a hefty overview of the different approaches out there. Like I said, if you haven't been exposed to these things it was probably a good session to attend. For me, I could have and probably should have spent my time elsewhere.

• Scaling Agile Software Development by Scott Ambler – I like Ambler's style. He's a straight shooter and holds nothing back. As he calls it, he speaks in the real world, not some fantasy world. Anyway, in this session Ambler discussed the real world practices of agile techniques and compared it with the theoretical practices of agile techniques. In doing so he brought up a lot of statistics and misconceptions people have about agile, including claims like:

  1. Agile teams don't write documentation: They do. They may even write more documentation than other methodologies.
  2. Agile teams don't model: They do. They just don't try to model everything up front, due to iterations.
  3. Agile doesn't require planning: Wrong. Agile requires a lot of planning, and more importantly it requires a lot of discipline. Ambler argues that agile requires more discipline than any other software development methodology.

 And of course there are others as well. Turns out Ambler is a great source of one-liners with quips like "Real professionals act in the real environment and not in a fantasy world of their own" and "Traditional development practices cover up a lack of discipline with paper trails". Regarding the statistics about agile, Ambler presented a lot of statistics collected from his DDJ Agile Adoption Survey 2008. Be sure to check that out for some very interesting numbers on both agile adoption and what agile techniques can actually do for you.

• Clean Code II: Craftsmanship by Robert C. Martin – This session was a little difficult to take notes on. I think it's just Martin's presentation style. In fact, most of my notes are one-liner quotations. Even so, this was one of the better sessions I attended in that it really drove home the point that software development isn't about just your code or just your process or just your customer. It's about all three, and the reason software development is so difficult is because in order to do well you have to do well at all three. Martin believes in the KISS principle – Keep it Simple, Stupid. He believes that continuous refactoring is incredibly important, as much as iterative development is important. My impression is he thinks professionalism is lacking in the industry – I agree with him on that – and that software developers need an "attitude of cleanliness" with their code. An example is how a top notch chef constantly cleans their utensils while cooking. In the same manner, we should constantly clean our code while developing. At another point, he quipped, "How can you claim to be a professional if you check-in code and don't know that it works?" and the "mark of unprofessional behavior is to have a huge bug list". Amen.

In all, it was a great week at the SD Best Practices Conference. While I didn't learn anything outstandingly new, attending this conference helped connect a lot of dots and turn on a lot of lightbulbs in my head that reinvigorated my desire to do things better. I'd highly suggest this conference and SD West to anyone looking for better fundamental software development insight.

There's a few sessions that I have decent notes for that I'll be posting in the coming days.

The only problem with the SD Best Practices show is that the expo is very small. There's maybe 10 vendors? I suppose it makes some sense – SD Best Practices seems to be about the equivalent of the gaming industry's Austin Game Conference relative to GDC (the software industry has their big SD West conference). But the problem is that it's easy to get burned out if you go to every single class session, which I have tried to do – and failed due to burnout.

In any case, these were the classes from Day 3:

• Introduction to Financial Engineering for Software Developers by Christian Gross – This was a great overview of the terms and methods used in the financial industry. Gross clearly laid out how it's important that software developers going into the financial industry understand the business side of financial engineering, which is practically required to have any chance of succeeding in that environment. Not that I'm looking to join the financial industry. My interest lied in the terms and techniques used to build software for the financial industry.

• Quantitative Testing: Moving Beyond Unit Testing by Christian Gross – Another one by Mr. Gross, where he discusses how to use statistical methods to verify that your algorithm doesn't just function but that it's actually right. I'm a firm believer in using data to back up your assertions, so this class was really interesting to me. Gross doesn't advocate losing unit tests, but he does believe that unit tests are limited in what they can do as they only provide 80% coverage (i.e. does it function?). The other 20% is where the most difficult problems lie and may only surface once in a while, but through quantitative analysis of your algorithms you can verify that your algorithm is correct (i.e. is it right?). This is a topic I want to explore more, particularly in how it can be used for 3D simulation and gaming.

• Code Metrics and Analysis for Agile Projects by Neal Ford – This one was mildly disappointing. I was hoping it would be a sort of extension from the Quantitative Testing class and discussed more about analyzing your code metrics and making strategic decisions off those metrics, particularly as applied to agile projects. It jumped into that topic a little bit toward the end, but a good chunk of time was spent watching code analysis tools run on the Java struts framework. For one, I didn't even know what struts was until I looked it up (framework for web apps), and two, do we really have to watch code analyzers run and look at the statistics they pump out about the code? In any case, I did pick up a few words to throw into Google and did get a better understanding of some metrics tools I had recently heard about (i.e. treemaps). Overall, though, I didn't have any "aha!" moments. For the most part I already collect and analyze the data Ford presented. It was a bit of a low after the fun statistical stuff from earlier in the day.

So now it's Day 4, the final day, and I'm not entirely sure what I'm attending yet. Today there's only one "must attend" class held at the end of the day (of course) called "Clean Code II: Craftsmanship". I suppose I could hope over to the Stroustrup & Sutter sessions on C++ if I don't find anything that really catches my eye.

With Agile, I have researched and studied it extensively, including implementing pieces of it at the workplace, so with these classes I'm looking for the little nuggets that help further refine my understanding. For the UI design, I recognize that while I've come up with my own approaches to building better interfaces, hearing an expert speak on the topic will only help.

These are the classes I attended:

• Introduction to Agile by Michele Sliger: Basic overview of agile principles and practices of iterative and incremenetal development, including a discussion of the different agile methodologies in use today.
• xUnit and Test-Driven Development by Justin Gordon: While more Java and JUnit focused, this was a good talk on how to use TDD in your project, including how to start TDD with legacy and pre-existing code baselines.
• Agile Estimating and Planning by Mike Cohn: A fun session on how to get better at estimating your releases and iterations in an agile project, including talk about story points, ideal days, and "Planning Poker". They even gave out a deck of Planning Poker cards to every attendee – enough cards for four people! Free stuff is good.
• Designing for User Performance by Larry Constantine: Very entertaining presentation discussing how to create better UI designs by changing your philosophy from inside-out to outside-in thinking when designing interactions with software. Constantine is a great source for one-liner quotations that summarize his presentation, including "The more you try to organize, the more you degrade user performance", "Think from the user's perspective", and "Anytime something simple has a user's manual then you know something is wrong".

Again, once the conference is over, and I'm able to settle in I can provide more detail from my notes.

For Day 3, I'm attending sessions on Financial Engineering for SW Developers (sounds cool!), Quantitative Testing, and Code Metrics for Agile projects.

The major topics covered involved how to use templates, explicit partialization, and partial specialization to make C++ code more secure so that errors are found at compile-time instead of run-time. A lot of the discussion revolved around ideas discussed in the book Modern C++ Design by Andrei Alexandrescu and focuses on more examples of how to use generic programming to solve problems and tighten code.

In the near future I may post a few things I learned or had "aha!" moments about. As for now, I'm tired and need to get ready for tomorrow.