Search This Blog

Tuesday, December 15, 2009

Entity Framework POCO (EF4): A Simple Mapping

link -> Entity Framework POCO (EF4): A Simple Mapping

The latest EF4 CTP released on November 12th includes updated support for POCO’s (Plain Ol’ CLR Objects). Although we could use POCO’s in the previous CTP, we still had to create an EDMX artifact to model our entities, thus leading to a bit of duplication.

In this post I want to take a look a simple mapping scenario, and how that looks using the new ‘Code Only’ API. By using the code only API I can have complete control over my entities, giving me the most flexibility in my mapping strategies, better testability and extensibility, and ultimately greater maintainability. No generated code. No XML files. Sweet ;)

Tuesday, December 1, 2009

Thursday, November 12, 2009

NHibernate 3.0 QueryOver

link -> NHibernate 3.0 QueryOver

One of the personal reasons that I had for co-founding Guild 3 was for me to re-discover my passion for software. I was suffering from something similar to what Davy Brion (quite bravely) outlined in Avoiding (Or Recovering From) Burnout. For me the age old adage of “a change is as good as a rest” has proven to be an extremely successful strategy.

Sunday, November 8, 2009

Wednesday, November 4, 2009

Back on the rails

Wow the last three weeks have been hectic. We have been evaluating NHibernate plus I joined two book study groups and neither of them are about the book I am reading. Hopefully things have calmed down now and I get back to reading and posting about Collaboration Explained.

Tabaka writes:

You’ll know that you have seriously moved to a truly collaborative style of decision making when:

  • You value the opinions of the group more than your own.

  • You provide process guidance through positive encouragement instead of controlling dictatorship.

  • You provide your opinion only as an expert contributor and only with the permission of the group(more on this later).

  • You don’t use your opinion to sway the outcome of the meeting.

  • You enlist others to dog your neutrality and ensure it is engaged throughout the meeting.


I do value the opinions of my team and believe that they can make a better decision together than I can make by myself. I have worked hard on being neutral and giving my team the power to make decisions, but I really need to work on being positive and supportive.

I have been avoiding providing my opinion. I don't know how to give my opinion without making it sound like the final decision. The book says it will talk more about this later so I am hoping there is some advice in there that can help me. The idea of getting someone to dog my neutrality sounds interesting.

Sunday, October 25, 2009

First Impressions: TekPub

link -> First Impressions: TekPub

OK Folks. I don’t do endorsements. I especially dislike commercial / corporate training. The trainers aren’t really experts. They didn’t create this stuff. They don’t even use this stuff. They just *teach* this stuff – day after day, city after city. I can learn 95% of the material with my laptop and 15 minutes with the slide deck.

What’s the alternative?

Blogs? They’re fine for keeping up with trends and knowing what the cool kids are doing, but if you’re trying to learn something from scratch, you’ve got to dig for the good stuff. The worst part about web 2.0 is that any idiot can start a blog about stuff he doesn’t really understand – even me.

Books? While I could recommend a few, the honest truth is that I’ve had a dozen queued up on my bookshelf for nearly a year. Even if you do take the time to read, the information is out of date before the book even hits your shopping cart. On top of that, you have no guarantee that the author is really an expert.

Here’s something different.

TekPub_logo Rob Connery @robconery and James Avery @averyj started TekPub.com. That’s @tekpub on Twitter. It’s a library of professional screencast series by Rob, James, and other subject experts with names you’ll recognize. They’re not little 30 minute channel 9 interviews with obscure Microsoft PMs. First, the message is not corporate in any way, shape, or form. Second, the quality is amazing. The audio is clear. The text is crisp and easily readable. The images are both humorous and relevant to the topi

Saturday, October 24, 2009

A student-designed velomobile

link -> A student-designed velomobile
As you know, I like to share student designs from time to time. Joseph Campbell is a recent design graduate whose senior thesis project “dealt with bicycles and how they do not fit into Americas current grid”. As someone who has cycled for transportation for many years, I don’t completely agree with that statement, but I do see his point. There is much more that can be done both with infrastructure and with various types of pedal powered vehicle designs that can open human powered transportation options up to a larger segment of the population. I won’t discuss the inadequacies of our current transportation system in this post. Instead, I will share Joseph’s thoughts about the velomobile that he designed in his own words:

Thursday, October 22, 2009

Reading gets personal with Popular items and Personalized ranking

link -> Reading gets personal with Popular items and Personalized ranking

(Cross-posted with the Official Google Blog)

Today, we're launching two changes to Google Reader to help you discover more interesting content faster. Just as the launch of Personalized Search improved search results based on your search history, these changes use your Reader Trends to improve your reading experience.

  • Explore section - We're always trying to help you discover new stuff in Reader, and today we're introducing "Popular items" and "Recommended sources", two ways to find interesting content from all over the Internet. We use algorithms to find top-rising images, videos and pages from anywhere (not just your subscriptions), collect them in the new Popular items section and order them by what we think you'll like best. Now you don't have to be embarrassed about missing that hilarious video everyone is talking about — it should show up in your "Popular items" feed automatically. And to make it easier to find interesting feeds, we're moving recommendations into the new Explore section and giving it a new name — "Recommended sources." Like always, it uses your Reader Trends and Web History (if you're opted into Web History) to generate a list of feeds we think you might like.

    Explore section

Linq to NHibernate Progress Report

link -> Linq to NHibernate Progress Report

Monday, October 12, 2009

Blood Rivers and Stone Forests: 15 Alien Landscapes

link -> Blood Rivers and Stone Forests: 15 Alien Landscapes

Shared folders and multiple file upload in Google Docs

link -> Shared folders and multiple file upload in Google Docs

Characteristics of a Collaborative Team

Tabaka writes
a collaborative team holds the following set of characteristics:

  1. They are self-organizing versus role- or title-based in organization.

  2. Teams are empowered to make decisions versus being dictated to by an outside authority.

  3. Members truly believe that, as a team, they can solve any problem.

  4. Members are committed to success as a team versus success at any cost.

  5. Trust versus fear or anger motivates the team.

  6. They aggressively engage in participatory decision making versus bending to authoritarian decision making or succumbing to bullying for decisions.

  7. Decisions are consensus-driven versus leader-driven.

  8. Teams maintain an environment of constructive disagreement versus falling into damaging conflict or no conflict at all.


The other day my boss was asking me what the vision for my team would be. I think this is a very good start.

I just finished the "Why" section of Jean's book, and I am moving into the "How" section. I am very excited to try out her suggestions with my team.

Nature’s Art: Striped Icebergs & Frozen Waves of Antarctica

link -> Nature’s Art: Striped Icebergs & Frozen Waves of Antarctica

Sunday, October 11, 2009

DISC model of team roles

Jean Tabaka has an excellent explanation of the DISC model of team roles in her book Colloboration Explained. DISC is an acronym that stands for four different personality types

  • D: you can describe this person as demanding, forceful, egocentric, strong willed, driving, determined, ambitious, aggressive, and pioneering.

  • I: you can describe this person as convincing, magnetic, political, enthusiastic, persuasive, warm, demonstrative, trusting, and optimistic.

  • S: you can describe this person as calm, relaxed, patient, possessive, predictable, deliberate, stable, consistent, and tend to be unemotional and poker faced.

  • C: you can describe this person as careful, cautious, exacting, neat, systematic, diplomatic, accurate, and tactful.


Teams tend to be imbalanced if a majority of the people on the team have the same personality role. This imbalance happens frequently because people tend to gravitate towards like minded and like acting individuals.

Teams with too many "D" types tend to be very results-oriented, but they don't produce very high-quality work or very detail-oriented solutions. Decisions are made based on speed and who has the strongest or most dominating personality in the group. Team meetings are marked with frequent power struggles, grandstanding, and little collaborative output. These teams are constantly running as fast as they can, straight into brick walls and then on to the next great idea or initiative.

Teams with too many "I" types tend to enjoy debating and brainstorming but have trouble really making any productive progress. These teams are weighed down with endless design meetings and can't focus enough to fully understand the details of the software they are building.

Teams with too many "S" types tend to hyper aware of how everyone is feeling, but they take too long to come to decisions. In addition previous decisions can be retracted and revisited the next time the group meets because someone's opinion was not included.

Teams with too many "C" types tend to have trouble sticking to their decisions because their decisions never feel quite right. They spend too much time reworking solutions trying to handle all possible scenarios even if the scenarios were not requested by a customer. All of this rework results in missed deadlines.

The highest performing teams are the ones that are composed of all these personality types. These teams just need the right guidance to move from divergence to convergence.

Comic for October 11, 2009

link -> Comic for October 11, 2009

Tuesday, October 6, 2009

Rambling on Cyclomatic Complexity

link -> Rambling on Cyclomatic Complexity

Fundamental Cultures of Working Part 2

Last time I talked about the command and control culture, the next culture is competence. The downside of the competence culture is that if only a few of your employees are competent then what happens if one or more of those employees move on. Another downside is that if your employees are competing against each other it can be very difficult to get them to communicate and help each other.

The downside of the cultivating culture is that employees are mostly concerned with their own interests. Deliverables and deadlines are not high on the list of importance. Teamwork only happens if helps the individual.

The collaboration culture is about teamwork. Teams work together to come up with ideas and solve problems. The team utilizes the wisdom of all team members to make the best decisions.

The book talks about how a collaborative culture can build a sense of community where people are motivated to move past conflict into productivity, move past indecision into action, move past defensiveness into trust.

If you can't tell from reading my post so far, I am very biased towards a collaborative culture. The book says that if you want to have a collaborative culture then it is good for the manager to be passionate about collaboration.

The manager tries to build a highly integrated and self organizing team that can find its own path to success. The team should come to value participatory decision making, self-discipline, and self-organization.

To me this sounds like a big project to take on. I am excited to try it though. I believe the effort I put in will be worth the pay off and then some.

Monday, October 5, 2009

Fundamental Cultures of Working

Tabaka lists four fundamental cultures of working
Command-and-Control— The leader is in charge and makes decisions for the team to ensure tight authority and responsibility.

Competence— The team or project relies on the expert capabilities of the few to bring about success for the whole.

Collaboration— Decisions are consensus-driven, and the team works in partnership toward success.

Cultivating— Establishing personal and professional improvement for each team member is paramount.


The book mentions that some of the downsides of command and control are that the success of the project rests solely on the shoulders of the manager. In addition this culture ruins morale and reduces motivation and creativity.

Since I assumed the manager role on my team, I have had a couple people tell me that I need to take on more of a command and control approach. I am not sure yet that I want to do that. I am interested in reading more about these other approaches. I am glad I picked this book.

I will add some more comments about the other cultures next time.

Integrating StructureMap and NHibernate with WCF - Jimmy Bogard - Los Techies : Blogs about software and anything tech!

link -> Integrating StructureMap and NHibernate with WCF - Jimmy Bogard - Los Techies : Blogs about software and anything tech!
Los Techies - Code like a rabid donkey!

Thursday, October 1, 2009

How Ironic

My last post asked how can I help my team while not being the manager. Since my last post I got reassigned to be the project manager. Weird. I feel like should I title this post how can I help my team as the manager. :)

For starters I am dusting off this blog and starting a new book today called Collaboration Explained by Jean Tabaka.

I will try to post comments about the book as I read through it.

Thursday, September 17, 2009

Still forever changed

link -> Still forever changed
I finally took him out today, the 2004 Ibex Corrida "Luxe Tour" bike that I call Roadie. Our rides are few and far between these days. Today I pumped up the tires from 10 psi - that's how long he's been sitting. I'm generally just a phone call away from listing him in the freebie classified ads, but every time we go out for a ride, I can't remember what about him made me think he was such a junker. He's a perfectly competent bike. I want to believe in him.

Also today, I picked up from the bike shop the 2008 Surly Karate Monkey that I call KiM. After dropping her off a cliff on Monday, I had to get the brake lever fixed. I also had them swap out her suspension fork for a rigid one. This weekend, I'll outfit her with skinny tires and my bikepacking gear, and shore up Roadie with a few new cables, brake pads, and a rack, all in preparation for the grand fall tour, the Golden Circle. I hyped up this trip enough to convince fellow enduro-nut John Nobile to come all the way out from Connecticut. I told him he would experience "real Alaska" (even though 90 percent of the route is in Canada), complete with wind, cold rain and maybe even a little September snow. We're setting out to relive our Tour Divide glory days on some of the most remote pavement you can find in North America.

Doing all of this started me thinking back to the Tour Divide. It's been exactly two months since I returned to Juneau. It's amazing to me it's only been that long. It feels like I've been "off the road" for ages, settled back into the mainstream of my life like I never even diverged from the flow. Still, little changes from the summer linger. A few ways I am different:

Tuesday, September 15, 2009

Hacking LINQ Expressions: Select With Index

link -> Hacking LINQ Expressions: Select With Index

NHibernate Testing with SQLite in-memory DB

link -> NHibernate Testing with SQLite in-memory DB

SQLite LogoThis is a follow-up to my post here about SQLiteDatabaseScope, a small class to control the lifecycle of SQLite in-memory databases. It allows you to run NHibernate tests against SQLite’s fast in-memory database. Since each test can have its own database in memory, you can easily run tests in parallel without conflict.

Wednesday, September 2, 2009

Fire and smoke in the Tushars

link -> Fire and smoke in the Tushars

Last weekend we did a little trip to the Tushar mountains East of Beaver, UT.  The riding is rugged, the scenery huge.  It feels like Colorado high country.

Thursday, August 20, 2009

Japan Going Small

link -> Japan Going Small

With the economy spiraling downwards each day, more and more people are choosing to drive cars that are efficient in fuel use. In Japan, there’s very little parking space and the rising costs of fuel are not going to make things easier. However, even before the Europeans and Americans started building mini cars, the Japanese have already started patronizing their own version of city cars called Kei.

The first thing that you would notice with Kei cars is their size. It’s so small that other minis would look like Goliaths when placed near them. These cars can be found all over Japan, which started during WW II. During that time, all resources were scarce including metal, rubber, and oil. In order to compensate for that, small cars were built that would still deliver the goods despite of their limited size.

The fact is, these Kei cars are freakishly fuel efficient while releasing only very small emissions. In order to be considered a Kei car, it should never be more than 11-feet long, 4.6-feet wide, and 6.5-feet high. Aside from that, the engine should be no more than 660 cc. The fact is, it’s really small, but if you’re only running errands and driving around the city, why would you need anything bigger?

Even Kei trucks are small, but that does not mean that they lack the power that you need. The Kei car pretty much helped the Japanese industry get back to its feet after the war. That’s because with a thriving automotive industry, the whole society will be moving again and that means the enterprise will start pouring in much-needed cash.

Today, these Kei cars are

Tuesday, August 4, 2009

Southern New Mexico

link -> Southern New Mexico
The first thing I saw when I woke up in the morning was a baby bird, dead in the grass just inches from my face. Above me, an adult robin, presumably its mother, hopped frantically from branch to branch, screeching into the still air. I stood up quickly and moved my bag away from the scene of the accident, which just riled up the distraught mother even more. Morning sun filtered through tall ponderosa pines. The baby bird laid lifeless on its side. And I was on such an emotional edge at that point in the race that I just broke down bawling. It was so sad - the dead baby, the despairing mother, and an unknown tragedy that seemed to occur while I slept in ignorant bliss.

Thursday, July 23, 2009

Unsubscribing made easy

link -> Unsubscribing made easy
Posted by Brad Taylor, Gmail Spam Czar

We believe you should only get the mail you want to get. Some of you already use the "Report Spam" button on all kinds of unwanted email, and for that we're very thankful: the more spam you mark, the better our system gets at weeding out junk mail.

Unsubscribing from mailing lists and newsletters you subscribed to a while back but no longer want to receive should be just as easy. Searching through individual messages for little unsubscribe links is too big a pain —you should be able to unsubscribe with a single click.

So we just launched something that makes this all work better, both for Gmail users and big email senders. Now, when you report spam on a legitimate newsletter or mailing list, we'll help you unsubscribe. After clicking report spam, you'll see a little dialog like this:


Clicking "Unsubscribe" will automatically send a request back to the sender so they'll stop emailing you.

This only works for some senders right now. We're actively encouraging senders to support auto-unsubscribe — we think 100% should. We won't provide the unsubscribe option on messages from spammers: we can't trust that they'll actually unsubscribe you, and they might even send you more spam. So you'll only see the unsubscribe option for senders that we're pretty sure are not spammers and will actually honor your unsubscribe request. We're being pretty conservative about which senders to trust in the beginning; over time, we hope to offer the ability to unsubscribe from more email.

For those of you senders who are inte

Teams should be improved, not enlarged

Cockburn writes:

Here is a common problem: A manager has a 10-person team that sits close together and achieves high communication rates with little energy.

The manager needs to increase the team's output. He has two choices: add people or keep the team the same size and do something different within the team.

If he increases the team size from 10 to 15, the communications load, communications distances, training, meeting, and documentation needs go up. Most of the money spent on this new group will get spent on communications overhead, without producing more output.

This group is likely to grow again, to 20 people (which will add a heavier communications burden but will at least show improvement in output).

The second strategy, which seems less obvious, is to lock the team size at 10 people (the maximum that can be coordinated through casual coordination) and improve the people on the team.

To improve the individuals on the team, the manager can do any or all of the following:

* Send them to courses to improve their skills.
* Seat them closer together to reduce communications cost.
* Improve their amicability and teamwork.
* Replace some of the people on the team with more talented (and more highly paid) people.

Repeating the strategy over time, the manager will keep finding better and better people who work better and better together.

Notice that in the second scenario, the communications load stays the same, while the team becomes more productive. The organization can afford to pay the people more for their increased contribution. It can, in fact, afford to double their salaries, considering that these 10 are replacing 20! This makes sense. If the pay is good, bureaucratic burden is low, and team members are proud of their output, they will enjoy the place and stay, which is exactly what the organization wants them to do.


As a programmer and not the manager how can I help our team improve? Hopefully reading this book is a start, but I am going to keep looking for ways to do more.

Monday, July 20, 2009

Speechless: Dilbert Creator's Struggle to Regain His Voice

link -> Speechless: Dilbert Creator's Struggle to Regain His Voice

Designing a methodology

Cockburn writes:
Designing a methodology is not at all like designing software, hardware, bridges, or factories. Four things, in particular, get in the way:

* Variations in people. People are not the reliable components that designers count on when designing the other systems.
* Variations across projects. The appropriate methodology varies by project, nationality, and local culture.
* Long debug cycles. The test and debug cycle for a methodology is on the order of months and years.
* Changing technologies. By the time the methodology designer debugs one methodology design, the technologies, techniques, and cultures have changed and the design needs updating.


No wonder it is so hard to get this stuff right. It keeps things interesting though.

Tuesday, July 14, 2009

Extreme Hour

Cockburn writes
More recently, Peter Merel invented a one-hour process miniature for Extreme Programming, giving it the nickname Extreme Hour. The purpose of the Extreme Hour is to give people a visceral encounter with XP so that they can discuss its concepts from a base of almost-real experience.

In the Extreme Hour, some people are designated "customers." Within the first 10 minutes of the hour, they present their requests with developers and work through the XP planning session.

In the next 20 minutes, the developers sketch and test their design on overhead transparencies. The total length of time for the first iteration is 30 minutes.

In the next 30 minutes, the entire cycle is repeated so that two cycles of XP are experienced in just 60 minutes.

Usually, the hosts of the Extreme Hour choose a fun assignment, such as designing a fish-catching device that keeps the fish alive until delivering them to the cooking area at the end of the day and also keeps the beer cold during the day. (Yes, they do have to cut scope during the iterations!)


This sounds awesome. I wish we had done an extreme hour on my team before we started XP. I wonder if I could convince people to do one now.

There are so many different pieces to XP. It is hard to see how they fit together by reading a book. I think the Extreme Hour could show people how each part of the process is important without making them invest more than an hour.

Friday, July 3, 2009

Daily Commute started on July 1, 2009

link -> Daily Commute started on July 1, 2009
Starting yesterday, I am doing my daily work commute via the Twike. The missing piece was getting a second battery pack working well. I drove yesterday and today to and from work which for me is just under 8 miles. I don't yet have a good feeling for how much power it is taking to do my commute but today it only took 1.2Kw to charge it when I got to work (and that was after it ran the fans for a while to cool the batteries). The NiCads can deliver lots of power but they do heat up in doing so and right now we are having a heat wave in Portland which does not help. I got lots of thumbs up and waves today. One guy was keeping next to me and yelling out his open windows. "hey! really cool. Where did you get it? Did you build it?" that kind of stuff. Kind of hard to drive and answer questions in traffic. Work is cool about letting me charge there (used 12 cents of power today). I'm not sure, but I might have enough charge to go roundtrip without charging at work. Tomorrow I'm going to try a trip to someone's house that is 13 miles away so we will start to test the range a little more. Currently, my longest single trip is the 8 miles to work. Since I brought it home, I bought 3 new tires, had them mounted and balanced, and I installed them on the vehicle. I also did a lot of cleaning up in the battery compartment and on all the removeable panels (bottom and sides). With two reasonable battery packs, the car is pretty snappy on acceleration. I can keep up with traffic no problem and can even hill climb at a reasonable rate (not as fast as a car but at least I *can* accelerate uphill now). I have been taking a less direct route home to minimize the hill climb t

Thursday, July 2, 2009

Coordination is important

Cockburn writes:
Coordination is important. The same average people who produce average designs when working alone often produce good designs in collaboration.

Conversely, all the smartest people together still won't produce group success without coordination, cooperation, and communication. Most of us have witnessed or heard of such groups. Team success hinges on cooperation, communication, and coordination.


I like this quote. This is the reason why I am reading this book. I want to learn how to help myself and my team cooperate, communicate, and coordinate better.

Wednesday, July 1, 2009

Boatman’s bags

link -> Boatman’s bags

Amicability and Conflict

Cockburn writes:
Amicability is the willingness of people to hear the thoughts of another person with goodwill and to speak without malice.

Amicability is the weaker cousin to trust. Trust is wonderful and should be nurtured, but amicability is easier to achieve within a group and still confers advantages. I always watch the amicability level in an organization to learn to what extent information is being revealed versus concealed in conversations.

When people conceal information from their colleagues, they lower the rate of information discovery, which raises the lost-opportunity cost as well as the overall cost per idea developed.

Amicability permits successful conflict to occur when the project goes through a stressful period. The people, knowing that the others are not intending to be hurtful, can look past the current disagreement toward resolving the issues.

One might think that removing all conflict from a project team would be the best, but that turns out not to be the case. People need to be able to disagree, in order to identify design problems!


I think being able to listen and without an agenda is really important but really hard for me to do. I start thinking about how to word my response before the other person is even finished talking. I want to be more patient and not be in such a hurry to steer the conversation in one way or another. I need to trust that eventually both people working together will come to the best conclusion.

Tuesday, June 30, 2009

Expectations and Citizenship

Cockburn writes:
There is an interesting and relevant aside to mention about this group, having to do with expectations and citizenship. For reasons I won't go into, this team of business analysts thought they were supposed to work in the XP style and that XP prohibited them from writing things down.

Notice four things about their situation:

1. They misunderstood XP. It does not forbid people to write things down.
2. Their citizenship was so strong that rather than be poor citizens and write down their thoughts on the domain model, they chose to be good citizens and not write down their business model at all!
3. Actually, they knew that the project wouldn't succeed if they really wrote nothing down. So they each clandestinely wrote pseudo use cases and other notes, which they passed to the programmers. They still did not create a domain model for themselves.
4. By writing down those notes, they subverted their own (mistaken) interpretation of the official process. I find this situation particularly interesting, because they were at war with themselves about whether to be good citizens and follow the process (at the expense of the project) or to be good citizens and protect the project (by violating the process).

What was significant in the end was that they posted an information radiator on the corridor wall, on which they scribbled individually and as a group, to give their thoughts and decisions some stickiness.


I feel like I have been in this situation before. I want to do the right thing, but I don't know what the right thing is. I often wonder if I am shooting myself in the foot by trying to be too strict with my attempts to follow the XP recommendations. I guess it would be helpful to have an Agile coach to talk to.

Monday, June 29, 2009

Repairing Design Discussions

Cockburn writes:
On project "Winifred" (Cockburn 1998), the lead programmer announced at regular intervals that design was unnecessary and that code simply grew under his fingertips.

As a predictable result, the young programmers working in the room with him also felt it unnecessary to design. The code looked that way, too.

He eventually left and I took his place. To reverse the situation, I arranged for us to design by having conversations at the whiteboard. After some period of doing this, I started getting questions like, "Could you look at the responsibilities (or communication patterns) of these objects?"

By setting an audible tone in the room and making these design discussions legitimate and valued, the programmers started to converse about design together.


We struggle with these discussions on my team. I want to have these discussions, but I have a hard time getting everyone to participate. There are a few vocal members on my team that complain that our efforts to design as a group are unnecessary. I wonder if there are ways to work through this problem without losing team members.

Saturday, June 27, 2009

Program by example

Cockburn writes:
You can and should start taking advantage of people's strengths in copying and altering work samples. Create a small, online library of real samples for work products produced on your (or some previous) project. Other people can then simply copy one of the samples as the base for their own work. In copying it, they will pick up both the structure and style from the sample, while changing the details to fit their purpose.

The implication is, of course, that you would like the work samples you collect to be relatively "good," having structure and style you don't mind having copied. They don't have to be perfect, of course, just "good enough."


I cut and paste code all the time. I think I have a catalog in my head of all kinds of patterns of solving problems. I wonder if people would use a WIKI site with code examples instead of cut and pasting from the codebase?

This HAS To Be The Coolest Way To Play Music

link -> This HAS To Be The Coolest Way To Play Music

Debunking Canadian health care myths

link -> Debunking Canadian health care myths

Friday, June 26, 2009

Cockburn writes

Piattelli-Palmarini describes a number of experiments involving risks and rewards. The interesting thing is that even when the outcomes are mathematically identical, the results are different depending on how the situation is presented.

Illusions of Choice

Piattelli-Palmarini cites a dual experiment. In the first, people are given $300 and then have to choose between a guaranteed $100 more or a 50/50 chance at $200 more.

People prefer to take the guaranteed $100.

In the second, people are given $500 and then have to choose between having $100 taken away from them or a 50/50 chance of having $200 taken away from them.

People prefer to risk having $200 taken from them.

(Piattelli-Palmarini, p. 58)

Mathematically, all outcomes are equal. What is interesting is the difference in the outcomes depending on how the problem is stated.

Piattelli-Palmarini sums up the aspect relevant to project managers: We are risk-averse when we might gain.


and then later

This characteristic, "preferring to fail conservatively rather than to risk succeeding differently," gets coupled with people's fear of rejection and the difficulty they have in building new work habits. The three together explain (to me) why managers continue to use the long-abused one-pass waterfall development process. Based on this line of thinking, I expect that people will continue to use the waterfall process even in the presence of mounting evidence against it and increasing evidence supporting incremental and iterative development. Use of the waterfall process is anchored in a failure mode.



Our group has been trying to practice XP for over a year now. I like it, but I think it is going to be a long hard journey to get some people to try this.

Wednesday, June 24, 2009

Repositories And Abstract Classes

Ran into weird problem where my Aggregate Root was an abstract type with many concrete classes. Should I have one Repository for each concrete class or one Repository for the base class?

I couldn't find anything in the big blue book or online so I made something up. I have one Repository for the base class. Then each GetByXXX method is a generic method that takes the type of objects you expect to get returned. So you can get a list of the base classes or a concrete type or an interface that allows you to group concrete types together.

Them's Funky People

Cockburn writes:

There is some resistance in our industry to the idea that people factors dominate software development.

As I participated in initiatives for formal program specification, advanced programming environments, and new development processes, I kept discovering that successful teams were still delivering software without using our latest energy-saving ideas.

Initially, I viewed this as a nuisance: "Why can't those people just realize how much better off they would be if they used our ideas?!"

Eventually, it went from a nuisance to a curiosity.

Slowly, it became a discovery.

I reversed my assumptions and found that the opposite correlation held: Purely people factors predict project trajectories quite well, overriding choice of process or technology.

I found no interesting correlation in the projects that I studied among process, language, or tools and project success. I found successes and failures with all sorts of processes, languages, and tools.

A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology might help or hinder them along the way).


I need to remember this. Put the people above all else.

Monday, May 11, 2009

Ecogo

link -> Ecogo
It has been a while since I have passed along any of the entries from last year’s “commuter bike for the masses” design competition. I have been busy with other things, but I do still have quite a few of the entries to share. As a follow up to my last post, I will show you one more of the velomobile entries that we received…ecogo by Walter Graf.

Here is what Walter had to say about his design:

“ecogo is a concept recumbent bicycle designed to get commuters out of their cars and onto - or into - bikes. The recumbent features a reverse-tricycle design to keep it stable and take the balancing act out of riding a bike. With its laid-back seat and ergonomic pedalling position, the rider / driver can relax and take it easy while pedalling. The bike will stay upright even when going up hills slowly in the "granny gear."

The carbon fiber and formed plexiglass shell protects the rider / driver from the elements, just as a car would, so this can no longer be an excuse for not biking. Its aerodynamic shape reduces the drag from the wind, which, along with the low profile, make riding at high speeds much less tiri

Parasitic twin erupts from 30-year-old man's belly button

link -> Parasitic twin erupts from 30-year-old man's belly button

Saturday, May 9, 2009

Mark Twain Motivational Posters | Sloshspot Blog

link -> Mark Twain Motivational Posters | Sloshspot Blog
Sloshspot is the place on the web to search for nightlife spots, bars, pubs and clubs in Lawrenceville. Search our directory for nightlife and entertainment venues in Lawrenceville that match your interest. Check out whats going on in Lawrenceville tonight!Mark Twain Motivational Posters: The Sloshspot Blog is the number one blog for nightlight and partying the world over...

Friday, May 8, 2009

The Lincoln C Concept: The Green Car with the Luxury Feel

link -> The Lincoln C Concept: The Green Car with the Luxury Feel

The Lincoln "C" Concept

It must have been quite the surprise to auto enthusiasts when Lincoln presented the Lincoln C Concept car. While most people are hesitant to make the shift from their gas-guzzling rides to the smaller and greener vehicles on the market, it should come as a comfort to luxury-loving folks that they won’t have to give up the comfort provided by their luxury rides–not once the Lincoln “C” Concept hits the market.

Tuesday, March 3, 2009

Ant trails, bike trails and Contrails

link -> Ant trails, bike trails and Contrails


Like ants leaving a scent trail for other ants to follow, cyclists can follow the trail of other cyclists with the Contrail Biking Community Tool designed by Pepin Gelardi and Teresa Herrmann for a competition.

A doodad deposits chalk powder on the rear tire, which in turn leaves a trail of chalk on the road showing the bicycle's path on the road.



As more cyclists ride along the chalk marked route, the routes become more visible to cyclists and motorists, just like ant trails are reinforced as more ants use the path.

Bicycles taking the lane


I really like this, though I hope I'm not directly behind a cyclist using one of these -- it could be pretty bad for the asthma. Doobybrain describes this concept as useful for showing cyclists where to "ride safely and out of the way of vehicular traffic," but the illustration above accurately portrays that the safest place can be in the lane with vehicular traffic if lane width warrants it. Gutter bunnies are dead bunnies.

More discussion at Bike Hacks and Streetsblog. Hat tip: Jamie in Columbus.

How to Be Jason Bourne: Multiple Passports, Swiss Banking, and Crossing Borders

link -> How to Be Jason Bourne: Multiple Passports, Swiss Banking, and Crossing Borders

Tuesday, February 24, 2009

Never Get Lost Again!

link -> Never Get Lost Again!

Thank you for purchasing the Bunn-O-Meter™ model OD2750!  The Bunn-O-Meter OD Series puts powerful omni-directional global positioning in a convenient size for pocket, backpack or purse.

No, I don't double as a keychain. Don't go there.

Thursday, February 12, 2009

Kingsford is on fire!

link -> Kingsford is on fire!

Meet "Kingsford" the piggle. He is the most anerable house-pig you've ever seen. Squealing included:

Great find, NTMTOM. Via LA Times.

Wednesday, February 11, 2009

Why not get a "Pomster"?

link -> Why not get a "Pomster"?

YOU HAVE NO REASON WHY YOU SHOULDN'T GET ONE

[shifty eyes] I'm still checking if they exist. Something about the beady-eye to paw ratio scares me.

This pocket pet pomster was created by Scuzzi for a contest. No, you can't have one.

Sunday, January 25, 2009

Comic for January 25, 2009

link -> Comic for January 25, 2009

Ladies and Gentlemen, THE PERFECT SCHNOZZLE

link -> Ladies and Gentlemen, THE PERFECT SCHNOZZLE

[Handing piglet blule-ribbon award] Dang, piglet, you win theBest of Schnozzles. We don't even have to wait for the Schnozzle awards in March. This competishe is OVER. [clapping hands in 'done' motion]

Dsc006402_copy

Can you lift your head up a little bit there to show us the GOODS?

Thanks.

Dsc00642

Oh you knew I was gonna do this.

Stand back. It's for your own good.

SCHNOZZHANCE!

Untitled2

Runt piggle "Chester" LOVED burying himself in heaps of laundry.  Photos by the fabulous Kristine B.

Friday, January 23, 2009

Monday, January 19, 2009

Friday, January 16, 2009

swissmiss: A bike lane that travels with you

link -> swissmiss: A bike lane that travels with you
If there is no bike lane, what to do? Bring your own: LightLane . We agree with GOOD, this is a superb idea. (thank you rion)...