Selling Agile to Developers?

One question I got recently was "How do you convince developers to adopt Agile methodologies?"

And I scratched my head.

And I gave my inquisitor a funny look, like maybe he said "sea gulls" instead of "developers", but his face was steady, he really said "developers".

So I gave him some answer, indicating that "Yes, I understand what it's like to have to go above and beyond explaining what Agile is to really sell it to a dev." But I don't think I can relate at all. How can a developer see that he gets to control his work load because he (and the team) get to provide the estimates, and not be in love immediately? If that wasn't enough, a dev now has:

• a Scrum Master defending his estimates with empirical data from things like burn down charts
  
• increased communication and involvement with his team, meaning that he is going to grow professionally from it, and so are his team mates
  
• more contact with the person or people who have input on a feature, and
  
• less management that only impedes his process
• a well defined list of features to work on (though the individual features may still remain vague, at least the target is not moving anymore)

The dev will also find that he gets to deliver working software numerous times throughout the year. I can't imagine what kind of person you can hire that would say, "Really? That's what I get from Agile? No thank you." I would probably fire such a person because either a) that person had a perfect job before working for me, and he's a moron for leaving, or b) that person is not actually a developer, but is in fact a joy-hating monster, or c) that person has never actually worked as a developer before.

If you put a microphone in a non-Agile developer's home I bet his top complaints would be:

• Of the things I'm working on, I don't know which one has the highest priority so I don't know what to do first!
• My team mates have no clue... about anything!
• My boss just set a random deadline for next week after I told him this project would take a month!
• I thought I did what was asked for, but it turns out they wanted something completely different!
• I can't get any work done because my boss always asks me for status updates!

With Agile, all that crap is fixed. To me, the hard sell is to the business side. Suddenly the Product Owner has to be available for questions a lot more, and he has to maintain a prioritized list of features and bugs, rather than just a list and pretending that the entire list is filled with high priority features, all of which will go in the next release. The project manager has to change the way he reports on progress, and has to participate in stand up meetings. Sales has to reign in what it promises to customers because it can't inject a feature into the product at will (instead it can introduce a feature via the PO at the start of a sprint and should expect to get it at the end of a release instead of "by the time the customer signs"). Customers have to start really dealing with trade-offs, "Do I want feature Z, or do I want Bug Y fixed?". And there's more visibility across the board, no one can hide behind lies or shift blame any more.

The business side of the system has been working pretty well for a while, but at the expense of the developers. The developers should want to fix it if they have their head on straight. The rest of a company could justifiably take a stance of, "If it ain't broke, don't fix it", and that's a hard perspective to change. Your developers should want to adopt Agile if they're worth their weight in salt. If they're opposed to Agile, make sure to check yourself and that you are presenting it so that the benefits to developers are as clear as a bell. Agile it should sell itself if you've done that correctly.

iPhone Web App in Ruby on Rails

This app has been made before, but not by me, not for the iPhone via the web. It's basically an overgrown score pad for fencing referees. When done by hand, a ref has to have a stop watch, a piece of paper, and a writing device, and he's not supposed to use a clip board because he has to make hand gestures to indicate the action and who is awarded the point.

My former fencer, Josh, came to me talking about an idea he and Ed had to incorporate iPhones and iPod Touches with scoring boxes and the bout committee. Up till then, I had been reading Rails for .NET Developers, and I had been hungry for a project to try out my new found knowledge.

In all honesty, there's no need for any server-side scripting in this app...yet. Once it ties into data from the BC, then it'll make more sense - so for the moment it really could just be straight HTML, CSS, and JavaScript.

What I like about this little app, this one page view into the status of a fencing bout, is that I finally did all of the suggested best practices that I had been avoiding. I used table-less design, so the presentation is all in the CSS, and not inline in the HTML. I did the same kind of thing with my behavior. All of the onclick event handlers are assigned in a script block using Prototype's Event.observe method. From there I even separated the code into separate blocks, one for dealing with the score, one for the timer, one for priority, one for swapping, and one for resetting. Once I started to make that kind of separation, my dependencies were clear as a bell, and easily refactored.

The resulting HTML, CSS, and JavaScript are all chunks of code I feel comfortable with. I feel like this is maintainable client-side code - code that I could easily have someone else work on with little explanation. I have never felt that way about client-side code before. I have known that the nagging feeling about client side code was the same feeling that others had to be experiencing, but I didn't know it could be addressed in the current state of the web.

Sadly, this only takes care of my code. It will not stop other people from writing bad code. Event the widely accepted method in the iPhone community for detecting if the browser is in portrait or landscape mode had a lot of room for improvement. Originally it was polling ever half second, when it could be tied into the resize event. Then I also removed the check to see if the width was a magic number of 320, and instead just did a test to see if the screen width was less than the screen height. Now if Apple comes out with a new phone with higher resolution, I'm all gravy baby.

Developing for the iPhone also made me think about the UI a lot more. In other apps like this, you'll see separate buttons for starting and stopping the timer. You won't see buttons like that on my app because I realized that a user might be ok just tapping on the timer itself to make it change state. The font color changes to reflect that the clock is ticking. A similar idea is employed with the score. Taping on the score itself adds one to the count. I wanted to use double-tap to decrement the score, but sadly the double-tap is reserved by the system for other functionality. At the end of my development, I found documentation on making objects wiggle to indicate that they are draggable, access to the multi-touch events which are handy for rotating, scaling, and just interacting with all kinds of things on the screen, and also a little lock-slider clone.

Big Org, Small Bandwidth

You're using Scrum? Excellent! But now you're adding a new team and you want to stay connected so you're now going to two stand up meetings each day. Okay, that works. But what if you add another team? Two more teams? Five? Now you're either spending your whole day in stand up meetings (and that's a lot of standing up), or you're only getting part of the picture each day.

You do some research and come upon this Scrum of Scrums thing. A representative from each team now makes up a new team and they have a stand up meeting. And this works pretty well until you've reached about fifteen teams. That's fifteen people giving updates about the progress of 100 employees. It starts to become an information overload. So you do what worked last time, and add another layer, a Scrum of Scrums... of Scrums (aka SoSoS or S3 because we're quickly running into the land of ridiculousness). You have successfully formed a tree network (see the diagram above from the Wikipedia entry on Network Topologies) and you have also managed to alienate yourself from all the people doing the work. *screeching brake sound*

You think to yourself, "But this is how business has always worked! Yet.. shouldn't the head know what the feet are up to?" You scratch your head because the tree network isn't making sense, and usually when a thing has this "smell" to it, it means you could be doing something better. "But I don't have the bandwidth to stand up with 15 teams, how can I possibly stand up with 50?" For that, I have a suggestion.

The real impediment is you as the department head. You don't have to know everything. There are some things you need to know, like projected release dates, and product backlog priorities, but these are things that you should be able ot easily get from your teams either electronically or by walking by their team space where they have their burn down charts posted. The people who need to know everything, are the people doing the work. Jim needs to know about the new Logging API so he doesn't have to rewrite one of his own. Bob needs to know that Sue has a problem with the parameters being passed to her function because she wasn't expecting NULL to be allowed. Dave needs to know that he needs to add upgrade the Linux servers to the latest Java VM to fix a bug Mark found, and the new employee, Mindy, needs to figure out where to download the third party DLLs from. If you're doing SoS or S3, somehow that knowledge has to not be omitted from being presented at the SoS, and then brought back to the team, to someone who might have a solution, and then that brough back to the SoS, and back to the original team.

You don't need to know all that, but they do.

And yet, those team members don't have the bandwidth to convey that information directly to everyone else any more than you do. We've tackled this problem of bandwidth in software plenty of times. When we can't push enough data in a cost-effective way between a server and the clients, we either a) get more servers and a domain controller to route traffic along the tree, or we make a peer-to-peer application like BitTorrent. We create a bunch of partially connected networks, using a part of the available badwidth of each user to create a very scaleable network that is more resistant to single points of failure, is cost effective, and still gets the job done.

I propose, that people, Scrum teams, can communicate the same way. If Team A always talks to Team B and Team C, and Team C talks to Team D, then all four teams are either directly or indirectly connected. Eventually, knowledge from Team A would propagate to Team D through Team C. This means that instead of a Tree network, we're looking at a Mesh network.

Goals:

• Allow the network to be self-managed. Teams should naturally work with other teams where there is overlap. But do give them the time and tools to form those networks. Maybe instead of having a cross-team standup every day, you provide those teams with lunch at the same time in the lunch room.
  
• Help reduce the degrees of separation. If Team A works with Team B, who works with Team C, who then works with Team D, A and D are very separate, and the chance of knowledge being passed from one to the other is very small. Do this only when it makes sense by fostering cross-team communication (assign them related feature sets, have an off0site with the two teams, etc). Ideally you'd want a Fully Connected network, but then you're out of bandwidth all over again.
  
• Identify "hubs", and participate in those stand up meetings. Some teams will naturally be more "social" because of the nature of their feature set, or by the makeup of the team membership. Hook into these teams to get a feel for what is going on day-to-day. Think of it as standing in Grand Central Station, you're much more likly to see someone from San Francisco pass through there than you are if you waited in Boonyville, USA.
  
• Don't let the connections stagnate. Some connections will always need to be there, but by forming new connections, now there's a chance for all of the knowledge to transfer to a new area within the company. Transfering members across teams who have strong bonds with their old team could serve you well in this area.
  

Through this Mesh network, a company can produce a much more adaptive communication structure that diseminates knowledge more reliably, is at less risk of a communication failure, and addresses the issue of limited bandwidth in a way that scales to any sized company. Best of all, it fits with Agile principles of self-organizing, and removing waste in a way that enhances your business.

The New Commodity

When you watch TV, you get to enjoy your show because they fill it with commercials. This monetizing model can be seen in radio and even some areas of the Internet too. Ads! But I submit to you that while money will still make the world go around, knowledge, structured knowledge, will make the money change hands. All the technology is heading that way, and if you aren't on board, you're not going to get into the money flood that's coming.

The demand is out there for knowledge - this broad "I don't know" type of idea, where people know they'll want to know 'things about stuff' but they're not sure to what end just yet. Google is poised very well for when the dam breaks. If you strip out the Google Ad Words revenue stream, you might think that Google has no way to pay the bills. But the truth is that they probably house more knowledge about people, demographics, chatting, email, images, video, and everything else, than any other library, corporation, or other KB group out there today. That is to say, that if knowledge is power, Google is will be the world's new king.

What is interesting, is how they do it. They give their software away. It's easy to use, there's no barrier to "buy" because you don't have to buy it, you don't even have to install it, and if you already have a Google account, you don't have to sign up for anything extra. Just point your browser at a URL and away you go. So now you're using their product giving them plenty of knowledge nuggets with each click and keystroke to be a data-miner's wet dream. And because of that, they can release new features or rearrange their UI to match what people want.

The really brilliant part is the platform and the price. Since it's all SaaS, they can push out an update whenever they want. And Google knows exactly what version you're running (hint: it's the same version as all of their other users). The price ($0) means that you're going to be less likely to complain if the server goes down, or the behavior is a little quirky. Sure, you might file a bug, but you're not going to be able to threaten to take you business else where, because you're just one person who has zero cash bargaining power. Yes, you have some value to Google, they want to know what you know, and they want to know what you don't know you know. But that knowledge you have is just a tiny slice of the millions of other users they have.

Other companies are starting to realize what's going on. JobScore is one such company that gives away the applicant tracking system they make, so that they can sell the knowledge that recruiters input into their system to other recruiters. They make the same old software that anyone else can make, but they sell the knowledge that only they had the foresight to see as a commodity. Now recruiters get better data thanks to the work that other recruiters were doing anyway. Here in the Bay Area, I see start ups all over the place with the same kinds of business models, though some don't have a market to sell their knowledge back to, they hope to be gobbled up by a knowledge giant like Google.

This idea that knowledge is a commodity is really what sets the big G apart from Microsoft and Yahoo who really seem to only fill a direct need with software, but neglect that they can get something extra from a user's experience. Ultimately, this leads us to write software that lets us solve hard problems. Things that fall into a category of 'dynamic pattern recognition' are great problems for humans to solve, but hard for machines to recognize. "Are these two faces the same?", "Does this MP3 contain profanity?", "Would a mother be upset if her child saw this picture?". One solution is to bring in all kinds of math-minded people to set up all kinds of algorithms that run in O(n*log n) time and gets it right only slightly more than if it just randomly guessed. Or, you can write software that asks a human "Hey, what do you think?" You have to work with humans though, humans who are sometimes lazy, who lie, who game the system for their own benefit.

Google has a happy set up for solving just such a problem. Actually they have millions of solutions - their users. By asking a lot of people the same question, they quickly can create some easy math to work with "What does the majority say, and who are the outliers?" You can ask your 15 year old son to compute the standard deviation of most any data set, but it is the kind of work that machines were built to handle.

Knowledge gathering is really quite simple. Step one: Write software that is easy to use and gathers knowledge. Step two: Get users to use it, thereby gathering knowledge. Step three: Profit! It's the bread and butter of Google, and that business scheme is rapidly being adopted in the start up world as well.

Scrum Master Certified

This Monday and Tuesday I attended the Scrum Master Certification tutorial at QCon held right here in San Francisco, California. It was great to have this tutorial right in my own back yard. I wish I could have attended the rest of the convention this week with speakers like Martin Fowler from the Agile community, but alas I was paying for the $1,700 course myself and shelling out extra bucks on top of that didn't seem like a good plan.

The course was two days as I mentioned, and held no surprises for the seasoned Agile/Scrum participant. We went over the product backlog, the sprint backlog, product planning, sprint planning, Scrum artifacts with a lot of emphasis on burn down and burn up charts, and we did some simulations, which is what I want to talk about.

In our simulations we had WAY too much to do in the time box we were given. So for instance, when we were told to prioritize the stories, we didn't really have time to fight over was story A really more important than story B in relation to stories A through ZZZZ (so there were lots of stories). But, we didn't have time to fight. Initially I felt cheated, like the simulation didn't resemble "the real world", but then I got to thinking that it could resemble the real world, if I made it that way. Think about it, why give your Product Owner and the stake holders days to decide what they can decide in hours, or even minutes. The end result will probably be the same that the critical items get in the product before the release, and the rest will possibly go in the next release.

I also got confirmation that technical items, those that don't directly add value to the customer, but help the devs produce better code faster, should also be on the product backlog, which implies that a tech person should be a stake holder. That person could be an architect, a team leader, or maybe even just a team member (and rotate the member). Same thing for maintenance (aka super high priority bugs, that management can't downgrade because they can't set expectations well enough with customers) - put a person on them all the time, but rotate who that person is so he doesn't burn out.

So now I'm a Scrum Master, and I feel confident I could do what a Scrum Master should do, given my new found training and my previous experience with Passageways and my counter-Scrum experience at Jobvite. If you're looking to hire someone with unlimited courage and a good sense of people, feel free to drop me a line.

Generalists

This week I sat down with Davis Frank of Pivotal. He's part of a contractor shop that does projects in Ruby and Java, but it's exactly the kind of shop that you wouldn't think could exist. They help a company work on a project, but at the same time they also teach that company how to be Agile (XP specifically). When you sign up for Pivotal's services, your engineers pair up with Pivotal's engineers. When the project is over, Pivotal gives you their project management software, Pivotal Tracker, and you're on your own.

One of the things Davis said was important in an Agile shop is to hire generalists. He admitted that no one is ever even in all areas (database, class libraries, UI design, client-side scripting, etc and even other non-tech areas like, um, communication), and that by the nature of being human we all have "specialties" but that the employees that work best in Agile are the ones who can do it all - there's no barrier preventing them from working on any particular task, especially when paired with someone else.

It doesn't make sense though. If you want a killer database, you have to hire the database zealot who has never come out of his Oracle cave, right? There are some projects where that will be true, where you need the specialist. But when it comes to the web, we're not talking about single platform applications. Knowing how to design a decent table structure that'll lend itself to your business objects that get passed through web services to be displayed on desktops, mobile phones, and video game consoles is a bit more practical.

We used this at Passageways to it's full advantage. No one person was ever on "the critical path", rather, the whole team was on the path. There was a bucket of tasks, and they were assigned to the team as a whole, and an individual took them when he or she was ready to work on them. So if I finish making the schema for the new reports, and then I jump over and add some themeing to the control for the new chat feature.

Sounds great? There's a cost to being able to do this. The cost is that everyone involved in that bucket of tasks has to understand "the big picture for all of the user stories that those tasks relate to. If there are ten user stories in a sprint, then all the developers (and testers) need to be part of that design process for all ten stories. This means that the first few days of a sprint, you'll have to sit around a white board. It also means that you'll disagree, and it'll be frustrating at times. But you'll also have fun. You'll learn from each other, and you'll learn how they think, and you'll come to trust them over the long term.

In the short term you'll know exactly what your fellow teammates are expecting a feature to look like. You'll be able to grab a task off the stack and get going without too much time of "getting caught up" and having to have your fellow team members repeating themselves.

Otherwise you're a bunch of people working in the same room, but you're not a team. A team agrees on design, a team knows where a feature is going, and where it is at all times. Imagine a soccer game where, before you could pass the ball, you had to tell your team mate where the ball had come from, how he had to move the ball up the field, and what the goal was. It's a pretty dysfunctional picture, and the same applies for software. You have to be involved and agree from the start so you can easily jump in half way through.

I Went Looking for a Ball...

...and I found something I didn't expect. The back story is that I was talking to a colleague about the merits of different jobs, and I started to talk about what kind of company I'd set up. Small group, about fifteen or so, mostly engineers, and the goal would be to let the producers produce as freely as possible. Trust the team. We could make anything. But where would the seed money come from?

My colleague said, "Have you heard of Ooga Labs? They're right down the street." I hadn't, so I asked the Internet and came across an article on SFGate from 2007 about Ooga. It mentioned "Calvinball", a game where the rules are always in flux. I'm always interested in how companies arrive at a culture, and a place that played a game based off the comic Calvin and Hobbes and features a CEO doing a head stand in the news can't be too bad a place to work, so I headed down Market St. to see what was up.

Up on the fourth floor of 703 Market St. is a sign "Ooga Labs Please use other entrance", so I did. After just a few seconds of looking totally lost someone offers to help and points me to David when I ask about Calvinball. We grab a conference room, but not before I get the chance to take in the office. But it doesn't feel like an office - there aren't cubes, there aren't high ceilings, and the desks are well decorated with everything from half drained cans of your assorted sodas to a fave figurine. While I'm looking around David informs the immediate area he's winning Calvinball, but there's no ball around and yet no one contests his winning.

The chairs are comfy in the conference room, there's a projector on the side wall and plenty of white board to collaborate on. It quickly becomes clear that Calvinball is not the core of this company. It's a game, it's fun, but it's the result of something else. David said one word about working at Ooga Labs: TRUST. I do not hear that word too often in business, and for someone to tell me his company is about trust when I just walked in off the street to ask about a game, it has to be genuine.

From what I gathered, everything good about the company stems from that trust. If you trust a person to do his job well, to make mistakes, but to do it well, he's going to love his job a lot more than the guy who has to write a detailed tech spec, and submit it for review, and have constant code reviews, and make presentations on why he should use widely accepted best practices. The trusted guy is gonna speak his mind, and his trusted colleague is going to disagree when he thinks there's a better solution, and they're going to come up with something great because they can talk. And when their trusted boss says that the priorities have shifted, his employees trust that he's got the company, not just himself in mind.

Bigger than the day-to-day, what happens because of this trust, is that they make a great product (check out GoodTree), and people go home feeling rewarded - happy. So yeah, they play Calvinball, but what they have, is the best thing a business can ask for.

Ooga Labs

Painful Software Scheduling

I recently read an article from "Joel On Software" (http://www.joelonsoftware.com/printerFriendly/articles/SetYourPriorities.html) in which he discusses a feature prioritization technique. At some point, he mentioned "Painless Software Scheduling" in passing, and I thought to myself, "This sounds like something I should look up."

I didn't look it up. Instead, I decided to write about my experience of the opposite. Then I'll go back and read what the painless variety is all about and see where I stand. I don't have any good reason why I should go about it this way, but here I go!

I have had the honor of experiencing iterative development for a couple of years now. I've seen user stories (features), stakeholder meetings, feature costing meetings, and all the fun stuff that you get involved in when working with such a process. The best part is how the schedule is decided. Once the features are prioritized and given a cost the schedule is made. Here's how that goes.

Manager Type: "Hey Developers, how many features can you do this iteration?"
Developers: (counts hours, subtracts meeting time, etc) "uh, thirteen features."
Manager Type: "Thirteen? Guys, we have a backlog of 247 features. 213 of which are high priority"
Developers: "Well, we can only do thirteen. That includes coding, testing, documentation, and buffer for a million unknowns."
Manager Type: "Did you guys subtract hours because of meetings?"
Developers: "uh, Yes."
Manager Type: "I'll go ahead and clear those out for you. How many can you do now?"
Developers: (counts hours) "We can do thirteen."
Manager Type: "Still? Really? Why?"
Developers: "What do you mean why? That's how much we can do. That's what we calculated."
Manager Type: "After I cleared the meetings?"
Developers: "Right. We count our hours and take 60% of everybody's time and round down to the nearest whole number."
Manager Type: "I'll go back to the stake holders to get some more details on the features, then you can give us better estimates. So be ready to re-cost the features in a couple of hours."

Notice that the schedule doesn't exist. I'll bet money that when those "detailed" features come back it'll be the same conversation because the features don't have a detailed specification and the unknowns are just too large. That's painful.

Instead of annotating the rest the process I started above, here's a summary of the rest of the story: stakeholders end up in an eight-hour meeting, which they didn't have time for. The developers end up spending two days waiting for features and defending their estimates. The manager type argued every single feature on it's merits and motivation. Now nobody in the company wants to do it again. Most people that were involved in that eight hour meeting won't be showing up to the next one.

Try to run that process a couple more times and pretty soon, sales people are selling features so they're guaranteed to make it into the next iteration (or the current one), developers are giving insanely low estimates to their manager type will get off their back, and support people stopped talking about features all together. It was just too dang painful.

I would like to point out that the schedule still doesn't exist.

I know this scheduling thing has been done before, so why is it so painful? I can think of a couple reasons. It's painful because someone is pissed-off at some point. Everyone wants features now. It's not easy to take a list of 120 features and only release the top 20 of them. It's not easy to tell someone that their feature wasn't a high enough priority to get completed. It's insanely hard to tell everyone that the developers had to drop 5 features because of some unexpected pitfall. But the point is that something gets released.

This schedule will be completed by the end of this blog, dang-it.

I've noticed that painful scheduling leads to a lack of adoption from the people that create a need to make a schedule. The people that think of the features, the developers that implement them, the people that sell them, and even the people that want to create the features have no faith in any process put forth when the results are never seen.

How do we get all these valuable people to want to suggest, implement, sell, and schedule features? My guess is that's where painless software scheduling comes into play. The challenge we face is to make it easy to get features suggested and prioritized.

Let's start with making the prioritization meeting short, remove the debating of features on there merits and just get people to understand the feature and tell you how valuable it is to them. Make sure a reasonable number of features can be prioritized in no more than two hours. If you're looking at 247 features, try to slim down that number. Combine duplicates and remove extremely vague ones. You may even find features that only apply to one or two customers. Those can go.

Then, hand that list over to the developers and let them cost the features. If the feature is too vague, break it into smaller, more cohesive ones and keep the values of each the same as the original. If there are dependencies between features, slice and dice them until those are minimized and keep the values generally the same. I don't know how you'll do it, but you're smart. You'll figure it out, just do it. Trust whatever number the developers tell you. The more you have confidence in there estimations, the more confidence they'll have in themselves. That way, they will be far less afraid to come to you to drop a feature out of the iteration because of an unseen pitfall. After all, you don't want them to crank that last one out two hours before the demo. It will be buggy and useless anyway.

Now you have a schedule. If you started with 100 features and the developers can do 20 per iteration, then you can have it released in 5 iterations. Repeat the last two paragraphs between every iteration and you'll hone in on a number of iterations it will take and your confidence in that date will get higher with each run. If you make it easy for the stakeholders and the developers, they'll adopt the process and it's not painful for them. It's a lot of work for you, but when every body else is confident in your schedule, at least it's not painful!

Building a Car - The Falacy That Dev Teams Will Add on Features Mid-Sprint

You say: Build me a car
I say: Ok
You say: I want it in 2 months!

What kind of "car" do you expect me to build?

You say: Build me a car
I say: Ok
You say: I want it in 2 decades!

Now what kind of car do you expect me to build?

In the first case you probably expected an engine strapped on to four wheels and maybe some breaks. In the second case you probably expected a cutting edge car with all the safety features, smooth ride, and uses renewable resources for it's power source.

It's the same way with developers and features. Take a developer who loves his job, give him a month to do a feature he estimated would take him a week, and he'll take that whole month. Scope creep comes from everywhere, even the developer himself. "I can refactor this and optimize that, and we'll make this AJAX to it puts the burden on the client machine instead of our servers..." and next thing you know you've got a Corvette when a Taurus would have gotten the job done.

Agile says "If something goes wrong and the team isn't going to make their commitment, then it's time to cut features." And all of the product owners of the world freak out here, so we try to comfort them with this: "But if they're ahead of schedule, they can always add on features from the product backlog!" And all the product owners start to recover from their impending heart attacks. But now you realize that unless something happens to make them take another feature off the product backlog, it isn't going to happen because developers want to make the code/architecture/feature they can - adding business value is something that doesn't come naturally, preventing bugs and being on tech support calls is.

There is one mechanism that is somewhat effective in preventing internal scope creep. It's the same thing that happens when you have external sources of scope creep, the creeper has to present his creepiness to the developer, at which point the developer says "You're creepy!" and tells sales they need to bill the customer for more hours. "But Will, there's no presentation when the source is internal, I'm confused." But we can make the developer "present" I'm not talking about a stand up presentation where he can hide his work. I'm talking about my favorite tool, pair programming. Now you've got another dev, and every character you type is presented to her for review. "Why are you adding that in, we still need to build up the core functionality, quit being so creepy Will", ok, so maybe that last part was from my Google-stalking days, but you see how having an extra set of eyes keeps you honest and business minded.

Ideas - Being Heard

I learned something about myself, about job satisfaction today. I learned about my ideas, and how sensitive I am to how they are received. The situation was simple, and the guy who revealed my sensitivity is a great guy, so he'll hopefully forgive me for using him in my example.

We've been talking about doing a team outing/team building exercise. Our CTO, asked for ideas. I felt strongly about our activity being of value to the company, and that it also be fun and socially acceptable for the group. Falling backwards into the group in a trust game wasn't going to cut it for these guys. So I spent a couple of hours on it, now I had a time investment and an emotional investment in this idea generation.

I came up with two, a treasure-hunting service that focused a lot on the team aspects I thought were important, and a cooking class since Adam had suggested dinner as part of the exercise (I figured we'd work together at a common goal - getting fed - and solve our food challenge all at once). I sent the ideas off to Adam, who then forwarded them to the team.

A member of the team responded with "I vote against a cooking class." and then went on to suggest his own activity.

I was devastated. I didn't want to suggest any more ideas. I was done with helping the activity. I was turned off, tuned out, I wanted no part. But I didn't know it. I knew that if you asked me about it I felt poorly, but I didn't understand why or what the extent of the affect was. I thought it was just another email until later, when our CTO asked me to just send those ideas to the group on my own, no reason to make him the bottle neck. What he asked me to do made me think about why I didn't do that in the first place.

As a group, we're young, naive, new, green. We don't know how to talk to each other so that we get our ideas out and heard. In this situation, my idea went out, it was read, but not heard. The recipient dismissed it without really chewing on it, thinking it over, and replying with why it didn't work for him. Was it that he doesn't like classes? Was it that he doesn't like fire? Is he on a specialty diet and doesn't want to impede others? I have no idea. What I do know is that his message implied "Will, your idea is bad, so bad I can't even build on it or respond to it." Ouch. I know the sender didn't mean it that way, but that's how it made me feel.

Now put me in a room, and ask me for an idea. How likely do you think I will be to share my thoughts? If I say something, it'll probably be safe, something that has already been established as accepted by the group. My ability to help the group innovate, to be creative, has been destroyed over time on an unconscious level by experiences like the one above.

But I do still contribute ideas. I do it because it is rewarding to be heard - it's why I like working in small companies where everyone has a voice. And there are people who hear me, like our CTO, like Matt. When I say to them "I have a crazy idea [blah blah blah]!" they listen and say "That is crazy, but I see where you're going, what if we..."

And that's how I know I'm being heard. That's how I know that they're communicating. That's how I know they understand me. And from that point, we could go anywhere.

Chrome Fail

You may have heard the Google released a browser into the market today. Everyone is pumped about it for a myriad of reasons, but it's mostly a new pony with old tricks:

• "I have a minimalist UI"
• "I'm faster"
• "I have a cool UI gimmick you'll love"
• "My address bar does more than your address bar"
• "I'm open source because open source is good"
• "I have better security"
  and so on.

At the end of the day it's deja-FireFox 1.0 all over again. Now that FireFox is hitting v3, it's got add-ins and all kinds of bloat you can tack on to your browser to get it to do the things it could have done out of the box. Awesome, thanks Mozilla. These ideas aren't new, all Google has done is created yet another web page viewer. And I should note that despite their "rigorous testing" it still eats web pages like they're going out of style and poops them out when it renders 'em.

But that's just the thing, it's time for web pages to go out of style. This is where I hoped Chrome would be a champion. I read that it had features tailored to Web Applications and that's where I got my hopes up. Instead of a series of linked web pages, an application that has a state, that makes server calls to update parts of the content. No more does a single URL point to a single resource, but rather an aggregation of all kinds of information. It's what frames tried to do back in the 90's and the iframe tried to do afterwards. It's what Web Services are built for and what AJAX should be able to rock hard if cross-domain issues didn't get in the way.

Chrome does not do anything special for the future of the web. All it does is create shortcuts and strip out the forward/backward buttons and conceal the address bar. "Hold on, let me put on my party hat! ... hey wait! Couldn't we do that already?" The answer is yes. Now we're using the desktop/start menu/quick launch bar as a bookmark folder, neat.

For clarity, it's a decent enough browser. I'm all for the JavaScript virtual machine that should make it less painful on users when I want to write out a thousand list items in a loop, and I like Google products, and I like a lot about the memory management and security. What I don't like is that Chrome aimed to be something really good for the web, and it turned out to be just another player, not a leader.

We need a leader. Matt will sing the praises of architecture like Adobe Air and Silverlight try to accomplish. But they lack adoption. The web is stuck in a page being a page, and not an application. The world is stuck on "navigation" and bookmarks and addresses. It doesn't realize that if it just got out of the way that "Web 2.0" wouldn't be just a buzz word, and that you really wouldn't need software or storage or much of a computer at all to be able to do all of the things you do on a regular basis. Just a network connection, and we'll take care of the rest.

Obfuscated Units of Time

Call them NUTS, Gummi Bears, T-Shirts, or whatever. If you can convert them directly to time you're doing your estimation WRONG. Let me say it another way: Estimates from developers do not correlate to the time expected to complete the feature.

Estimates from developers represent relative complexity among stories. For example "Feature A is twice as complex as Feature, B and since we said A is a relative complexity of five, Feature B is a ten".

And for the most part, assigning relative complexity is easy to do with little detail from the customer. "Gee, that sounds like all my User Stories!" Bingo.

BUT! (I know what you're thinking) Money is time, time is money. If I try to tell a customer or product owner "Well it's about 2,000" their first question should be "2,000 whats? What's the unit? How long will it take?" He wants time. The truth of the matter is you don't know. "They'll never buy anything from me if I can't give a time estimate." I know, trust me.

The tools Agile/Scrum provides for converting complexity to time are based on one thing: experience. The main tool you want to use is your Burn Down Chart which relies on a secondary tool, velocity, to predict when a team will finish a set of stories based on how they did in previous iterations in this release. After just one iteration you have a conversion factor from complexity to time, and it just gets more accurate as the release goes on.

Yet there's one spot, one tricky spot, the most important spot, the beginning. No work has been started, you have no velocity, but the customer needs to know if this is going to take five months or five years. Lie. Just kidding. Do the same thing that you always do, pull from your experience. Chances are your team isn't brand new, they've done similar projects, you can guess (the double that number) and start there. Consider a web project consisting of a series of forms with four team members. That's kind of like the project you did last year for another customer. There it had a complexity of sixty, and it took six months. Here we have a complexity of eighty, so one could come to the conclusion that it might take about eight months, so you pitch sixteen to the customer, and get started. Hopefully velocity will start to show that you will finish in eight, but if not, you have a good buffer to work with.

Remember, the conversion factor from estimates of complexity to real time is experience and the Burn Down Chart is you slide rule.

Monkeys Know Best

http://www.safetycenter.navy.mil/Articles/a-m/monkeys.htm



The idea behind this article is that without communication, knowledge is lost. You say, "Duh!" I say "What are you doing about it? You say "Oh... ummm..."



Right.



So in the article, the monkeys soon find themselves doing an action without ever knowing the reason. What's to stop the next monkey from coming in and saying "You guys are stupid! I'm gonna just change this." Every developer has faced that situation, "What's this piece of code doing here? I'm going to change it!" and next thing you know you've got a bug in your product that got fixed a year ago (but not if you use unit tests to test your bug fixes and you run those unit tests every time you check in code!).

So you need to communicate the history of things. In code we can do it through comments, or unit tests as I suggest. But what about bigger decisions? Why'd we only go half way on this feature? Who don't we park in the spot next to the street? Why don't we come in to the office before 10AM? Maybe time got cut short because the market changed, maybe the street cleaner comes by on random days and Bob learned that the hard way, maybe if you come in before 10AM then your schedule doesn't overlap enough with the rest of the company to make you an effective developer (or maybe it overlaps too much and you can never get anything done).

So we have tools now that help us pass on knowledge. Some are software tools like a Wiki, or a version controlled document management system (which might be the definition of a Wiki) that help us with history that someone might search for. Stuff you don't expect people to remember the details of. We also have other tools that help us transfer knowledge so that we can go on vacation and know that our feature is in good hands. "What kind of tool does that?!?!" you say?

Pair Programming is just such a tool. You sit, she sits. You write code, she writes code. You talk, she talks - and it's not all about code. You learn from each others' experiences, both code related and otherwise. You figure out how to better communicate with your boss, and you learn that you should always use a finally statement to clean up your objects that implement IDisposeable.

Meanwhile, you stay on task instead of checking your GMail, or http://fark.com, or to go vote at http://stackoverflow.com, or to wander around to talk to people... you are talking to someone already. So you're more productive, and when you get stuck, chances are that your partner is ready with a solution. It also gives you some added confidence, now you have two people who think the code is good instead of just one. You'll know that confidence is well placed the moment your partner asks you "Hey what about this edge case here?" and you go and write code to handle it.

It's not something that comes naturally. It's hard to give up your privacy, and have someone "sitting over your shoulder" all the time. But when you try it, when you do it, and you experience the difference, you'll never want to go back.

Do What You Do

It's hard, many of us are working for companies where there isn't a "Button UI Guy", heck I'd venture that most of us fight just to have QA people, let alone specialties. So we're forced to wear a bunch of hats and we like saying "Yes", that's how we got here in the first place. But what about when you should say "No" for the good of the company?

Dan is the CEO of Widget Co, and was meeting Raphael for drinks one night. They got to talking business as they always do, and some guy slid over and said "You're the CEO of Widget Co? What do you guys make over there?" To which Dan, with a confused look on his face, because the answer seemed obvious, said "We make widgets at Widget Co, hence the name...", and returned to his conversation with Raphael. But the stranger persisted, "You see, my wife works for you, and all she talks about is the gizmos she has to make, not widgets." Dan was clearly upset now, "Why yes, gizmos are a feature of the widgets we make at Widget Co." Now the stranger had him, "So you make gizmos at Widget Co.? That doesn't make sense." Raphael at this point made a hasty exit with a woman he met earlier and Dan just stared at the bottom of his all-too-empty glass and replied simply by sighing.

It happens everywhere in all industries. The key is where your expertise lies. It may be a natural evolution for a stainless steel company that usually ships unfinished steel to start making finished goods. But is it a reasonable extension for a law office to also offer lawn mowing services? Probably not. At Passageways, when we saw that we had a need for a search engine we knew it was outside of our expertise, we were a web-based portal company, not a search algorithm company. It was time to get outside help, and we did.

Knowing what you do, and doing it can be two separate things. The cause for disparity is often listening to customers "too much" and letting them steer you on their individual needs while losing site of the company's goals. Don't get me wrong, customers should have a voice that does not fall on deaf ears, otherwise you can kiss your revenue goodbye, but those voices need to be reconciled with the overall vision so that healthy decisions can be made, such as asking Gizmo Inc if they'd be willing to sell us some gizmos so we can get on with the widget making.

The Basic Design: MVC

As software developers, we have to make design decisions constantly. Something seemingly as simple as a bug fix can raise questions regarding design. I know that while Will and I analyzed the problems we were confronted with, we always ended up with the same general design guideline: Separate the business logic from the user interface.

I understand that this isn't a ground-breaking discovery, but it's something that all developers I know have learned the hard way. In fact, the Model-View-Controller Pattern (MVC) is the de facto design for the aforementioned solution. Unfortunately, the pattern doesn't spell out the class definitions and their interactions specifically. Instead it leaves those details to the developer. Hence, it's specification as a pattern. Not to mention the slight variations of it's definition a developer will find when typing "MVC" into the Google search box. I'd like to explore this pattern and describe a possible implementation in C#.

Before I do so, I feel it's appropriate to mention that the ASP.NET team has created a MVC Framework, which I will not be discussing in this blog.

First, let's define the problem. We have an application that doesn't have a clear design to it and we've been asked to implement a feature that adds, removes, and updates users and roles. Roles can contain many users as well as many roles. The users and roles will be used throughout the application and we know that maintenance will become an issue if we don't start thinking about the overall design.

The first step is easy: Define a User class and a Role class.



Now that we have the objects defined, we have to understand how interactions with these objects will take place. This is where the user interface comes into play. Several UI objects (windows, dialogs, etc...) need access to the objects.

Since the UI needs to display the users and roles as well as have an interface for adding, removing and updating them, we can certainly create instances of the objects all of the UI classes. If we do this, we soon realize that every time we add a user to a role, we have to call the appropriate methods elsewhere in the UI code to persist the changes. This becomes problematic because every time we add a UI object, we have to call methods on those objects as well as have references to them.

Example code in one of the UI objects:

private void OnAddRoleClick(object sender, EventArgs e)
{
Role newRole = new Role();
m_Roles.Add(newRole);

m_SomeInterface.AddRole(newRole);
m_AnotherInterface.AddRole(newRole);
}

What if a third UI object is created that is interested in roles? That object will also have to maintain a role collection, pass it's instance passed to the two existing UI objects, and expose public method to add have roles added to it. In other words, for every UI object added, every existing UI object must be updated. This isn't going to be easy to manage in the long run.

Now is a good time to separate the business logic from the UI. To do this, we will create one object that manages the user and role objects and pass an instance of it to the UI objects. Lets call that object "Application."



The Application object represents the Model of the MVC pattern. We already have the View of our application defined by the UI, so now we have to connect the two. This is where the Controller comes into play. The Controller is responsible for responding to events and invoking changes to the Model. In C#, this can be accomplished by raising events from the user and role classes and handling UI events to update the Model in the UI objects.

Here is what the Model will look like with the new Application class and the appropriate events exposed:


All we need to do now is pass an instance of the Application class to the UI objects, handle the UserAdded and RoleAdded events in the UI code, call into the Model from the UI when the user adds roles and users, and we're done! Well, not really. With most design solutions comes a number of smaller design problems. I'd like to explore some of those problems in my next post: Object Models and the Observer Pattern.

The Power to Self Manage

"Ok, so we're using Agile and we're now a self-managing team. Sweet! Soooo, what's with the suits still hanging around?" It's a valid question, and if things are going well, their role is much different than in a traditional environment.

But what about when something happens that the team can't resolve internally? Say a personality conflict, or maybe team morale has dropped so low that no longer is "for the good of the team" good enough. That's when you need help.

In the case of a personality conflict, some suggest that the team can vote someone off the island. In that case, the team has the power to remove a person from the team who has become an impediment. But a team can't fire a person, only remove him from the team. So that person has to go somewhere, this is where management helps [or doesn't help]. If management can't provide him with a place to go, he's going to stay on your team and everyone suffers. If management forms a new healthy team, then you're all set, everyone wins.

In the case of low morale, where a team no longer functions well enough to solve even the smallest of impediments, an outside hand is needed. Sure, it is possible that the outside hand is part of the reason the morale is low, but who better to solve the problem? Everyone makes mistakes, and everyone gets the opportunity to fix them.

Keep in mind, that management shouldn't step in every time "for the good of the team" isn't good enough. The idea is that a team is self-organizing, and draws on the creative solutions of the creative people that make up the team. Their solutions of a four person team are expected to be better than the results of four individuals working on the same problem. Collaboration makes them better, and the struggles they overcome makes that bond stronger.

So when should management step in? The answer is simple, but sometimes hard to identify: When the team fails to identify a problem. Individuals may have identified a problem, but if the whole team doesn't agree that it needs solving, then this is when management needs to step in. We had a situation where there was clearly a conflict within the team. As usual, we were allowed to work it out, so after a sprint, we talked (and drew) it out. The result of this particular discussion was that the feature specification we made up front wasn't being followed, and two members viewed this as a problem, one was indifferent, and another thought that everything was fine. The team did not agree that there was a problem, and thus created a problem for two of the members (Matt and I) who felt that the feature spec needed to be adhered to, or revised as a group.

This is a perfect time for a manager to step in. His job at that point would be to determine if the problem did exist. He'd have to listen to both sides, and then make a call based on the company's history and goals. Chances are he was there when the feature spec was put in place, and knows the issues that arise when there is no documentation of discussions. But he might also say that the feature spec is antiquated, offering no value outside of the team, so something more valuable to the company might be suggested.

The bottom line: A team usually does an amazing job of solving problems that affect the whole team. The team struggles when a problem affects a part of the team in a negative way, but another part benefits from it. This is where management plays an important role, and their action or inaction can greatly affect the health of the team.

Location, Location, Colocation

In my experience, the team that "eats together, wins together", or something along those lines. It's tough get the most out of a team if you're not working together. The problem is not solved simply by having the team in the same building, they have to be in the same room, without full walls. When working with Matt, we had half walls, you could be sitting, and see the faces of everyone, but your got a little privacy for what was on your desk, or on your screen.

The problem compounds when part of your team is in a different timezone. Staying in the US with as much as a three hour gap is detrimental to an eight hour work day, but what if your company has paired you up with an off shore team in India? Sure, it seems great to have people working on a project nearly 24 hours a day, but the reality is that there's no reason four people can't do the same work in an eight hour window as two can in one window and another two in a second window. The detriment is when you need a question answered. For instance, let's say it's Friday morning, and you just checked out the latest code from source control (you do have source control, don't you?). You were all set to finish up a user story today before going home for the weekend, when you realize that your counterparts in India decided to refactor three classes. Nothing is where it was before, and they didn't send you any kind of help on how to use the new set up. You could:

• Call them. The company is more than willing to foot the international phone bill.
• Send an email. You can be a little more clear and concise to help the communication barrier.
• or you can spend the time yourself to figure out what the hell is going on.

You best option is surprisingly the third option (or you could work on something else). Because of the time change, team India has already gone home for the weekend. You'll get your response sometime on Sunday. It'll be Monday before you can get anything done.

So the question you have to ask yourself is this: If it takes that long for a team member to get work-related information, how in the world can I expect the team to develop the comaradarie and trust it needs to be highly effective? You simply can't.

Occasionally, I was brought on to help interview candidates. I knew someone else had an interest in seeing if the candidate could write code, so I never asked many technical questions. I was always after the team fit. "Can I talk to this person?" "Does this person speak in a way that is constructive?" "Will this person be able to learn from and teach me?"

This often showed itself with a much simpler question: "Does this person laugh at my jokes?" If she didn't laugh, I knew right away that we'd have trouble communicating. It might have been a language barrier, or a subculture barrier? Sometimes my humor is lowbrow, but that's the way the team works on a daily basis. It happened more than once that I said a person was not a good match, "a 'No Hire' situation" as I now say in the hiring market, but I was told that culture fit isn't as important as I made it to be. In each case, the person hired was not successful in his/her job (and was usually let go or repositioned shortly after). I'd take someone eager to learn with a good team fit over a brainiac-thorn-in-my-side any day.

I've gotten slightly off topic but the point is that the team has to work together. In an Agile software environment, a team is not a group of people who meet once a week. It's a group of people who share the same work. We all own the same code, the same successes, the same failures. This isn't true in other departments where victories are the result of an individual's efforts. This is also why it's tough for management to understand why you need a big room with all of the team together all of the time. I'm not saying there can't be a side room for personal phone calls, but when you're working, you need instant access to the knowledge of the team. You need to be able to collaborate at any point in the day. You need to know these people, and know that you can trust them to do their job, and ask for help when they need it, and ask early.

The key is to have a physical presence in the same area as the rest of the team. The barrier to pop your head up and ask the guy on the other side of the table is insignificant to looking up a number, picking up the phone, dialing the number, waiting for the off-site guy to answer, and so on. A man in Waterloo worked around this disparity by getting a robot with a monitor, speakers, and web cam to drive around the office. He may not have been in the office himself, but all the components for people to interact with him quickly were there. If a time change is an obstacle, then consider shifting your office hours to match, devs love to sleep in, but families can throw a wrench in this work around. If all else fails, just split the team. The people that can work in the same space at the same time are one team, the people on a different schedule/location form a different team, or work solo. In the end, your teams need to be with their team mates, and they need to be able to leverage those team mates at the drop of a hat.

Time Box

I'm sure one day I'll move away from being a developer and move into being more of a process consultant of some sort. In every job I've worked at I always try to find better way to get work done. It has resulted in numerous conflicts with management, and it has also resulted in some great successes. At my job with Matt, I was lucky enough to experience Agile. For those not familiar with the concept, I suggest you get familiar with it - it's the best way I've found for a developer to feel good about his job.

My most recent success in applying a process is in the selection of this blog space. Matt had invited me to blog with him on developer related topics. I had been wanting to blog on a place that was separate from my personal blog about that very same thing. The choice was easy for me, I said "Yes" before I could finish reading his email. He had a day off and had planned to sign us up for a blog on that day. The criteria was pretty straight forward:

1. Must be able to accommodate multiple authors
2. Must be able to paste in code snippets
3. Should be easy to use
4. Should be part of a development community

He looked all day (or at least that's what I imagine), wading through all kinds of blogs. Some were explicitly for devs, but didn't really allow multiple authors on a single blogs since it was like one giant blog with a ton of authors. Others weren't so easy to use and paste formatted text into. The options were overwhelming. So much so, that anyone would be paralyzed by the choice.

Fortunately, there's a mechanism for dealing with such situations, one which is regularly employed by Agile, and more specifically, Scrum. It is called "time boxing". No, this is not seeing how fast you can get through the old school NES game of Mike Tyson's Punch-Out. This is about setting a reasonable time limit to make a decision. The idea is that a certain amount of research is appropriate, but at some point, you just have to pick. Spending four hours and making an OK decision is way better than never starting at all. We want to deliver. And that's just what Matt did, he put a time box on it and he had picked a blog for us to use within a few hours.

The Application: Time boxing is good for forcing decisions that otherwise might drag out unneededly. Let's say every month you have a meeting with management to discuss what to do next. This meeting is aways scheduled to be one hour, but it ends up becoming four hours when everyone chimes in, gets derailed, or just tired. If you enforce the time box of one hour, people will decide what they can in quick fashion. They will table the things that need more investigation (which should also have a time box on them), and everyone can move on. To enforce a time box on yourself, just set a timer. To enforce it on others, you can approach it one of two ways: 1) When the time box has elapsed, simply get up and leave. The first few times, they'll "finish up" without you. But if you're consistent, they'll clue in, especially if you can get more people to leave the meeting with you ("I have to get lunch, pizza anyone?"). Or there's option 2) do it the CEO way, "I've got a meeting at 10:45, so we need to be done by 10:30." This lets people know that the meeting is time boxed and there's nothing you can do about it. The blame is off your shoulders, but people still feel motivated to finish. The trick is, you still have to leave at 10:30 like you said you would. If you box it for 10:30, and stick around till 11, you're not doing anyone any favors.

The pros: Stuff gets decided. You can get started. You don't get stuck in meetings that take half a day and make you want to curl into an anti-social ball when you get home.

The cons: Yes, you run a good chance of not finding THE BEST SOLUTION EVER. But you have to weight finding something that's 90% as good against getting a decision made. If you're coming up with solutions that only meet 50% of your expectations, maybe a longer time box is in order. Maybe you need to reassess the goals.

Remember: This isn't work specific. Any time you get stuck when trying to make a decision, just slap a time box on it.

About Matt

I worked with Matt for about 18 months at Passageways, starting in 2007. I was immediately intimidated. I had worked on web projects before, I had even developed for portals before, but I had also just taken a year off from software to be a fencing coach. I was rusty, and here's a guy who was in my same class at Purdue, and he's teaching me things about software engineering so fast that I feel like I'm drinking from a fire hose.

Having been through a number of jobs in and after college I thought I knew what I was doing. I knew how to use inheritance to cut down on code duplication, I could tie into a database with the best of them, I was at the top of my game, especially for my age - or so I thought. I learned the ropes of the product from my team mate, Dustin. After our project was finished I had a lot of overlap with Matt. I'd check in my code, he'd inevitably have to add something to the same class, and so I got my code reviewed all the time those first few weeks. Things that I knew about, but was lazy about mostly - using the finally statement to dispose of my IDisposable objects, using StringBuilder when I was appending several strings, and so on. And there was polymorphism opportunities that never occurred to me.

I learned to love the white board as Matt had. It's a great medium for team-oriented design, so everyone can see what's being developed and respond to it, instead just assuming the note taker got it all. We both liked it because the design wasn't the responsibility of just one person. Anyone with a good idea on the team for the task at hand could make it better. Instead of an architect, we had a team, who pulled on the various experiences each one had.

At the company, Matt was a Development Lead, a role that wasn't very well defined as to what it was. it wasn't a management of people position. It wasn't heavy in product vision based on customer input. It was often times, providing a product vision based on technology - helping to meet the needs of both customers (as defined by the product owner) and the needs of the developers, leveraging the technology available to us. Often times his biggest obstacle was getting the new technologies set up for all 150+ customers.

After the initial growth, and tightening of my code style, Matt and I struck a good balance. We both had areas we liked to focus on, and for the most part, they didn't interfere with the other's aspirations. When we did cross over, we'd get frustrated just like any other relationship, but we had a strong enough social and professional foundation to always talk it out. Now that I'm 2,000 miles away from Matt, I expect this blog to be an extension of that same dynamic. He has his focus, I have mine, and we'll step over and disagree occasionally, but I expect that's the time when we (both Matt and I, as well as you, the reader) will grow the most.