Weekly Nuggets - 9/16/05-9/30/05

(Two weeks worth to make up for the trip to D.C. Speaking of travelling - I'll be in Vegas October 10th-14th if anyone wants to get together)

• "Some of the world's greatest feats were accomplished by people not smart enough to know they were impossible."(Doug Larson)


• "People who have the ability gain buy-in aren't the ones looking for solutions to their buy-in problems though. That isn't to say that people can't learn to be more effective leaders (quite the contrary), but at some level all efforts at building teams (which are groups where leadership is shared among a group with a common goal) -- including XP, Agile, Sociocracy, etc -- boil down, to basics like: Communication, Honesty, Compassion, Trust, Integrity, etc. People get buy-in because they both have a good idea *and* they are able to get others to see its a good idea. Some people get traction without the first bit (sometimes for quite a while) but in the long-run you need both."(William Caputo)


• "If there's only one answer, then this must not be a very interesting topic."(Ron Jeffries)


• "I used to have a rule called "Rule 38". The text of the rule is "Trust your I/O". The meaning is that it's not easy to beat the built-in I/O subsystem (though it can be done)."(Ron Jeffries)


• "hadzramin wrote:
  
  >> Any suggestions on good code analysis tools?
  >>
  >> I am evaluating FxCop, but it can only check assemblies and not inside
  >> source codes.
  
  How are pair programming and relentless testing working out?" (Phlip)


• "I'm thinking the naive programmer is either going to have to learn to be clever or wait for Continuous Integration for Game Development (for Dummies)."(Jason Che-han Yip)


• "There is no dishonor in being a great garbage collector. None." (Ron Jeffries)


• "changing practices is far easier than changing perspectives" (Lean or Sigma? (PDF))


• "People who do "one delivery at the end of the project" methodologies _talk_ about maintainability, but their stuff isn't very maintainable because they never tested for it - by trying to maintain the code base they were developing. Agile is intrinsically maintainable because that's all you do: maintain it." (John Roth)


• "Last iteration we had a record-breaking hurricane. This iteration, we had a record-breaking hurricane. Next iteration we will haaave....?" (Phlip)

Charlotte Extreme Programming Group

Well, I was tired of wondering if anyone else in Charlotte was doing XP, and since it looks like the XPDay conference helped push our company in that direction, I've started up a Charlotte XP group. Hang on to your hats - I'm going to light an XP fire yet around here!

XP Day 2005 - Washington, D.C.

(Edit: Corrected the name of the conference and the organizers of the event, thanks to J.B.'s feedback. Sorry!)

Today was XP Day DC 2005. We're on the plane back right now, and I wanted to recap my thoughts on it while I've still got it fresh in my mind.

The conference, put together by Diaspar Software and Digital Focus, was held in Washington D.C. at Digital Focus' offices. The morning started off with breakfast and a keynote address by Bill Wake. In it, he discussed the role and importance of the customer on an XP team. This is, of course, an often misunderstood and underappreciated role. Bill, armed with only a marker and a big notepad, walked us through the different customer concepts like their value. My favorite quote of the conference came during this when Bill was talking about bug fixes. He said you do your release after the bug fix and your customer says, "Hey, works like it was supposed to last time!" Good stuff.

The conference was split into three tracks. The first was a set of tutorials on XP which Chris and I attended. The second was a code room where a small project was being developed XP-style, and particpants could grab a story, a pair, and a desk and get cracking. The third was Open Spaces, a collaborative environment where people posted various topics they wanted to discuss, and people signed up, and away they went. Although we didn't go to any of the Open Spaces, it turned out to be very valuable for some of the participants trying to hash out how to make sense of XP when dealing with Federal Government projects. I didn't get the number of people there who did work for the Feds - you'd think we were in the Capitol or something. ;)

As I said, Chris and I attended the two morning tutorials. The first was an Intro to XP by J.B. Rainsberger. It was incredible. Rather than approach it from the "Here are the 12 rules, now do them", he came at us from the theory of constraints angle and compared software development to the manufacturing process where it belongs instead of building a house which we often see as a comparison. I am still taking in everything from that tutorial and think I am going to have to write just on that here soon.

To give you an idea, after that presentation Chris told me it was worth the cost just to hear that tutorial. Great job J.B.!

Second up was Jeff Nielsen, Chief Scientist for Digital Focus. The tutorial was titled to be about writing Business Rules as Tests, but mostly was a FIT introduction. And a darn good one at that. I had heard a lot about FIT, but haven't had a chance to play with it. His presentation was great as well - although I wish we wouldn't have had so many questions.

Afterwards we broke for lunch. We sat at a table with several people including some Digital Focus people and learned some great stuff about the company. I also learned that not one but two people at the table knew where Lutz, FL was! (Hi Paul and Michelle!)

After lunch, Chris and I decided to jump into the Code Room, not seeing any topics we wanted to join in Open Spaces. This turned out to be great, because Jeff came in and grabbed a story to write the FIT tests for a particular feature and I jumped in as his pair. I learned more about FIT in that one hour pairing session then I think I would have in the next three weeks. Jeff is a great developer, although it was great to see someone having problems in Eclipse because they had been doing too much .NET programming and their Emacs bindings kept getting in the way. (Long live VI!)

We loved their project room. I got a couple of pictures (1,2,3). And it was a great madhouse in there with probably 15 or 20 people all working together greatly emphasizing the Expert-In-Earshot pattern. A couple of people had been assigned as customers, which was great because when we encountered a problem we could just ask.

The interesting thing was how quickly we were able to get it up and running. The project was a book review web site. We were tasked with writing the FIT tests to implement a feature where the book description and review were checked for a defined list of prohibited words. Sounds simple enough, but it turned out to involve taking the list of words, tokenizing the description string and comparing word by word to the prohibited words list. Even then, we knew that it wasn't going to be perfect. You can write foo (one of our sample words) a lot of different ways! foo, Foo, FOO, F00, F0o, F@0, FO@, "FOO", F'o'o - the list goes on and on. We just limited the scope and made a mental note that the descriptions will probably have to be manully checked or have some other form of feedback if this were a real delivered project.

The day finished up (for us) with the client panel. Digital Focus brought in three of their customers who had implemented XP with Digital Focus' help. All of them had previously used waterfall processes, and all three now embraced XP. One thing I wished was that they had discussed a project which didn't have great champions, or whose champion didn't have the clout to push XP into the organization, and how they dealt with that.

We had to leave early to catch the flight back. Fly in, attend, Fly out. Oh yeah.

But, I thought overall the conference was great. And the one day format I think works really, really well. The focus was on the right people - the players who need to figure out what this XP thing is and how it works in their shop, while still providing plenty for the programmer-types to do without hacking around on the wireless network. I hope that they continue to do more of these - I think it would be a great way to get people introduced to XP quickly. And with speakers like J.B. and knowledge like Jeff you can have a great impact.

Thanks again to Digital Focus and Diaspar Software for hosting the event. I had a great time, learned a lot, and can't wait to do it again soon!

Test Driving UIs / MVP Part 2 - User Stories

In Part 1 I discussed a hypothetical realty company who needs a new application for their business. They've decided to go ahead with the app, and so we are about ready to start development.

With the general requirements in hand, we work with the customers to create user stories for their application. We get the following from each customer, listed in initial priority order:

• John Roberts (Dial-Up)
  
  
  
  1. I search for a property and get listings back.
  
  
  2. I search within a list of properties to get more targetted results.
  
  
  3. I click on a property and see all the details we have on it
  
  
  4. I can mark properties and see a comparison of them
  
  
  
  


• Susan Stern (Blackberry)
  
  
  
  1. I type in a street name and/or zip+4 code and get a list of properties.
  
  
  2. I select a property to find out more information like number of bedrooms. (I don't have to select to find out the address or price.)
  
  
  3. I select a property and get driving directions.
  
  
  
  


• David Craig (Laptop/ Wireless)
  
  
  
  1. I enter an address, price range and/or other criteria and see a list of properties.
  
  
  2. I narrow down a list by entering more criteria.
  
  
  3. I access the list from any computer
  
  
  4. I get an email alert when new properties are available
  
  
  5. I get driving directions to the properties
  
  
  
  

While I know I'd like to write acceptance tests for these, I'm not sure how to go about that. In lieu of that, we create some mock-up screens for each section. So far we know we have three seperate UI pieces: a Web, a WAP and a Desktop Application. We could do a Java app for the Blackberry, however the indication is that not everyone who is mobile uses Blackberries, nor Java enabled phones, and they want something that will work regardless of phone type. We explain that they will have to have a data access plan for their phones, and they agree to it.

The screens mocks are very basic. The Web and Desktop apps have fields for all search criteria: Area, Zip Code, Address, Price Range, Number of Bedrooms, Square Footage, Lot Size. They both bring back a listing of properties 10 to a page that includes the picture and all criteria. No clicking through will be necessary, though a link is sketched that will take them to theoretical driving directions.

The mobile app allows for entering street number, street name, street type, zip code (+4) and price range. Street Type is a drop down list. All fields are optional except zip code. When the user submits, it returns a listing of properties with the price and address ordered by street name. It shows 10 to a page, and the user can page through the listings. They can also click a property and bring up an information page including a link to the hypothetical driving directions.

After working with XYZ to create these documents we put some estimates on the table, with the total coming in at two months. They decide to cut the comparison screens for now, and the email alerts will be handled by their existing DBA who will add a trigger to their SQL database, which cuts back the estimate to six weeks. We also add some additional background stories:

• Unauthorized users are not able to access the application


• A user logs in succesfully and is brought to the search page


• A user forgets their password and clicks on the Password Reminder link

With that behind us and with approval from the client, we take a look at the app as a whole. We lay out the stories and estimates and come up with the following release schedule:

• Week 1: View a list of properties based on search criteria via a web page


• Week 2: Search and view properties on a desktop app based on a static database


• Week 3: User security and driving directions enabled for web and desktop, desktop app gets latest database on startup or sync


• Week 4: Search and view properties on a WAP simulator


• Week 5: Security, driving directions and search enabled on WAP phones


• Week 6: User Acceptance

Though ambitious, the team feels like it is doable based on their previous experience with web and mobile apps. They feel like they will be able to reuse a lot of the code between the versions to help speed development along, creating a pluggable presentation layer. What do you think? Do you think they can make it?

Weekly Nuggets - 9/9/05-9/16/05

• "That was back when I thought simple rules sufficed."(Kent Beck)


• "Take "test before code", for example. It's a nice simple rule. However, in practice I find that sometimes I just can't think of how to test, so I code anyway. Often I discover I really could have tested but I didn't realize it until later. So my rule isn't really "test before code" but "test before code as long as I can figure out how to test and when I can't I spend some extra time thinking about how to test except not too much time which depends on what else is going on and then when I'm done I think about how I could have tested or how I could have tested better". I'm sure if I thought about it a while I could add a few more provisos too." (Kent Beck)


• "It's design philosophy is different from more mainstream languages like Java and C#. Smalltalk is about empowering the individual programmer, rather than limiting the damage he can do." (Colin Putney)


• "We don't go on the air because we're ready, we go on the air because it is 11:30" (Lorne Michaels)


• "My job is to deliver value and it turns out that the kind of value I deliver is more like ice cream than money. You know: you can never have too much money ( or get it too fast ) but there's a limit on how much ice cream you can take in one sitting." (Charlie Poole)


• "I am that guy. I'm learning. If you're interested in long-term investment, then let me learn; and if you're not, rein me in." (J.B. Rainsberger)

EJB 3.0, XMLBeans, and other CharJUG Goodness

Last night was our monthly CharJUG meeting. Patrick Linskey from SolarMetric (and Bitter EJB fame) came down and talked with us about the new EJB 3.0 spec.

For those of you who have shunned EJB's before, this is definately something you might want to check out. The EJB team was tasked, among other things, with making EJB easier to use, and more testable. And from what I saw last night, it looks pretty close to that goal. Not only is everything an interface (like Query, EntityManager, EntityManagerFactory, etc), but they increased the dependency injection points, and allow you to run it outside of a container. So some very cool stuff when that comes out. I also got a good taste of a lot of the new Java 1.5 language features like annotations and the new foreach operator. Makes me wish we were doing more Java stuff at work.

Speaking of, after the meeting we went out to a local tavern and had some good discussions on different technologies, including several parts where the group picked on me for our company moving to .NET. We still do some J2ME, but most of what we do nowadays is C#. The funny thing is that some of my time is tasked to make .NET more Java like through things like NUnit, CruiseControl.NET, NAnt, and NHibernate. Yep, most of the good familiar Java tools have .NET equivalents.

Some of the other topics were actually on UI stuff. Patrick mentioned a project he did where the UI interfaced with the domain objects via XML. But not by having each domain object serialize themselves into a Document. Basically they had a framework that knew how to take an XPath Query and get information out of objects based on that. It's an interesting notion, and one I want to look more at. He said that XMLBeans are doing something similar, but with some restrictions on the objects, and that he really believes those restrictions could go away with enough demand.

All in all a great meeting, and sorry to anyone who didn't make it out. The next one probably won't be until February - we are moving offices next month, and then you have the holidays. But a big thanks to Patrick for coming out, and all the CharJUGgers.

Test-Driving Development with VS2005

(Edit: Sorry for the misleading title. Indeed, this is more of an introduction to unit testing in 2005 then actual TDDing in it - Cory)

Over the weekend I got VS2005 beta installed on a virtual PC. While I know there have been a lot of changes to the IDE, I was most interested in the Testing features that were added to it. Here are some first impressions.

First, I fired up the IDE. I noticed that when I went to create a new Solution, I had the option of creating a Test Project:



Since I don't normally start my projects, I filed that away. I decided to start with a Windows Application. After I created the solution, I added a Test Project to it, and ended up with something like:



After adding the Test Project, something really interesting happened. An AuthoringTests.txt file popped up, and it had instructions for how to get the tests up and running. About a minute later I had my first test written, which is the first test I usually use in my NUnit methods:

[TestMethod]
public void TestMethod1()
{
  Assert.IsTrue(true, "This Works");
}

I noticed they also provide Initialize() and Cleanup() methods (tagged by the custom attributes [TestInitialize()] and [TestCleanup()] respectively). So it looked something like:



Great! Now how do I run it? The AuthoringTests readme said that tests could be run from the Test View window and the Test Manager window. Great. Where the heck is that? Ooh shiny new Test Menu option!



Zipping down to the Manage and Execute Tests option pulls up the Test Manager. From there, I was able to click on Run Tests, and get my first Green Bar (sorta)!

Test Manager:


First Results:


So I guess Green Checkies will have to do.

All in all, not a bad first start. The tests seem to take a little while to compile, but I am running it in a Virtual PC giving it 512MB of RAM, and it is Beta, so both of those together I'm sure have something to do with it. It was exciting seeing the work that went into it, going so far as to provide the AuthoringTests instructions. I don't think I'm quite ready to replace NUnit with it, but it's great to see some progress from Microsoft on the issue!

For those interested, according to the AuthoringTests.txt file, these are the Test Types you can create with Visual Studio Team Test:

Test Types
----------
Visual Studio Team Test allows you to create a number of different test types:

Generic test: A generic test is an existing program wrapped to function as a test in Visual Studio. Three examples of generic tests are the following:
- Wrap an existing test that adheres to the Visual Studio return-code interface.
- Wrap an existing test harness that adheres to the Visual Studio result-data interface.
- Wrap a general program to obtain specific functionality during a test scenario.

Manual test: The Manual Test type is used when the test tasks are to be completed by a test engineer as opposed to an automated script.

Ordered test: Use an ordered test to execute a set of tests in an order you specify.

Unit test: Use a unit test to create a programmatic test in C++, Visual C# or Visual Basic that exercises source code. A unit test calls the methods of a class, passing suitable parameters, and verifies that the returned value is what you expect.

Test-Driving UIs / MVP - Part 1

I've finally gotten together enough time to do some more work on TDDing User Interfaces and implementing the MVP pattern in .NET. As some of you know, I presented on a little bit of this at an MSDN Code Camp several months ago.

My flaw in that presentation was trying to cover too much ground. I tried to summarize everything from the Agile Manifesto to NUnit, NUnitAsp, TDD, TFUI, etc, etc. It was too much for a beginner crowd.

I promised myself I would come back around and do a fuller example from start to finish using TDD to generate a testable UI layer that also followed the MVP pattern. This afternoon I came up with an initial draft of the requirements.

So, first, the overall "hidden" goal is to end up with a testable UI/Presentation layer that allows different views to be plugged into it (including a Mock view). The views I'd like to see develop are thin wrappers around the UI specific code, and delegate immediately to the presentation logic. A good definition of MVP is available at Martin Fowler's site, and also can be found in the discussion of the Humble Dialog (PDF).

Now, our "real" story is as follows:

The XYZ Realty Corporation, a state-wide realty corporation serving residential customers, has been having problems providing a consistant way for their realtors to be able to find home listings. Each realtor has an office, but some offices only have dial-up internet connections. Some realtors have laptops with internet access. A few have mobile phones that have internet access, and want to be able to search for homes on the phones which will help them when they are in a given area with a customer and want to see what is available around them.

After an initial meeting with the realtors, the following features came up:

• Search by one or more of:
  
  
  
  • Area (Predefined based on geographical regions by the company)
  
  
  • Zip Code
  
  
  • Price Range
  
  
  • Number of Bedrooms
  
  
  • Square Footage
  
  
  • Lot Size
  
  
  
  


• The form should be available over the internet and on the phones.


• The offices without high-speed connections should be able to download the latest listings and run a desktop app to search them.


• The listings should be sortable by each of the criteria


• An agent should be able to select a property and get the details of it, including address and pictures (if available, and if the device supports it)

The realtors, while busy, have agreed to be available to answer any questions that come along. Three key realtors have been identified who are the primary contacts:

• John Roberts, a realtor for 17 years. His office is on dial-up


• Susan Stern, a realtor for 9 years who does just about everything on her Blackberry


• David Craig, a realtor for 11 years who uses his laptop for access. He generally meets customers at Starbucks or his office to go over properties.

The database is a Microsoft SQL Server and is already populated and updated based on MLS Data and a custom in-house software package which lets them flag that properties are under contract or sold.

The company has an in-house web server running IIS 6.0. They have agreed that they are willing to upgrade any equipment if necessary.

From this, I intend to build out the application in installments, letting you see the warts along the way. I also would love feedback on the process. If there are things you think I should do differently, or things I've missed, please don't hesitate to let me know.

Eschewing Fundamental Types

There is a very interesting conversation going on at the Test-Driven Development list about Eschewing Fundamental Types. Basically, how many times have you done:

public class Person
{
  //...
  public string FirstName
  {
    get{return firstName;}
  }

  public string LastName
  {
    get{return lastName;}
  }
}

and then how many times has the requirement changed so you have to provide a full name representation? Or Last, First? Or handle Maiden names?

John Roth got the ball rolling with:

It's that simple: the fundamental language types, and the basic language libraries, do not, and let me repeat that, do not represent any concepts that your application actually needs. At best they represent bizzare oversimplifications of those concepts that can't be told apart by the type checking mechanism.

It's a fascinating concept, and one that I was amazed how often I skipped over. If I see two properties with the same suffix, it often raises a flag that maybe they want to be their own class. But for some reason that same flag never gets raised with names and other fundamental properties of common classes.

So, the solution is to tweak your Spidey-Sense to recognize this duplication. In the above example, we would have:

public class Person
{
  public Name Name
  {
    get{return name;}
  }
}

public class Name
{
  public string FirstName
  {
    get{return firstName;}
  }

  public string LastName
  {
    get{return lastName;}
  }
}

Which allows us to grow the name class as our app wants it.

A counter-argument raised by Ron Jeffries was YAGNI. What story caused you to want Name to be a class? What duplication triggered the Extract Class refactoring?

I would argue that as soon as you ask for more than a simple name, (and maybe not until it's more than a first name and last name) that you should move it into a Name object. Moving it sooner could get you hitting against YAGNI.

I guess, like a lot of things, it comes down to experience and how badly your spidey-sense is tingling.

What do you all think?

Weekly Nuggets - 9/2/05-9/9/05

• "My favorite tdd life story is last fall when we were putting a large plastic sheet down on our porch (didn't have time to seal it), and I let my girlfriend work on it for a while. She had started by stapling one end down, then slowly moving down the porch, stapling each side. What ended up happening was that it was crooked, so it wasn't going to reach the other end straight. I stepped out, took a look, then tried to figure out how I could write a test for each step of the way. We already had some legacy sheet (I had just read Michael Feathers' excellent book), so I thought about how I could do a bit of safe refactoring to get some tests in place. I made a small slice in the plastic, so I could reposition it (refactoring), then stapled the far end down to the other side of the porch. At this point, I had a passing test (the sheet of plastic was laid down square across the porch), so I could go in and start adding additional staples along each side to finish it up. At each staple, I knew that I was still good, since my test (are all four corners stapled where they should be) was still passing.
  
  Yeah, we should have started with stapling the four corners, then we wouldn't have had the problem, but we didn't (should start all coding TDD, too, but it doesn't always happen that way). In the end, TDD saved the day. :)
  
  And, no, my girlfriend didn't want to hear the long explanation about how this is just like what I do at work every day with programming." (Corey Haines)


• "The greater the stress, the less likely that individuals can tolerate "ambiguity"." (Decision Making Under Stress)


• "You can observe a lot just by watchin'" (Yogi Berra)


• "When life is reduced to numbers, success is defined as bigger numbers." (Sharon Villines)


• "Basketball would be a whole different game without numbers. Probably more fun to play and less fun to watch. Autocrats may be watchers." (Sharon Villines)


• That's why I define "Agile" as ...
  
  
  • can accept feature requests in any order
  
  
  • can release any integration
  
  
  • minimize the time between specifying a feature and end user profiting from it
  
  (Phlip Plumlee)


• June Kim posted a thread about how they got their team to refactor a very ugly method that is a must read.


• Once when I interviewed at a company and it came time for the hiring manager to ask me if I had any questions I asked him "are you willing to fire people who suck?"(Jeffrey Fredrick)


• Continuous Integration is an Attitude, Not a Tool (Jim Shore)

Comparison of SQL Databases

Brady Gaster found an interesting comparison of the features of various databases, including MSSQL, PostgreSQL, DB2, MySQL and oracle. Pretty good stuff.

Taking things for granted

I just got back from a trip to South Florida. My wife and I are both from Tampa, and both of our families (and most of our friends) still live there, so we go down quite a bit. This trip I headed down with my brother and stepdad to my stepdad's girlfriend's family reunion in Everglades City. To give you an idea where that is, head South on 75 until you see a gigantic sign that says "No Services Next 50 miles". Go 20 miles past that, turn off on the exit that is in the middle of nowhere, go 20 miles down there (passing lots of "Panther Crossing" signs and not much else) and you'll get there. Our airboat guide on Saturday told us there are more gators between there and Miami then in the entire rest of the state. I saw just over 10 gators in the day and a half I was there, so I believe him.

But one of the most intereting moments didn't come on an Airboat, or fishing, it came walking from the room to the car. I had just showered, and walked out to get something from the car which was no more than 20 feet from the room. In the 45 seconds I was out there I got no less than 15 mosquito bites. Suddenly it made sense why there were gigantic bottles of Off around the room.

A similar situation happened to me recently on a project at work. I admit, I love small companies. There's something about being able to turn on a dime and wear lots of hats that I am a glutton for. I especially like this one because of the talent on our team. We've just got some good developers. Even the ones right out of school pick up quickly. So it was quite an astonishment a couple of weeks ago to find out that our boss was throwing all of our resources at this one project. This project had been in development for around 7 months or so, and it seemed to me like it was doing really well. And being that we as a team regularly talked about patterns and test-driven development and unit testing, I figured I knew what to expect when I saw it.

In both instances I made a mistake. I took for granted that situations would be a certain way. In the case of the Everglades, I took for granted mosquito control (those loud trucks that come buzzing by late at night). Without that, mosquitos run rampant. With the project, I took for granted that, in lieu of checking, a common pattern and code style would emerge, which could be tweaked if necessary.

It got me thinking about other things we take for granted. Like other developers having the drive to want to constantly improve. Some people are more than content to come to work, crank out whatever needs to be cranked out, and go home without thinking a second thought about it. Or good developers producting clean, well designed code. (To our team's defense, I have a better understanding of the pressures they were put under, and with that and only having two people, I would probably have ended up with a BBOM too).

So how do we deal with this? I mean, we have to take for granted /some/ things, or else we will have a hard time functioning. Like that our car will start, or that the fuelers know how much fuel to put in the plane. Or that when you call 911 someone will come quickly. But other times we get woken up by an assumption that comes back to bite us. And all we can do is work to correct that.

Luckily for me, I had brought a big bottle of Off, so I was able to enjoy the weekend down there (and catch some fish too!). And, just as great, I have a copy of Working Effectively with Legacy Code at my desk, a build server with CruiseControl.NET and NUnit, and an allowance of two hours a day to bring the project under test and refactored. It won't be as fun as doing it right the first time, but once the bites heal, and we get our safety net in place, we should be just fine. Now if I could just find my gator repellent...


(And if you haven't already, be sure to donate to the Red Cross or some other organization to help with relief efforts in New Orleans. It's a mess down there)

(P.S. I may not have made it clear, but, yes, our team *is* interested in making things better. And they are heckofa coders. They just got stuck with a bad situation of having too much to do and *way* to much pressure put on them with very little guidiance. Hopefully we can fix that)

Weekly Nuggets - 8/25/05-9/1/05

(Short list this week as I am heading down to South Florida in the morning. Have a safe Labor Day!)

• "My finest moment was estimating stories with a team in "number of tests". We took one iteration's worth of work, did a quick design by layer, then estimated the whole thing at about 275 programmer tests. We took the number of pairs, the available hours and the 2-week iteration length, divided by 275 and got a pace of one passing test every 45 minutes. That gave them confidence that they could do it. They did." (J.B. Rainsberger)


• "There's a little mantra I repeat to myself after changing existing code:
  "Is the code easier to understand now?"
  If the answer's no - I hit revert." (Adrian Howard)


• "Lifting a process used by a really good team and dropping it onto a lesser-skilled team isn't going to turn the second team into gurus. People matter more than process, tools, and techniques, therefore the second team isn't going to be as productive." (Robert Watkins)


• (Done before, but worth repeating)
  "If we're not shipping our software when it's ready,
  it's poor business practice.
  If we're not sure whether our software is ready,
  it's poor software practice." (Frequent Releases)


• "Growth is a false goal. Many companies try to get bigger or go faster instead of understanding how to adapt to change and get smarter." (Sharon Villines)