Codemash retrospective

So I’ve been posting all these posts about the sessions from Codemash, but that’s not all that I learned during my time there.  So I thought I’d do an “outside the session” retrospective.

• No matter how well the facility prepares, 700+ geeks are going to kill the network.  It may have been the wireless access points, but no matter the case people quickly became used to near dial-up speeds again because of so much traffic.
• I really need to realize I know more about some topics than I think I do.  I went to a couple sessions that looked like they should be higher level and more technical, but ended up focusing on the 150-level type of coding.
• Great presenters follow the “what am I going to tell you, tell you, what did I just tell you” pattern for presenting.  They also are aware of their time constraints and will make sure to allocate enough time for Q&A, or provide a way to contact them for follow up.
• Developers have the odd behavior of always sitting near the back of the room.  Some of it makes sense when the power source is in the back or the projector screen is so huge that it would cause neck problems by sitting up front.  This really makes no sense because of technical issues like the mic not working make it easier to hear the presenter.  (ironically, I’m sitting in the back row while I’m writing this up.)
• A developer conference being held in Sandusky, OH in the middle of January definitely doesn’t sound like a bright idea, but it’s obviously a great conference.  It sold out in about a month.  Maybe it’s the waterpark that’s attached to the hotel.  Speaking of which…
• I now understand the draw of sitting in a hot tub outside in freezing cold weather.  The hot tubs in the Kalahari waterpark all have an outside area and the feeling of sitting out there was amazing.  That almost made me want to skip some extra sessions to head out to them.
• Enter The Haggis is an awesome band.  Edge Case Software paid for the band to come out to the conference and perform at the after party after the first day  of the actual conference (day 2 if you attended the Pre-compiler).  You can never go wrong with a band that has a bagpipe in it.
• Conference sessions are only valuable to you for the first few years of learning a new technology.  Either make use of Open Spaces (provided the conference has it), or network with others.  Open Spaces is great because if there’s something you want to talk about, get it posted on the open space board.  Maybe a time slot has no valuable conference session to you, so check out what’s going on with Open Spaces.  You can learn quite a bit more that way, or meet people you normally wouldn’t.  In my case I caught Jeremy Miller giving a presentation on Storyteller and his goal with it.  And for networking, I got several contacts for the Madison .NET User Group to hopefully get some more prizes coming in.
• Speaking of Jeremy Miller, I have to admit I’m now wondering why he’s considered such a big deal.  Sure he has done some great things in the open source field, but his presentation skills are kind of lacking.  He has a lot of great ideas, but he takes forever to present them.  I now understand where his monolithic, thousands of words type of blog posts stem from.  Seriously, you’re talking to technical people who are children of the Internet.  Our attention spans aren’t that long.  Keep it moving and vary it up a bit.
• You can (usually) quickly tell how old some of the pictures are for those that use actual images of themselves on Twitter.  Those that have a somewhat recent picture made it easy to recognize them.  Although it does give you that surreal, “Where the hell do I know you from” feeling when you are sitting right next to the person but can’t place a name with a face.
• Vendors that use twitter to give away prizes at the conference can be very annoying.  In the case of Pillar, they had a retweet message about being entered to win a Kindle.  The problem is that people just kept retweeting it, even beyond when the conference is going on.  Seriously annoying as all it did was spam the #codemash hashtag.  Telerik took a better approach in that only those that attended the session knew what specific @’s and #’s to put in a message to be entered for a prize.

Overall an outstanding conference.  Definitely looking forward to attending next year, although I think I may actually spend more time in sessions on languages I don’t normally use everyday.

Codemash: Credit Crunch Code

Paying Back the Technical Debt

Presented by Gary Short.  The talk was about the shortcuts we have to make when coding and how we can start making up for them.  It’s great learning something from a guy who has a strong Scottish accent.  He is has an outstanding ability to present though.

• Ward Cunningham was the one who coined the term “technical debt” in 1992
• Came up with the term as he was doing work for a financial institution, so it was very similar to borrowing money.
• With financial debt, it can be like “virtual debt” in that you’re aren’t earning as much money as you could on the money that incurred the debt.
• By incurring the technical debt, you can cause the product to be shipped late (causing a bad brand name), a loss of market share, or loss of excitement to work on the product.
• Just as financial debt isn’t all bad, technical debt isn’t all bad.
• If you need to hit a milestone by a certain time to get the company buy in, it’s fine as long as you pay it back
• The only safe amount of technical debt in a codebase is 0.  But that’s like saying a codebase has 0 bugs.
• Really just need to get it to a point where you don’t notice the issue, even if it’s really there.
• You don’t want to have a logarithmic graph describing the technical debt.  You want a saw tooth graph describing it.  So every couple months take some time to pay it down.
• It’s difficult to calculate the technical debt.  He has a nice, complicated formula that factors in things like employee costs, hardware costs, software licenses and software brand costs.
• Waterfall methodology is an anti-pattern
• Because you’re making all decisions up front, the costs go up as the project goes further.  Since you can’t change, it’s an insane amount of cost.
• Because the subject matter expert has to go through a learning curve (no matter what they know), there’s going to be things that aren’t known up front.
• Agile isn’t necessarily the fix to the Waterfall anti-pattern
• Try to incorporate elements of Agile into Waterfall so that the cost isn’t so high
• Not-Invented Here anti-pattern
• Development teams spend time developing software which is not core to the problem they are trying solve.
• Bunch of reasons why not to use a 3rd party product.
• By having a developer working on a component that they find is harder than initially thought and buy the 3rd party product, they’ve incurred major technical debt.
• Buy the components if it truly will save time.
• Use open source if you can.
• If these don’t work, then work your own
• Objects that are in code together stay together anti-pattern
• The classic car example.  Car’s have no behaviors because it’s an inanimate object.  Actors perform behaviors on the object.
• It’s technical debt because it’s a simpler object graph.  We repay it later because of the cost of adding functionality.
• Because adding functionality becomes so hard, it damages the brand.
• It’s not horrible because it allows you to quickly get to market.  Just realize the cost it will incur.  Decide if the debt is worth it.
• Sensitive Tests anti-pattern
• tests that are sensitive to context/interface/database
• make sure tests are as isolated at possible.
• How to spot technical debt
• technical debt is pretty much invisible.
• Take the astronomer approach to finding technical debt in the way that they find planets that can support human life.
• Using things like the burndown graph to find when issues are coming up.
• The average productivity should stay pretty consistent
• If it’s going down, then technical debt is accumulating because it’s harder to add features
• the number of tests per feature should be pretty similar.
• if it’s increasing per feature, it’s showing how difficult adding the new features are becoming.
• if the average team morale is decreasing, it is a good sign things are becoming worse and becoming harder.  Measure this by having the team members rate their happiness on a 1-5 scale anonymously.
• Technical debt is a silent killer
• http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
• http://www.martinfowler.com/bliki/TechnicalDebt.html

On a side note.  Andy Hunt’s keynote over lunch was outstanding.  He talked about the mother of all bugs: the human mind.  It essentially covered all the psychological defects that exist in the human mind.

Codemash: 0-60 With Fluent NHibernate

This was presented by Hudson Akridge.  He contributes to Fluent NHibernate.

• Automapping
• the classes need to be public (classes were A and B)
• all properties need to be virtual
• in the configuration
  
  Fluently.Configure()
  .Database(SQLiteConfiguration.Standard.InMemory())
  .Mappings(mapping => mapping.AutoMappings.Add(AutoMap.AssemblyOf<A>().Where(x=>x.Namespace == “…”))
  .ExportTo(Directory.GetCurrentDirectory()))
  .BuildConfiguration();
• Fluent Mapping
• Needs a parameterless constructor
• Nested Expression Exposition
• Nested Mapping
• Reveal using string based names
• www.fluentnhibernate.org
• http://github.com/jagregory/fluent-nhibernate

The talk was given to the Chicago ALT.NET group back in July 2009.  You can catch the video here: http://chicagoalt.net/event/July2009Meeting060withFluentNHibernate.

Codemash: Software Design & Testability

This session was presented by Jeremy Miller. 

• Testability & Design is not about mock objects/interfaces.  It’s about finding/removing/preventing defects.  Better partitioning or responsibilities.  Boils down to “Divide & Conquer”.
• “I don’t code, I ship software”
• Take advice from Mary Poppendieck about optimizing the whole of the project, not just the code.
• Good Code vs. Bad Code
• The quality of the code has a dramatic impact on how productive the developer can be.
• Interesting quote from Michael Feathers: “I don’t care how good you think your design is.  If I can’t walk in and write a test for an arbitrary method of your in five minutes…”
• First causes of good design
• Feedback, Cycle Times, Batch Size
• Orthogonality
• Being able to focus on features independent of other features.
• Reversibility
• The ability to change a decision that’s been made about the code.
• Understandability
• Is the code readable and can be followed easily?
• Writing Automated Tests
• Set the system into a known state using known inputs
• It has measurable outcomes
• State based tests.  I.E. Calling a method to write a file results in a file actually being written.
• Interaction based tests. I.E. Verifying that a method is actually called.
• What makes tests better
• Repeatable
• Running the same test over and over always has the same result
• Runs Fast
• If you can’t run the test quickly, you won’t run them that often.
• Easy to write
• Easy to understand
• If you can’t quickly and easily glance at the unit test to verify what the test is aimed at, it’s not easy to understand
• Systems that are hard to test
• invoicing rules engine
• rules defined in an xml file
• invoice data read from stored procedures
• no seams in the application to break it apart.
• How do I test
• WorkflowProcessor
• Basic workflow logic
• State persisted to the database
• Sent emails at various times
• Things that are hard to test
• The database
• Active Directory
• Web Services
• Messaging
• Windows Services
• Remoting
• SCF
• WPF/WinForms
• System.Web Namespace
• External System
• Chatty APIs
• “Isolate the ugly stuff.  That essentially comes down to anything written by Microsoft”
• Test small before testing big
• Verifying that the pieces actually fit together
• Start working on the pieces you know how they work.
• It’s just the small pieces you’re working on, not the entire system as a whole.
• Code from the bottom up…
• start with the small pieces
• …or from the top down
• Use mock objects to flush out API and how things will fit together.
• Talked about Dependency Injection (with a rather strange bias towards StructureMap. Gee…wonder why…).
• Keep a short tail
• Can you pull it off a shelf and work with it without pulling down/in extra classes.
• Isolate the Churn
• Isolate when there’s a lot of change.

Codemash: T4 Code Generation with Visual Studio 2008

Presented by Steve Andrews.

• What is it?
• Was originally a DSL for creating code based on your model.
• Demo
• Need a template directive
  <#@ template language=”C#v3.5” #>
• Output directive
  <#@ output extension=”csv” #>
  one,two,thee
  four,five,six
• Expression blocks
  <#= DateTime.Now.ToString() #>
• Statement blocks
  <# for (int i = 1; i < 6; i++) { #>
  <# } #>
• Class feature blocks
  <# HelloWorld(); #>
  <#+
  private void HelloWorld()
  {
  }
  #>
• Include directive
  <#@ include file=”_IncludedFile.tt” #>
  
  remove the custom tool for the included file if you don’t want it to run.
• Assembly include directive
  <#@ assembly name=”System.Xml” #>
  <#= new System.Xml.XmlDocument().ToString() #>
• Import directive
  <#@ assembly name=”System.Xml” #>
  <#@ import namespace=”System.Xml” #>
  <#= new XmlDocument().ToString() #>
• T4 Toolbox
• Can generate multiple outputs per template
• Since the generator has to create a file by default with the same name, use it as a log of the output.
• Can create classes within the template that can extend Generator
• Can extend templates as well.
• Custom Directive Processor
• Need to put create some registry keys for the custom directives
• Custom host for running T4.
• Debugging T4
• Registry setting that you have to change from 10 to 2 if using above .NET 3.0

Have to say that I thought I knew quite a bit about T4, but really a great presentation overall.

Codemash: Powershell: Ten things you need to know

Presented by Matthew Hester and Aaron Lerch.  It’s interesting because much of the audience really hasn’t seemed to have even touched Powershell.

• What is it?
• Rich script environment
• Bulk operations
• Interactive environment
• The Active Directory Administrative Center that ships with Windows 2008 R2 is all Powershell driven.
• When to use it
• consistent, repeatable tasks
• talking with Active Directory, registry, WMI and others natively
• to create aliases to create commands that you’re used to.
• Make use of commandlet (a verb-noun syntax) and the parameters (the name-argument pair).
• Making use of the pipeline
• Talked about the Powershell ISE that comes with version 2.
• Useful commands:
• get-module –listavailable
• help “command” –examples/-detailed/-full
• Providers
• Get-PSProvider
• Custom
• DriveCmdletProvider
• ItemCmdletProvider
• ContainterCmdletProvider
• The ShouldProcess capability means it handles the –whatif flag
• Use PSCmdlet when creating your customizing commandlets.
• System.Management.Automation is the assembly to reference
• PSHost for hosting the powershell run space.
• The Windows Troubleshooting Pack is built on Powershell.

 

On a side note, this was after lunch, where Hank Janssen gave a keynote on PHP and Microsoft.  Pretty interesting stuff.  It’s great to hear about the efforts that Microsoft does with the open source projects that are out there.  Although he didn’t really plan on some of his demos being that horrible with the crowd killing the internet connection.

Codemash: Building maintainable ASP.NET MVC

This was presented by Chris Patterson from RelayHealth.  He’s an active open source developer, so that’s probably why his name sounds so familiar to me.  He’s also a Visual C# MVP.

• Since much of the audience are not ASP.NET MVC programmers, he covered a lot of the basics.
• Talked about some of the MvcContrib/ASP.NET MVC 2 features.
• Controller should be the only thing that talks to the Domain Model.  The Controller, View Model, and View all have an idea of each other.
• View Models should only have data.  No behaviors.  It should be a flattened structure.

Overall the presentation was aimed at those who’ve never looked at the framework before.  Maybe if I hadn’t already done a project using this technology before it would be worthwhile to me.  But overall it wasn’t quite what the session abstract stated.  So that means it’s time to kick in the law of two feet and go find a session that I’ll actually learn something.

Codemash: Agile Iteration 0

This was presented by Ken Sipe from Perficient.  It basically covered how to get Agile accepted into a business, starting out with the first iteration and what it all includes.  Overall the presentation was great, but he was a little scatter brained in actually presenting it.  It didn’t flow very well as it felt he was jumping back and forth quite a bit.

• Talked about waterfall development being the standard way companies generally tackle development.
• Iterative process’s biggest usefulness is the feedback.  But companies don’t like it because they can’t plan long, long-term goals of when things will be delivered.  Since priorities can be shifted around, knowing what will be delivered is nearly impossible.
• Talked about college experience when finding out you have a paper due in 3-6 months.  Most people finish it the night before/week before/weekend before.  When the instructor requires certain aspects of it at given points throughout the course, it’s an iterative approach.  You get feedback from the instructor earlier and can make the paper that much better.
• Similar approach with the NASA Apollo missions.
• Finding the iterative length is really about what feels right for the company.  Longer iterations means less feedback.  Shorter iterations means not being able to get things done.
• Iterative delivery helps develops trust between the development staff and the business.  Building the trust is essentially actually doing what you say you’re going to do.
• Agile is not evolutionary, no documentation, no architecture, cowboy development.
• Pair programming is extreme of code reviews.
• Programming engages the logical side of the brain.  Taking a break causes it to disengage and lets the creative side tackle the problem.  Pair programming allows a full brain to tackle a problem.
• Pair programming is actually about 1.5 develops worth of work, not just 1.
• “Bus Number” – the number of people on the project that need to be hit by a bus before the project can’t continue forward because expertise is gone.
• Agile at the micro view:
• Initial opening meeting
• *everybody* is there to make sure everybody’s on the same vision of the project.
• Agree on acceptance criteria
• Agree on the priority
• Break down into groups to figure out what some resources already exist or come up with estimates
• Opening meeting
• Should be attended by Developers, DBA, User/BA, Architects, QA
• Using a BA or having limited contact with the user, generally a failing point is not meeting the acceptance criteria.
• Assign tasks.
• Standup Meetings
• Can be sabotages by the Project Manager because they’re trying to get and provide too much information.
• Only pigs are allowed to talk.  Chickens don’t talk.
• Closing meeting
• What was accepted by the user?
• What is the velocity?
• What architecturally significant  has changed?
• It is a quality check of general
• Were the estimates accurate?
• Is the team performing as expected?
• Is QA catching bugs that weren’t functional bugs?
• Are functional bugs making to QA? Are the unit tests not being that effective?
• Agile at the macro view:
• Starting is the hardest part.  Having a mentor who’s been through it is the greatest point
• Pre-iteration 0
• Project inception
• Stake holder level
• Business opportunity/concerns
• Collection of stories
• Estimating ROI and project justifications
• Building up team/resources
• co-ownership of code
• prepared to steal tasks
• pairing capable
• expected velocity.  Adjust story alignment and release plan.
• Team phases:
• forming
• excitement/optimism
• storming
• resisting task, disunity
• norming
• constructive criticism
• performing
• self directed
• iteration sizing
• initial list of risks
• release plan
• iteration 0
• 2 store development approaches
• Majority of the stories upfront with the major understanding that you will likely discover more
• sone stories upfront to prime with the intent that you’ll have a trailing analyst
• Either approach needs an Analyst, BA or PM to keep feeding stories into the next iteration.
• Automate as many things as possible.  Not just in software, but bringing on new people to the team.  Take out as much manual work to a simple button click/one command line.
• Perform some spikes to learn about the new tools for the project
• Build system/continuous integration is a necessity.
• Set up reporting: burn down charts
• Get a story reposity/wiki going
• The general standards, annotations, and upfront patterns (MVC, presentation model, logging in all aspects…)
• feature slip are those features that don’t get completed in an iteration, but were meant to be part of it.  Similar to RUP’s time slip.
• If you have humans doing regression testing, you will fail.
• Talked about different options in working with QA in the iterations.  Will post pictures later.

Codemash Keynote: Mary Poppendieck – Five Habits of Successful Lean Development

What a way to kick off the actual part of the Codemash conference with a keynote from one of the major voices of the Lean development segment.  None other than Mary Poppendieck.  Some of the points of her talk:

• Key tenants of Lean:
• Eliminate Waste
• Focus on Learning
• Build Quality In
• Defer Commitment
• Deliver Fast
• Respect People
• Keep On Improving
• Optimize the Whole
• Think about the entire process, not just the software
• The 5 Habits
• Purpose
• Many developers are only doing their job because somebody told them to do it.  Sure coding it fun, but do they really know why they’re doing it?
• Keep the development staff near the customers to focus on what the end users actually NEED vs keeping them completely separate and all the requirements are tossed over the wall where the developed software is most likely never used.
• Essentially just get the developers involved in the business to better understand what the needs of the business are.
• Possibly have the developers actually do the job that they’re developing the software for to understand the pain points.  e.g. call center software.
• If nobody’s requesting new software features, it means nobody’s using the software.  It doesn’t mean the software is feature complete.
• That’s why open source software seems to be so easily programmed.  Those programming it are those that use it because they need to use it.  They know where the pain points are.
• Passion
• Developers like getting passionate about their work.  If they’re not passionate about their purpose at the company, they tend to get passionate about the minutia of development tasks.
• Cost Center Disease – focus on cost reduction instead of delivering value.
• Typical places this is found: IT departments, government organizations, some consulting firms
• The problems include not being able to focus on giving better customer outcomes, no real engagement with customers.
• Example of a passion – the Launchpad developers back when it was a for-pay development package.  Even though it was for-pay, it was very open source style based.
• Typically if you are very passionate about something (like programming) it’s hard to make a living at it because you enjoy it too much.
• Persistence
• There’s no substitute for being careful and doing really good work.
• The most accomplished people need around ten years of “deliberate practice” before becoming world-class.  This is also known as the ten-year rule.
• Identify a specific skill that needs improvement.
• Devise (or learn from a teacher) a focused exercise – designed to improve the skill.
• Practice repeatedly.
• Obtain immediate feedback – adjust accordingly.
• Focus on pushing the limits – expect repeated failures
• Practice regularly & intensely – perhaps 3 hours a day.
• Open source development is a good way to learn – you generally have a teacher, are challenged, get immediate feedback, and dedication to the project.
• Improvement kata
• Visualize perfection – visualize what the ideal world is
• Have a first hand grasp of the situation – understand how you can improve the situation
• Realize that there’s a huge gap between the first 2 steps – find the minor steps inbetween the 2 points
• understand obstacles that come up between the minor steps and overcome them.
• Dijkstra’s Challenge
• If you want more effective programmers, you will discover that they should not waste their time debugging – they should not introduce bugs to start with.
• Find as many bugs early so the “code freeze” phase can be brought down to less than 10% of the release cycle.  Typical is around 30% of the cycle, sometimes 50%.
• Pride
• Story about a philosopher asking 3 stone cutters what they were doing.  “I’m cutting stones”, “I’m earning a living”, and “I’m building a cathedral”.
• Move responsibility and decision-making to lowest possible level. 
• “If you’re a manager, your job is to be lazy.  Have those lower than you helping drive decisions”
• Litmus test for those with pride: how do people handle their frustration with their job? Do nothing, complain about it but overall do nothing, or find a way to fix it.
• Profit
• The examples given are large companies, consistently profitable, they dominate their industry and for a long time.  The front-line people are highly valued, expected to make local decisions and effectively engaged in delivering superior customer outcomes.
• Talked about Tandberg’s successful implementation of Lean
• Talked with really individual, front-line workers
• The workers knew by heart the 1-line pitch of company for what the company’s purpose was.
• The workers also knew exactly why they were doing their job.  They were passionate about what they did because they knew why they’re job was in place.
• http://www.pvv.org/~oma/SoftwareDevelopmentAtTandberg_March2009.pdf

Overall really great information presented.  If you ever have the chance to listen to Mary give a presentation, don’t miss out.

Codemash Pre-compiler: Software Craftsmanship

This was presented by Steve Smith (@ardalis | Codeproject.com) and Brendan Enrick (@brendoneus | NimblePros.com).

• What is It?
  • Software Craftsmanship Manifesto ()
• Why practice?
  • Basically it’s like Microsoft Certification tests; memorize the techniques so that when it’s time to solve a problem, you have a number of techniques you know like the back of your hand rather than having to look it up each time.
  • Using Kata’s helps for improving your “muscle” memory when it comes to tackling similar problems.
  • If you’ve already explored the problem domain using one approach (strictly OO using .NET 2.0 way), you should already have the unit tests that, in theory, can be used when you rework them in the underlying logic (using LINQ).

Kata’s practiced:

• Bowling game (as Uncle Bob has tackled the kata).
  • the TDD approach that Uncle Bob took to tackle the problem
  • Took an approach with Mike Letterle that might have been a little more complicated than it needed to be, but was a good exercise in thinking it through.
• A grocery shopping register.
  • having to account for discounts like “Buy N and get the N+1^th free” and “Buy N for $M”.
• FizzBuzz

Overall it was a cool session, but more for talking with developers outside my normal circle and getting a different point of view in how to architect the code.  It was great taking a TDD approach to tackling these kata’s though.  Especially pairing with a Java developer on the Grocery store kata.  Kind of wish I would have gone to a different session to actually learn more content as I’m thinking I’ll probably end up in the coding room one of the days to pair with people just to learn more from them and to actually be able to do some pair programming as it’s such a foreign concept every place I’ve worked.  It’s amazing how much it helps to be able to think through the implications of a certain architecture before ever actually laying out the code.  Although if you have two developers that over think the  problem it can lead to issues.  Amazingly I was able to no do that at all today and instead focused on “this is what’s being asked for, so let’s actually deliver that”.

Codemash Pre-compiler: Software Engineering Fundamentals Workshop: OOP, SOLID, and More

It’s that time for Codemash again.  So I’ll be doing some stream of conscious type blog posts again.  If others find this information kind of interesting I’ll expand on it some more, but mostly it’s for my own recollection.  The first session I attended during the pre-compiler was “Software Engineering Fundamentals Workshop: OOP, SOLID, and More” presented by Jon Kruger.  He kindly has the slides up at http://jonkruger.com/solid/OOP-SOLID-CodeMash.pptx.  Some of the points of his presentation:

* Started out talking about OOP.  Good analogy between Legos and code.  Glued together Lego pieces are like tightly coupled code.

* “Just because you are using an OO language does not mean that you are doing object-oriented programming.”

* “Avoid Not-Invented-Here syndrome”.  Promote reuse of objects, not just methods. And not via copy-and-paste.

* Great example of Encapsulation –> home electrical wiring.  You have abstraction/interface on top of abstraction/interface on top of abstraction/interface.  You only need to know what’s under the hood if you really HAVE to, otherwise go with the easiest interface.

* Object-orient programming is about behavior, not just fields.  Encapsulation is about hiding the fields and the only interaction is via behaviors.

* Rethink about object Inheritence by using composition.  It helps break down large methods.  It’s like going to a grocery store to choose what food is available to you vs. being a farmer and tied to what food you grow.

* Easier programming does not mean you shouldn’t learn new techniques/programming languages/etc.  It’s sometimes FAR easier to learn something new to help you out overall.

* The SOLID talk is very similar to what I presented to the ALL.NET group awhile back, but focused more on “Don’t do something that you really don’t need to do because it doesn’t fit your situation” and “Think before you implement.”

I have to give kudos to Jon for integrating the pairing session into the session.  It was a great opportunity to take an existing (crappy) application and refactor it using the techniques he had just presented.  I paired with Curtis Mitchell which was a great time, despite the fact we didn’t get a chance to dig too far into actually fix much of the code.