Discovery’s Man vs Wild has been one of my favorite shows on television. I enjoyed tuning in to see exactly what lengths Bear would go to in his quest for surviving areas that many tourists get lost in. I’ve been skeptical of the show for some time, but still enjoyed watching it. For instance, what does the camera crew do? Now, it seems we find out…

This article recently surfaced and brought with it allegations from a former consultant that some of Bear’s stunts were staged. Also in the article are implications that Bear is removed from the areas via helicopter to stay in plush hotels, complete with television and Internet access. This article, however does change things for me. I feel ripped off, even cheated.

Discovery has refused to comment which just seems to confirm the allegations.

Microsoft has announced their Secure Content Downloader, which they’re touting as “a peer-assisted downloader for downloading select Microsoft CTPs”.

This is just another attempt by Microsoft to reinvent software that already exists in the open source space, without adding any real value to it. David Starr addressed this earlier this year in an open letter to Scott Guthrie. Examples include MSBuild (instead of nAnt), MSUnit (instead of NUnit), EntLib (instead of numerous other tools), and the list goes on and on.

When will Microsoft get that it’s ok to leverage open source technology. By them leveraging and contributing, the entire development community will be better off. This is what Java has done and you dont have to look very far to see a very tight-knit development community around Java.

Interestingly enough, yesterday, Microsoft also unveiled their new web presence dedicated to their open source efforts. It’s going to be very interesting to see if this new initiative helps Microsoft to embrace the many fine open source projects out there.

Very often, I hear people referring to open source software as any software in which the deliverable includes source code. This is not the case. There is a fundamental difference between free source and open source.

When delivering the source code for a library or application, developers typically are allowed to make changes to the source code to support their particular business needs. Almost never do these changes end up in the core library. The developer is ultimately responsible for maintaining their changes between releases of the library or application.

Contrast that with an open source model, in which developers contribute code to the trunk, or to the main code base for inclusion in a future version. This way, developers do not have to maintain their changes between releases. Supporting the open source project benefits both the developer as well as the rest of the community using that library or application.

There are pros and cons to each. In some situations, a developer may not want to relinquish complete control of the code base. In this case, a free source model will work better. The con to the open source model is that you could potentially end up with a library full of features or components that nobody is using. The key to solving this is to look for open source projects that are very well managed, such as nHibernate or castleproject.org.

Yesterday, Phil Haack challenged users of Open Source Software to contribute to their favorite projects. I strongly support Phil’s campaign and have pledged myself to contribute to open source tools that I use on a regular basis. It’s a very important way to keep your saw sharp.

I’d like to take Phil’s challenge a little bit further and challenge users to contribute to open source projects that they use once per month. This contribution can be financial (as little as $1 goes a long way). The contribution can be a bug fix or a code addition. Regardless of what the contribution is, I urge you to do something to support the people that are working hard to provide us with very high quality free software tools. This is the least we can do to ensure that the libraries we use will continue to evolve.

This morning, I happened to be driving through downtown Boise to make a stop at my bank. I noticed that the new high rise next to the bank had a picket line. People in the line were holding signs and chanting something like “CCI does not pay area standard wages and benefits”.

I thought more about that and realized that I really don’t get what strikes and picket lines are all about. These people knew what the wage and benefit package was when they signed on. I’m positive that this was not kept secret from them. They made a decision to go to work for this company for a set wage and benefit plan.

Now, if the picketers are dissatisfied by the pay or benefit package they are receiving, why wouldn’t they go find a different organization to work for. Wouldn’t that punish the offending company in the same way? As more people find out that this company doesn’t pay area standard wages and benefits, and more people leave said company, they would have to either adjust their wages or go out of business since they wouldn’t be able to find any employees.

If these people are upset by their wages, they should go find another company to work for instead of marching and chanting in front of a job site. Picketing seems like so much wasted effort.

Teams working under a scrum model very often talk about the relentless pace of scrum. There seems to be a constant pressure on getting new work done. So much so, that a lot of teams feel that there is no time allowed for personal development/technology investigations or even refactoring of the systems the team is responsible for.

Typically, teams in scrum, get a group of stories from the customer. The team is then expected to execute on these stories, getting them completely developed and tested prior to the end of the iteration.

What gets lost, often times, is the realization that the teams are not responsible for delivering stories. The teams are responsible for delivering a system. The outcome of a particular sprint/iteration is not a group of completed stories, but rather a high-quality system. Once that paradigm shift happens, then it makes it very easy for teams to find time to accomplish some of the things that they previously thought they were unable to do because of scrum.

Teams have a fair understanding of the amount of technical debt that they are accruing interest on. It is perfectly within that team’s right to take on fewer stories so that they can address the technical debt.

It is important that teams realize that they control their own velocity. The teams dictate the amount of work that they will take on for a given iteration. Teams should certainly be allowed to take on a little less new work to address some technical debt.

We, as agile development managers, need to encourage teams to deliver effective systems. It is not conducive to measure teams on velocity alone.

I just do not see what the hype is about Twitter. I’ve read several articles that state that Twitter has the capability of replacing blogs. I look to blogs as a source of information about new technologies. Twitter simply looks to answer the question of “what are you doing right now?”.

Frankly, I have enough technological stimuli in my life. I dont need to know when so-and-so has a soy vanilla, half-caf latte. I’ve been considering cutting back on the technology in my life, but that is another post. :)

Am I missing what Twitter is all about?

As part of one of my COM classes at school, I need to write a 2500 word research paper. The thesis of this paper is that the process of writing functional software has become much easier with the advent of sophisticated tools which are intended to make the software engineer’s life easier. I’ve been doing a significant amount of research at the University library and stumbled across an article from the June 10, 1996 issue of PC Week. The article was entitled, “Software slips out of the primordial ooze (the evolution of software development)”.

What caught my eye was the last line in the article:

Over time, browsers will not matter for Net applications–Java will. Java is the integration platform, and like Navigator plus plug-ins, we’ve now moved to Java plus ActiveX. We’re evolving. Darwin would be proud!

I’m not exactly sure why this made me chuckle as much as it did. Most likely because of how Ajax has really solidified the browser as an application container. More and more full-fledged applications are being made available to me via my web browser.

This is one of the reasons that software development field is so interesting. I cant wait to see how today’s current articles will look 10 years from now.

Alex Mueller posted an article the other day that talks about the ASP.NET page life cycle and focuses specifically on occasions where OnPreRender may or may not be called.

Alex’s post just reiterated to me why I choose MonoRail over the WebControl model every time. With MonoRail, I have true separation of concerns. With MonoRail, I have views that are responsible only for presentation. With MonoRail, I don’t have to worry about a complicated page life cycle. I dont have to concern myself with which method I need to override to get my control to render properly. I dont have to worry about overriding a different method to do the same thing when the control’s Visible property is set to false.

MonoRail does everything that a framework should by making the developers day to day tasks easier. Since I’ve made the switch to using MonoRail, I no longer have to use .NET Reflector to try and understand why some piece of code isnt working the way I expected it to. I also dont have these wierd bugs popping up anymore, because the testability of the controllers in MonoRail is much, much better than the web forms model.

Thanks, Alex, for your post. Your post reaffirmed my deep dislike of the web forms programming model. Thanks to the Castle devs for making a much more intuitive framework.

How do you help an agile software development team become more productive and more “agile”?

I think the answer lies in the agile manifesto itself. We value “individuals and interactions over processes and tools”. This right there tells me that you need to empower the team to come up with the process that works best for that team. I feel strongly that this is why you rarely find strong direction in how to do agile software development. Sure, you find plenty on what you should be doing, but how is so different per team.

Most software development teams really want to do the right thing. So, the question is, why don’t we empower the teams to choose their processes? If they want to change something, they should feel free to.

Since each team has a different dynamic, does it make sense to prescribe agile to multiple teams in the same organization? Does it make sense to prescribe agile to teams without giving them a voice?

I think not… Agile development is not something that you can do “by the numbers” throughout your organization. Each individual team is going to have slight variations and needs to make the process successful for them. The core part of agile development is the team, and trust has to be placed with that team that they will do the right thing. If you don’t or can’t trust the team to do the right thing, then you have a bigger problem than evolving agile development.