Friday, October 05, 2007

SubSonic Gives Us Migrations

SubSonic, a dead-simple code-generator / ActiveRecord ORM tool, is about to release a kick-ass new feature.  Migrations are an awesome tool that exists in Rails, but we haven't had a solid .NET equivalent yet.  I hope that SubSonic Migrations will live up to the hype.

I've blogged about the need for this before.  I've been wanting to use VSTS DB Pro in this way, but the tool just isn't meant to provide evolutionary db support.

My current project relies on SubSonic for the code-generation, but our database development is done through DB Pro.  I think this is a great tool, but I fear that it's really missing something.  I'm sure the next version will be much better, as is generally true with Microsoft products.  1st versions often take some time to meld, get some good feedback from the general public, and get the usage stories streamlined.

I may be able to take advantage of Migrations, however the DB Project needs to contain all scripts (and they have to be named according to the client's standards).  I wonder if I could create the migrations, execute them, then use sonic.exe to generate the scripts that represent the changes.  I could dump this script in the database project (or import it).

Right now it seems like a Rube-Goldbergian mess.  Any thoughts, ideas, suggestions?

Thursday, October 04, 2007

See you at ALT.NET

Get ready folks.  History is in the making.  The Earth will shatter.  People will be enlightened.  The sky will rain candy...

Ok, I'll stop now.

As you can see I'm really excited about the ALT.NET Conference going on this weekend.  I'm especially looking forward to (finally) meeting:
Sadly, I won't be able to meet Ayende Rahien as he won't be able to make it.  I'm really bummed about that.  Also, there are a ton of folks I've met before that I'm eager to catch up with.  And, of course, I'm really interested in meeting NEW people!  It's amazing the amount of excitement and vigor around this community.

I'll be driving in tomorrow night and should arrive around 8pm, so if you want to meet up for dinner/drinks (or if there is something official going on at that time) then drop me a line at ben {at} scheirman {dot} com.

I'm bringing my wife, however she's not so interested in the ALT.NET stuff.  She's more interested in hanging out, having fun, and (probably) shopping.  Maybe I can get her to attend 1 session, who knows.  Maybe we can get her to stop teaching Spanish and start programming.

See you in Austin!

Tuesday, October 02, 2007

Replacing Notepad with Notepad2 on Vista

I hadn’t ever gotten around to replacing Notepad with the most-excellent Notepad2 until today and realized that the method outlined in my older post doesn’t work in Windows Vista due to heightened security.

To replace it on Vista, follow these steps:

  1. Download Notepad2 and put it in a folder somewhere like C:\tools\Notepad2
  2. In Windows Explorer, navigate to C:\Windows\System32
  3. Right-click on notepad.exe and go to Properties
  4. Under the security tab, click Advanced.
  5. Change the owner to MACHINE\Administrators
  6. Close and re-open the properties box.
  7. Go back to the security tab and click “Edit”
  8. Give the Administrators group Full Control over the file.
  9. Now go to a command prompt and type this:
    copy c:\windows\system32\notepad.exe c:\windows\system32\notepad.exe.old
    copy c:\tools\notepad2\notepad2.exe c:\windows\system32\notepad.exe

Voila!  Now you should be back in business.

Now I’m back to wondering why they didn’t just make Notepad better in the first place…

Monday, October 01, 2007

Don't Make Squirrel Burgers

Your manager comes to you and says “Hey, Joe.  Let’s talk.  I need to get a new system developed to keep track of our help desk calls.  It needs to have a slick user-interface that is easy to navigate, it needs to be fast, and also we need integration with SAP.”  You ponder what the system architecture might be like.  He continues.  “So how long do you think this will take?”

Of course, your first instinct is to tell your manager that you’ll get back to him later with a rough estimate, but he is in a hurry and persistent.  You cave in and tell him, “I think it would take 6 weeks.”

“Hrm, 6 weeks?  I really need it in 5 weeks, no later.”

Your manager is already negotiating your rough estimate.  Be afraid.  You start to figure out how you can accomplish all of this in 5 weeks and you are realizing that you really needed eight weeks, not six.  Let me put this story on pause while I tell you another story…

Bob is the new night manager at FatBurger.  One night a man walks in and requests a double Fat-burger with cheese, a large order of Fat Fries, and a chocolate shake.  He pulls out the change in his pocket and Bob finds out that he only has $1.20.  The entire meal costs $7.50.

What would you do in this situation?  Turn away your only customer in the 11:00pm hour?  Offer something that he can afford?  Give it to him for $1.20 this time only?

Bob, being a proud night manager, wants to satisfy his customer.  He cannot give away the food cheaply because then the guy will return again, expecting another discount.  So Bob decides to get creative.  He goes around back and finds a dead squirrel on the pavement.  He scrapes it up with a shovel and brings it inside, grills it up and gives it to the man.

In this story, Bob sacrified quality to give the gentleman what he wanted for only $1.20.

Stop me if this scenario sounds familiar.

Back at your desk, you are realizing that you are about to deliver to your manager a squirrel-burger.  He wants X features, but you can’t deliver them on time.  The first thing you are going to throw out are automated tests.  Then you’ll stop refactoring.  Pretty soon you are just heads-down coding like you did in high school and you are making a huge mess.

Two things are likely to happen.  The system will buckle under its own weight because the code reaks of dead squirrels.  The other thing that is likely to happen is that your system becomes useful, and now management has another request.

“Hey Joe.  The new system rocks!  I just got off the phone with marketing and they want to start selling this to our larger clients.”

Now you’re in a pickle.  You have a spaghetti-mess of a system and now you need to extend it and polish it for redistribution. 

This sad state of affairs is all too common.  Your manager might want a double Fat burger with cheese in 5–weeks, but what he’s getting is a squirrel burger.  Don’t deliver squirrel burgers.  Be careful with off-the-cuff estimates that end up turning into negotiations.  Joe should have negotiated features instead of quality to meet his 5–week deadline.  Estimates should include time for automated tests and refactoring because it is part of your daily coding activity and it helps maintain quality.

I first heard the term “squirrel burgers” and the above story from Mark Pushinsky.

Tuesday, September 25, 2007

Adopting Agile Slides

Agile Houston tonight was a pretty good turn out. There were over 30 people, so it was a good number to get people talking.  If you came, I’d love to hear your feedback in the comments!

I was able to talk to a number of agile folks from Houston and it’s really cool to see this type of enthusiasm at a local level.

You can download the slides here.

(Matt recorded the whole thing, so if I can get the audio bits I’ll post those as well).

Adopting Agile @ Agile Houston Tonight

I’m speaking on Adopting Agile at the Agile Houston meeting tonight.  The meeting will be held at PROS Revenue Management downtown on Main street.  Check out the agile houston website for more details.

Hope to see you there!

Sunday, September 23, 2007

Certified ScrumMaster Training - Day 2

Day 2 of the class went right into it and had a lot of good, hands-on excercises.  Here are some notes from the day:

Team

  • Includes everyone required to deliver the “slice of the pie”  (the functionality for the sprint)
  • Extended teams are teams that you have to interface with to deliver your software.  Peripheral teams may be doing waterfall and include vendor and/or teams external to the company.
  • The core team should all be co-located, and shouldn’t be interrupted during a sprint
  • All teams go through the forming, storming, norming, and performing phase… even teams built with experienced scrum members.  Team dynamics are always different.  Mark (the trainer) wanted to stress that there is an additional phase here called “Adjourning.”  This implies that you have to let go of your previous team if it’s not bringing value.  Don’t do things a certain way just because “that’s how we did it last time.”
  • Good Scrum Coaches address problems by holding up a mirror rather than a stick.  Get the team talking and let them come to a solution.  Good coaches know how to set things up to get them talking and then shutup.
  • Recommended books:  Project Retrospectives by Norman Kerth, and Agile Retrospectives by Esther Derby, Diana Larsen, and Ken Schwaber.
  • Role of Managers often comes into question in Scrum.  Are they pigs or chickens?
    • Most of the time chickens
    • sometimes the product owner / customer, but depends on the project
    • Managers still have forsight of team impediments, so they can be very valuable.
    • Managers help the ScrumMaster remove impediments to the team
  • Scrum scales via Scrum of Scrums
    • 1–2 Members from each team are part of Scrum of Scrums.  Important to get the right people in the room (need problem solvers and cross-functional SMEs)
    • goal is to re-sync team efforts, share impediments (find common ones)
    • helpful to have someone of VP level present so that common impediments can be taken care of quickly
    • “Distributed teams are hard.  Period.  Scrum doesn’t make them any easier.”
  • Distributed Teams
    • NEVER as productive as co-located teams.
    • 90% of communication is non-verbal so stand-ups over the phone are hard
    • Effective distributed teams START co-located, then distribute.
    • Spend the investment to bring people together or “accept it and have bad teams.”
    • The best distributed Scrum teams share a product backlog and task list (via tools or Spreadsheet) so that they still feel part of the same team.
  • User stories
    • Stories are not contracts.
    • Rather they are a placeholder for future conversation
    • Stories are not Requirements!  Requirements are meant for defined system behavior for contractual purposes and not business-user friendly.  User strories are meant so that business users understand them.
    • INVEST in good user stories that are
      • Independent
      • Negotiable
      • Valuable
      • Estimatable
      • Small
      • Testable
    • Stories can be large at first (called Epics) then are broken down into (Themes), then finally into stories. Epics or themes never make it into the sprint, so break them down as soon as you can.
    • Purpose of stories:  (3 C’s)
      • Card
      • Conversation
      • Confirmation
  • Estimating
    • Use story points (or gummi bears… whatever) rather than hours.  Hours decay.  You don’t want to have to re-estimate because your initial estimates were wrong.  If you estimate that you can accomplish 24 story points and you only get 18, then you can only count on getting 18 the next sprint.  If you estimate a task at 4 hours and it takes 8, then what about the other 4 hours tasks on the board?
    • Planning accuracy
      • 20% of the efforts gives you 80% of the benefit
      • Planning beyond that yields little return
      • “Plans are useless. Planning is everything.” – Eisenhower.

The course was AWESOME and I strongly encourage others to take the course if you are interested in agile/scrum.

Afterwards we took Mark Pushinsky and Kert Peterson out to dinner and shared some stories and laughs.  I hope to see these guys again in the future.

(oh yeah, and Jimmy and I worked on something super secretive during our free time on this trip… more on that later on)

Thursday, September 20, 2007

Certified ScrumMaster Training - Day 1

So my buddy Jimmy and I are in Austin right now taking a Certified ScrumMaster course by Mark Pushinksy. 

I’m ecstatic to be earning this certification, and while I won’t be getting a “Get out of my way, I’m a ScrumMaster” T-Shirt, I am getting incredibly valuable, practical Scrum training from two experts.

Excellent Quotes from today:

Mark (trainer):  So what do you see in the Waterfall model that you don’t see in the agile model?
Guy: You mean “Waterfail” ??

 

Mark (acting as a troubled PM who hasn’t seen any results in 7 months):  Well, I need ALL of those features.  They are all important.
Jeff Palermo:  What if I told you that your budget was reduced to 1/10th of what it is now.  What would be  most important then?
Mark:  Umm, well all that is important.  I need it ALL.
Jeff Palermo:  Ok, so if I could give you something in 30 days, what would you like to see first?
Mark:  You can give me something in 30 days?!?!?!

This dialog was very valuable to me.

Mark:  You can’t heal, what you can’t feel.  (not going to sell agile if they aren’t already feeling pain with current process)


 

Here are some notable points:

  • If you tell a customer that it’s going to take 12–18 months to deliver his software, what kind of features do you think he’s going to ask for?  He’s going to think “Well if I’m not going to get it for over a year, I better get the everything and the kitchen sink!”  Contrast this with telling the customer that you can deliver in 30 days, what is most important?
  • Scrum demands transparency on the project.  Why would some people resist this?  Lack of trust, Fear of failure (or appearing as a failure).
  • Shu, Ha, Ri (martial arts terms — Learning the Rules, Applying the Rules, Adapting and Combining the Rules)
  • Waterfall separation of analyst, architects, developers, testers breeds lack of trust.  In the extremem these groups become “enemies” — Ever heard “ Oh if we ever got good requirements we could deliver”  — or “the developers are delivering tons of bugs to us!  What are they doing?!?!”
  • Agile/Iterative teams self-organize and fill needed roles to meet the sprint goal – this fosters trust between team members
  • The class had some trinkets and creativity toys which I thought was a nice touch to break the monotony of sitting in the same place for a long time
  • There were many hands on activities, many requiring us to stand up.  These were awesome!
  • Think of scrum as a snowman.  The head is the daily activity (24 hrs), the middle section is the sprint (2–4 weeks) and the base is the release plan (3–6 months)
  • Don’t make squirrel burgers (don’t deliver software that is low quality.  Low quality means sloppy code, no unit tests, any corner-cutting.)

Role of Scrum Master

  • Remove barriers
  • Increase transparency
  • Help Customer/Product Owner realize ROI by prioritizing product backlog
  • Educating those involved about scrum rules
  • (Silent) leader / facilitator
  • Improving engineering practices to meeting shippable goal at end of sprint
  • empower team to make decisions and get stuff done (self organize)
  • look for “coachable moments”

More to come tomorrow…

Tags:
Vegas Hotel - Loans - United Specialties - Credit Card Consolidation