Recently, I’ve started rekindling my love affair with the Ruby language. One of my favorite idioms is ||=. How many times do you find yourself writing something like:

if (someVariable != null)
{
  // some other code
}

Ruby makes this much shorter and more elegant:

someVariable ||= // some other code

The code on the other side of the equals sign does not get executed unless the variable on the left is null.

I’ve used this syntax in a current Rails project to define caching and also to provide default values to request parameters that may not have been passed.

# caching example
# The code below evaluates whether an instance variable
# named action_regex is nil, and if it is, it initializes
# it to a new Regexp
@action_regex ||= Regexp.new(action)
 
# params example
# this works exactly as above. If the page_size parameter
# is not passed, it defaults to 20. In this particular case,
# we are then calling the to_i method to convert it to an
# integer to be assigned to the page_size variable
page_size = (params[:page_size] ||= "20").to_i

In what is sure to end up as a flame war, Jeremy Miller asks the question: “is there a good reason to switch to MSBuild?“. I want to throw my $0.02 into the mix.

I do not have a compelling reason to switch to MSBuild from NAnt. As pointed out by David Starr in his open letter to Scott Guthrie, what we often times see from Microsoft is a half-assed attempt to implement something that has already been evolved in the open source community without adding any value to it.

MSBuild does nothing to improve on the functionality provided by NAnt. The same way that MSUnit does nothing to improve on the functionality provided by NUnit. Many will argue that MSUnit is considerably worse, actually.

So, why would I switch to a closed source tool, when I can get an equal feature set, with greater community support and quicker response times to questions? Easy… I wouldnt.

Software quality is a very subjective term and means many different things to many different people. Consistently, a part of the definition of software quality includes whether or not the software was delivered on time, and whether or not the software was delivered on budget. The evolution of software development processes has resulted in software that is much more consistently delivered both on time as well as on budget.

The Standish Group is an organization with years of experience in assessing risk, cost, return and value for information technology investments. Formed in 1985, the Standish Group’s vision was to collect case information on real life information technology (IT) project failures and environments to deliver advice based on collective wisdom. In 1994, The Standish Group published The Chaos Report which was focused on identifying the scope of software project failures, the major factors that cause software projects to fail and the key ingredients that can reduce project failures. The Chaos Report surveyed IT executive managers representing all sizes of companies across major industry segments, including banking, manufacturing, retail, and healthcare (Standish, 1994).

The Chaos Report classifies projects into three resolution types. First, successful projects are completed on-time and on-budget, with all features and functions as initially specified. Second, challenged projects that are completed and operational, but over-budget, over the time estimate, and offer fewer features and functions than originally specified. Lastly, impaired projects are projects that have been cancelled at some point during the development cycle. Successful projects account for only 16.2% of respondents, while challenged projects accounted for 52.7%. Cancelled projects accounted for 31.1% (Standish, 1994). To put that another way, 83.8% of software projects that started were not successful.

Since 1970, the most common process used to develop software is called the waterfall process. Initially used for developing computer hardware, it is called the waterfall process due to the way the process emphasizes completion of a phase of development prior to proceeding to the next phase (Sorensen, 1995). The waterfall development process is best known for its well-defined and demarcated phases to development.

According to Sorensen (1995), the waterfall development process strongly emphasizes a formal, top-down model, which is composed of independent phases to be done sequentially. The most common phases to the waterfall model as it relates to software development are planning and analysis, development, followed by testing and deployment. To complete the planning and analysis phase, the expectation is placed on the customer to know all required features of the system in advance. Only when every feature has been planned and analyzed are the software engineers engaged to develop the software application. Once the entire software application has been developed it is turned over to a quality assurance group to perform testing of the application.

Certain strengths have been identified to support the waterfall model for software development, including reporting capabilities, workforce specialization and the ability to predict resource allocations. However, the stronger weaknesses discussed above have led to recommendations like “the application of the waterfall model should be limited to situations where the requirements and the implementation of those requirements are very well understood” (Sorensen, 1995).

In 2001, several prominent software developers, including Martin Fowler, Ward Cunningham and Alistair Cockburn realized that there were many inherent problems with the waterfall model and sought ways to make the software development process more nimble, or agile. This group came together to form the Manifesto for Agile Software Development. The Manifesto for Agile Software Development (2001) is committed to “uncovering better ways of developing software by doing it and helping others do it”. To this end, the manifesto defines four core values which are intended to enhance software quality. First, agile methods value individuals and interactions over process and tools. Second, working software is valued over comprehensive documentation. Third, customer collaboration is valued over contract negotiation. Lastly, agile methods prefer responding to change over following a plan.

There are two primary differences between agile and the waterfall models. The waterfall model is very predictive as it tries to anticipate every requirement prior to beginning development. The predictive model works very well until things change, so very often waterfall models are resistant to change. Agile methods rely on an adaptive model for developing software, in which the development of the software applications adapts to changes in customer requirements. Agile methods welcome change, adapt and thrive on change, going even so far as to changing themselves. The second primary difference between agile and waterfall models is that agile methods are people-oriented rather than process oriented. The waterfall model is intended to work well by anyone implementing it. Rather than try to be all things to everyone, agile methods support the development team by allowing them to respond quickly to change. (Fowler, 2005).

There are numerous agile development methodologies, although the most common methodology uses a combination of Scrum for project management and Extreme Programming (XP) for specific practices that software engineers can use in their day-to-day tasks. Scrum is a simple method for the management of complex projects which allows practitioners to embrace change, release creativity and increase productivity.

Standish Group founder and Chairman Jim Johnson (1999) states that there are three metrics that can determine the potential for success of a given project: project size, project duration, and team size. Research confirms that small projects have higher success probability than large projects. Smaller teams and shorter projects have also been confirmed to result in more successful projects. Scrum places emphasis on all three of these pillars.

In conjunction with the founder of the scrum methodology, Softhouse (2006) defines the three primary roles in a scrum team as the product owner, the scrum team and the scrum master. The product owner acts as the voice of the customer and ensures that the team is working on the correct things as they relate to the business. The product owner administers a product backlog, which is “a current to-do list where all the specifications for a product are listed according to how profitable they are deemed to be” (Softhouse, 2006). The scrum team is a group of 5-9 people who function as the problem solvers and designers. The scrum team is a self-managing team; the team members decide how to arrange the work and who performs the work. The scrum master is the scrum coach for the development team. The responsibility of the scrum master is to remove any speed impediments from the scrum team and makes sure that the scrum team has the best possible working circumstances to achieve their goals.

Scrum is centered on what are called iterations or sprints. A sprint is a time-boxed focus on a specific set of goals. Although the prescribed sprint time is 30 days, a sprint can be anywhere between one and six weeks in duration. Prior to the beginning of the sprint, a product owner creates a product backlog, which is a prioritized list of all functionality desired for the product. Once the product backlog is ready, a scrum team forms which contains the people who are responsible for the success or failure of the sprint. During the sprint, discussions are had with the product owner to determine the goal of the sprint and to break down prioritized functionality to the task level. After the team has determined the tasks and required time to complete the sprint, the product owner steps away. Now the scrum team is completely self-managing and collectively responsible to the success or failure of the iteration. Every day, at a time set by the team, the scrum team has a brief meeting with the scrum master. Each member of the team is expected to answer three questions: What has the team member done since the last meeting? What will the team member do between now and the next meeting? Is there anything preventing the team member from doing what was planned? The first two questions provide a commitment from the individual to the rest of the team as well as giving the scrum master insight into the progression of the project. The last question provides insight to the scrum master into problems that the individual is having and serves as a starting point for problem-solving. At the end of the sprint, a feedback or demonstration session is held with a larger group, consisting of not only the product owner, but also users and corporate representatives. This session serves as the starting point for the next sprint (Softhouse, 2006).

Scrum has done very well to establish itself as an effective project management tool for software development. Extreme Programming operates more at the tactical level and provides guidelines for how the team develops the software. Certain principles, such as user involvement and daily meetings, dovetail into the scrum philosophy as well. The benefits of XP as an agile method to develop high quality software are found in the principles around the coding and testing phases.

In the coding phase, XP states that code must be written to agreed standards to help keep a consistent format. Consistent formatting makes understanding the code easier and quicker for everyone on the team. In addition, all production code is written by a pair of developers working together at a single workstation. Some people will argue that this is counter-intuitive, but these two people working at a single computer will produce as much functionality as two working separately. The difference is that the quality of output will be much higher, because the pair is consistently getting feedback by having two sets of eyes on the project. Lastly, XP emphasizes a collective code ownership paradigm which allows any member of the team to add functionality or fix bugs. In this way, no single person becomes the bottleneck. The strong benefit from this is that the entire system is not held in the mind of a single person but rather the collective mind of the team (Wells, 1999).

In the testing phase, XP emphasizes unit tests on all production code and all code must pass all unit tests before it can be released. Unit tests are defined as a piece of code that tests the production code in the system and makes sure that the code under test performs exactly in the way that it was intended to. Developers working in an Extreme Programming model very often will write unit tests first. A developer will create on test to define a small aspect of the problem, after which the developer will create the simplest code possible to make that test pass. After that a second test is added, and once again, the developer writes the simplest code possible to make that new test pass. This continues on until there is nothing left to test, at which time the developer knows that he is done. The advantage to writing tests first is that at any time the overall quality of the software system can be known (Wells, 1999).

Research published by The Standish Group in the previously mentioned Chaos Report states that for successful projects, 15.9% of the respondents believe that user involvement was the primary cause for success. 13% of respondents believe that a clear understanding of user requirements was the primary cause for success. In projects that were ultimately delivered but were late, over-budget, or some other way devoid of the initial expectation, 12.8% of respondents believe that lack of user input was the primary cause for the project being challenged. 12.3% of respondents believe that incomplete user requirements were the cause. In projects which were cancelled, the numbers are very similar. 13.1% of respondents believe that incomplete requirements were the cause of failure, while 12.4% believe that lack of user involvement were to blame.

Agile development methodologies address both of these causes of project failure. Jim Johnson (2006) states that he is “a big believer in Agile, having introduced the iterative process in the early 90s and followed with the CHAOS reports on quick deliverables”. Agile development has helped by breaking down projects into manageable pieces. If something goes wrong, the organization is aware of it early rather than much later in the project. Constant interactions with the user of the software leads to building exactly the software that the user is expecting. The adaptive nature of the agile development methodologies ensure that when a customer does change their mind, the development can continue effectively, without major effects on the timeline or on the budget. The iterative approach that agile development emphasizes in conjunction with the constant feedback that is solicited from the customer makes this methodology very effective in delivering high quality, on-time and on-budget software.

References

• Fowler, M. (2005, December 13). The New Methodology. http://www.martinfowler.com/articles/newMethodology.html
• Johnson, J. (2006, August 25). Interview: Jim Johnson of the Standish Group. http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
• Johnson, J. (1999, December). Turning Chaos into Success.
• Manifesto for Agile Software Development. (2001). http://www.agilemanifesto.org/
• Softhouse. (2006). Scrum in Five Minutes. http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
• Sorensen, R. (1995, January). Comparison of Software Development Methodologies. http://www.stsc.hill.af.mil/crosstalk/1995/01/Comparis.asp
• Standish. (1994). The CHAOS Report. http://www1.standishgroup.com/sample_research/chaos_1994_1.php
• Wells, D. (1999). Extreme Rules. http://www.extremeprogramming.org/rules.html

OJ Simpson comes through once again. Not only is he involved caught on tape in an armed robbery in Las Vegas, but addresses his situation with probably the stupidest quote ever.

“I’m not walking around feeling sad or anything. I’ve done nothing wrong. I’m having a great time. Besides, I thought what happens in Las Vegas stays in Las Vegas.”

Wow… After being charged with 7 felonies, the best you can come up with is “I thought what happens in Las Vegas stays in Las Vegas”. I’m not even sure what to say to that. This has been quite a downward spiral for this once-great athlete.

Is it a fair assessment to state that organizations that utilize platforms other than Microsoft Windows are much quicker to install security related operating system patches?

I’ve found over my career in the software engineering field that organizations are typically very slow to install new security patches from Microsoft simply because they are not sure of the impacts of a particular patch. Very often, it seems that patches come through to fix previous patches. This must not help the credibility of the patch concept. If a patch is installed and it breaks something else, pretty soon, I’m going to be conditioned not to install patches (ala Pavlov’s dog).

I understand that mistakes happen occassionally, but it seems like more often than not, a Windows patch has very unintended consequences. We saw this earlier today at a client site. A client had ran a particular IE security patch to get past some display issues that they were having with our web application. The patch fixed the display issue; however, every time an AJAX request was executed, the browser would crash because a buggy version of jscript.dll was delivered with the original patch. So, now they had a patch (KB917344) for the patch (KB937143).

Not to say that Apple or Linux are off the hook for this either, because I, personally have had issues with an Apple security patch affecting my application. Not long ago, an OSX security patch broke the USB support in Parallels. However, the problem was not with OSX, but rather a workaround that Parallels had put in, which was no longer required.

I’m anxious to hear from other people out there: Do you have Automatic Updates turned on? If not, why? Would you have automatic updates turned on if you were running an OSX or Unix based operating system? Why is this different?

I moderate all comments posted to this site to protect readers from inappropriate content. One of the best spam comments I’ve seen came through my email box earlier.

hello , my name is Richard and I know you get a lot of spammy comments ,I can help you with this problem . I know a lot of spammers and I will ask them not to post on your site. It will reduce the volume of spam by 30-50% .In return Id like to ask you to put a link to my site on the index page of your site. The link will be small and your visitors will hardly notice it , its just done for higher rankings in search engines. Contact me icq 454528835 or write me tedirectory(at)yahoo.com , i will give you my site url and you will give me yours if you are interested. thank you

The best part of this is that the comment was posted to one my most spammed posts, so I can’t help but wonder if this was a comment from the spammer himself. The extortion attempt is a nice touch.

By the way, Richard, you made my index page. Probably not the way you wanted, but nonetheless. As far as your offer goes, thanks, but no thanks. Akismet seems to be serving me just fine, thank you.

We are probably one of the very few organizations in the wild that is actually using TFS for our source control system as well as backlog items, etc. We are really striving for an end-to-end TFS solution.

Coming from a CVS/SVN background, the one thing in particular drives me bonkers about TFS’s source control system is its insistence that I check something out prior to being able to work on it. There are very many times when I would like to just touch a file on the file system, and not fire up my IDE to do so.

This checkout/commit (aka VSS) model of source control can be likened to having a box of floppy disks somewhere in your building. Whenever you need to modify a file, you have to go get the floppy disk and take it back to your desk. Once there, make your changes and then return the disk to the central storage. If you go on vacation, you also have to make sure and either return all the disks, or make a copy of the disks, so that other members of your team can continue working.

Contrast this with the SVN/CVS model, where you get a writable copy as soon as you do a get from the repository. Once you have the writable copy, you can make all the changes you want. Only once you are ready do you notify the repository that you have some changes for it. People can work simultaneously on the same file. The only “problem” comes up when two or more people modify exactly the same location in the file. At that point though, basically, the last person in has to resolve his changes with the others.

This seems to be a much more efficient way of getting work done. I’d like to see an option in TFS that allows you to create this model at the server level.

Mladen discusses the performance of List<T>.ForEach vs foreach and finds that the earlier is more performant than other methods of iterating collections. The comments are rather interesting and most focus on the readability/maintainability of one versus the other. The primary argument is that you should prefer maintainability/readability over performance. I completely agree with this.

I disagree with the commenters in that I feel that List<T>.ForEach actually reads better. In addition, the List<T>.ForEach construct stays true to the single responsibility principle. Other classes should not know how to iterate a collection, only that the interface supports it. The calling class only passes a delegate that should be executed on each item in the collection.

I talked about this point in an article entitled refactoring away external loops. The code in the article is .NET 1.1 specific, but the point of the article still applies.

Thank you very much to the person asshole who authored the Win32/Virut virus. You have accomplished nothing short of wasting the past 12 hours of my life by creating a virus that does nothing more than find all of the .exe files on my system and infect them with the same virus. Recursion at its best…

It’s times like this that I curse the internet as well as Microsoft Windows. In all seriousness, what are people trying to do by creating a virus such as this? I know that this question has been asked repeatedly, but I still cannot seem to come up with a good answer to this. If people have the talents to do things like this, surely they could put their talents to good use.