Fervent Coder

How about doing a full regression of the system under development every ten minutes?

Second Day Automation Testing

One of the things I neglected to mention (on purpose) in my End2End post the other day was that you also test for the second day.  In this test you are sending in new items and updating some existing items. You also leave some of the items from the first day completely alone to see what happens to them.

This is done in the same way as the first, except you look for a second input file (Input_Update) to move to the application and a second results file (Results_Update) to compare the second day to.  This is the equivalent of finding out how your application will behave when presented both new information and information it receives of already existing items.  Does it update all rows or only certain rows as defined by your business rules?  What about existing rows with no updates? Do they get deleted or not? Does the system work correctly in this aspect?

Why Automated End2End Testing?

The interesting thing to note here is that this testing is no different than QAs (quality assurance) / testers do anyway.  This kind of testing is nothing new.  Every self-respecting tester worth his/her weight does all of this.  MANUALLY.  BUT, and this is big, but we have so much information to verify sometimes that the cost/benefit of verifying everything is not there. We are presented with so much information and scenarios that it would take WAAAAAAAYYYY too much time to verify everything, so instead we sample certain areas and tend to miss things. Actually "tend to" is not correct. We miss things sometimes.  It just happens. We just can't look at it all manually and justify the cost of it and the sheer amount of time it would take.

Now can you imagine having to do a regression test of the system before a release? Think of one module with 400 scenarios and another module with 250 scenarios.  How long would that take someone if they were doing a full regression?  That's right, a LONG time.  I would go so far as to say because of the costs and time, people in software development either don't do them or only do them very infrequently because they absorb weeks of your time (usually right before a release).

How about doing a full regression of the system under development every ten minutes?

Up until now this concept for us has been unheard of. If we automate the process with verifying the results against expected results given particular inputs, we black box the system in the same way that a tester would.  But now the expected results are not in the QAs head and on the test scripts which have to be manually verified and prone to human error. The results are in files and every row, every column is checked for correctness. Every Row. Every Column. All checked and verified. Not just a sample. 1 item, 20 items, 10,000 items. Every single piece of information verified for correctness. Now imagine the possibilities of doing a regression whenever you feel like it or multiple times a day!!  Imagine saying this as a tester:

I just regression tested over 4,000 different scenarios in ten minutes and only had two places that we need to look at. 

Minutes! Not weeks! Minutes!!!! The testers I know salivate at this concept.  End2End is not a system for developers, it is a system for our testers to help us ensure we have better software in the end. To fully realize the benefits of what this could provide your testers, share these articles with them.  Find out how they feel about it.

Isn't This Like Fit/FitNesse?

Well, End2End is kind of like Fit, but not really.  The ideas behind Fit are the same as the ideas behind End2End. From Wikipedia:

It integrates the work of customers, analysts, testers, and developers.

From C2:

Fit is a tool for enhancing collaboration in software development. It's an invaluable way to collaborate on complicated problems--and get them right--early in development.

Fit allows customers, testers, and programmers to learn what their software should do and what it does do. It automatically compares customers' expectations to actual results.

End2End provides the idea of the same great collaboration between users, testers, and programmers with the same core concepts as Fit. Fit/FitNesse are different because they can cut sections of the system and test there.  They don't automate the actions a user or tester would take to run the system. The benefit of this is that they give testers the ability to white box test the system a little more.

I believe there is a place for white box tests, and that is with unit (logical) and integration testing done through frameworks such as NUnit, MbUnit, MSTest, etc. As good developers who are Test Driven, we have already completed testing many of the scenarios that Fit/FitNesse fit into.  It is much easier to maintain tests in these other test frameworks, and if we are already doing these kinds of tests with unit and integration testing, then why do we need to repeat the process with Fit/FitNesse (and violate DRY)?  If we have good reporting with MbUnit's framework, and soon with Gallio's Universal Testing Platform, the results of these tests can be provided as part of the documentation for testing.

From what I have noticed across the industry, Fit/FitNesse is not something people stick with after adoption, for one reason or another.  Perhaps it is maintenance.  Perhaps people are trying to do things with it that it was never meant to do. We tried FitNesse for awhile but decided it wouldn't work for us due to some of the reasons cited here in addition to other reasons.

Back To Basics

With End2End we are testing the system as a whole without cutting into any piece of it.  We get back to the basics of what QA testers do, which is mostly black box testing.  And then we automate it so they can focus on what they really want to focus on.  Breaking our systems.

Subversion (SVN) just released version 1.5.0 recently on June 18, 2008.  With it comes bug fixes and boosts in performance. It is highly recommended that you reference the release notes, and pay attention to merge tracking:

Merge tracking means Subversion keeps track of what changes have been merged where. This reduces the overhead involved in maintaining branches, and gives users a way to inquire what changes are merged — or are available to be merged — on different lines of development.

VisualSVN  responded by releasing VisualSVN Server version 1.5 on June 19, which adds easy configuration of Windows Authentication (and support for windows groups) in addition to some other great new features.  Download here.

TortoiseSVN, one of the most popular clients for Windows,  just released version 1.5 on June 21. Download 32 bit edition here and 64 bit here.

VisualSVN also released their popular Visual Studio Integrated Client VisualSVN on June 21. Visual SVN is not free (unless you qualify), but well worth the nominal fee of $49 per seat.  You must have TortoiseSVN installed (not sure if that means only the 32bit version or not). Download VisualSVN here.

New to SVN?

If you are new to SVN, you need both a server and a client tool installed.  Jeff Atwood has an excellent post on how to set up Subversion on Windows.  I prefer to use an easy to configure server that gives you the option to use the command line as well. Thus, I use VisualSVN Server. I use TortoiseSVN on the client side. I am trying out VisualSVN (VS integration) to see if I like it as well. 

With open source, you can easily get analysis paralysis because there are sometimes so many options.  So let me make it easy for you. Download VisualSVN Server and TortoiseSVN.  You can have VisualSVN Server installed and ready to go in less than ten minutes.  It has a great interface and can get you to DONE very fast. TortoiseSVN is a great tool for client side working with SVN.  If you need the Visual Studio integration, then get VisualSVN as well.

Calling a remote application, you want it to run almost always in its native directory and not against your calling End2End code's directory. Why? You don't want to have to verify whether the application uses or will use any kind of relative paths.  You want your End2End Tests to work in any respect.  So you can implement the basic code for starting a process using the System.IO and System.Diagnostics .Net libraries.

Public Sub RunApplication(ByVal filePath As String, ByVal args As String, ByVal waitForExit As Boolean, ByVal setWorkingDirectoryToPath As Boolean)

     Dim processStartInfo As New ProcessStartInfo(filePath, String.Format(" {0}", args))

     processStartInfo.UseShellExecute = False

     processStartInfo.RedirectStandardOutput = False

     processStartInfo.CreateNoWindow = False

     If (setWorkingDirectoryToPath) Then

         processStartInfo.WorkingDirectory = Path.GetDirectoryName(filePath)

     End If

     RunProcess(processStartInfo, waitForExit)

 End Sub

 Private Sub RunProcess(ByVal processInfo As ProcessStartInfo, ByVal waitForExit As Boolean)

     Using process As New Process()

         process.StartInfo = processInfo

         process.Start()

         If (waitForExit) Then

             process.WaitForExit()

         End If

     End Using

 End Sub

We have started an initiative this year. We call it End2End Automated Testing. The idea is based on a couple of factors. Many times in the past we have not had an easy way to verify our configuration, security and deployment to an environment in an automated way.  The second is that regression testing is a very arduous process for our QA staff when it must be completed.  How do we give time back to our testers and verify everything in a given environment is correct? With automation of course!

So what is End2End Testing? It is a way of taking what we expect the system to do based on our inputs and verifying that against the actual results in an automated fashion.  We influence the inputs into a system so we know what we expect the outputs are going to be.  Then we check those outputs, or actual results, against some expected outputs, or expected results files to see if we have matches. This helps free up the Quality Assurance staff to focus more on figuring out what should happen when a given scenario is passed into the system. 

We make it easy enough for them to focus on "If I pass this into the system, this is what I expect to get out of the system or to happen with the system."  The real benefit of this is an actual automated regression suite with a focus on what if for the QA staff! They get to concentrate more on actually breaking, err, testing the system to ensure it works correctly and meets a level of acceptable quality for the ultimate end users.

End2End testing is not a replacement for unit tests.  You need that quick feedback cycle that you get from those.  End2End is also not a replacement for your integration tests.  Although a little slower than unit (logical) tests, integration tests give you feedback much faster than End2End will be able to.  End2End is not a replacement for your testers. They must really focus on specifications to put good scenarios through the system to accurately tests all aspects of what might happen.

End2End is a strong collaboration between developers and testers.  In incorporating End2End, you will work very closely with each other. End2End is unforgiving. When it runs, it only passes if everything is 100% correct against specifications.  It takes awhile to get expected results built to verify actual system results against.  Once you do, the benefit is knowing the application you are creating is correct up to that point.

Principles of Automated End2End Testing

• End2End must be able to affect the inputs to the system.
• End2End must be able to verify results (possibly in a database).
• End2End will couple to those two points only, but will be tightly coupled to those points.
  • This is really no different than a QA (tester) testing a system under development would be coupled.
• End2End is not actually part of your project at all. It is in itself a mini-project.
  • That means it deserves it's own unit tests to ensure it's functionality.
• End2End should start from a known point for both inputs and outputs (preferably empty starting outputs).
• End2End should be able to be completely encapsulated on a LOCAL developer machine as well as on some remote environment.
• That means you may start some more processes or do a couple more setup options locally than you would in other environments.
• End2End should provide a Reset Test to clean up everything for your users or testers so they can start the process over.
• End2End should include a readme file for both your developers and testers.
• End2End should be helpful in identifying what exactly is wrong for every point that is wrong and possibly provide pointers on how to correct the issues.

How To Do the End2End Test

1. Setup Step1: Automatically set up the inputs.  This could be putting a file somewhere or setting up database tables with scripts.
2. Setup Step2: Optional - Set up network permissions on the remote directory.
3. Setup Step3: Call the remote application, have it execute in the remote directory. Optionally, wait for exit.
4. Setup Step4: Optional - Remove network permissions to the directory.
5. Setup Step5: Figure out the trigger to know when your application is ready. You could put a file watcher or a database table watcher to know when ready. Or possibly, waiting for the application to exit is good enough for your needs.
6. Setup Step6: Make a data table from your expected results.
7. Setup Step7: Make a data table from your actual results.
8. Setup Step8: Remove the columns that you have decided not to verify against.  We call these the ignored Fields.
9. Test1: Verify the total rows of expected results versus the actual results.
   1. Print the information. "There are _ rows in the expected results and _ rows in the actual results."
   2. Set the testSuccess variable to false if different.
   3. Continue the test suite.
10. Test2: Verify the column count of the expected results versus the actual results.
    1. Print the information. "There are _ columns in the expected results and _ columns in the actual results."
    2. Set the testSuccess variable to false if different.
    3. Continue the test suite.
11. Test3: Verify the columns are named the same in expected results versus actual results.
    1. Set the testSuccess variable to false if different.
    2. Print the information if fails. "I had column1, column2 in my expected results but could not find them in the actual results.  I had column3 in my actual results but could not find it in the expected results."
    3. Continue the test suite.
12. Test4: Verify the actual data in each row versus the expected result.
    1. Do not expect the results of both to be in order. Filter down and find the specific row.
    2. Print both the expected result row and the actual result row. Include headers if possible.
    3. Set the testSuccess variable to false if different.
    4. Print the information if it fails per column. "I expected a value of _ in column1 but actually had _."
    5. Continue the test suite for every row.
13. Print how many rows passed and how many failed.
14. Verify whether the End2End test failed or not. Assert.IsTrue(testSuccess)

I worked sitting right next to a guy named Chris Stein for 2 years here in Topeka, KS.  He had an interesting sense of humor, was really thin, and smokes.  He left the company nearly a year ago, but we still remain friends. 

A few months ago I was reminded of one of my high school teachers named Mr. Stein.  Mind you, I went to high school in a very small town about 200 miles from where I live and work now.  It was worlds ago (and a different life) for me.  I started thinking about his name and wondered if there was any connection to my friend Chris. Why? Well Mr. Stein smoked quite a bit and was also really thin.  He had a very dry sense of humor.  He was the type that would run around the track with a cigarette in his mouth. I don't mean that metaphorically either.  I actually remember him doing that. :D

Then I forgot all about the possible connection and don't remember if I ever asked Chris or not. Besides, Chris grew up in a different state during some of his younger years.  Sometimes people remind you of other people you have known before but they have no connection.

Fast forward to last night.  Last night I attended Chris's wedding.  At the reception, I am standing there talking to some mutual friends and in walks Mr. Stein, my high school teacher.  It turns out Chris is his nephew! The idea of it is wild to me, and I am still feeling a little strange about this today. Sometimes the world is such a small place.  I wonder how many other people I could draw connections to from different areas and chapters of my life?  Have you had anything like this happen?  How did you feel about the experience?

One thing I always keep noticing is that people will develop things without even giving a thought to maintenance.  This somehow seems impolite to me.   I suffer from Coder Alzheimer's, which means I can't remember a thing I wrote after not seeing after three weeks. That is why I think about things like maintenance.  I am seeing all new code if I have been away from it for awhile!  Now that is not completely true, but imagine how it may be for the guy who has never seen your stuff.

Challenge: How Easy is Your Code to Run?

I bet you can't guess how many steps it takes to get your project code running from a blank slate! In fact I bet it takes more than five additional steps for you to get it running. Five additional steps besides getting the source.

Try this. First check in any changes that you need to get in.  Now I want you to blow away your local source files. Everything. Remove the database from your database server. Remove your web settings. Remove any files and folders you may need for processing that didn't go away with getting rid of your local source files. Go ahead, I'll wait. :D

1. Now, pull everything back down from source control.
2. Crack open Notepad.
3. Completely set up to the point you can finally run the application locally.
4. Document every step in Notepad. Save that as a readme.txt file.

How many additional steps did you need to take to be ready to go again? Were you right?

If it does take more than 10 additional steps, you have failed.  If any of them involve getting a file or creating a folder (something you could give them with source control), you have failed (unless that is automated through another file that is in source control). Permissions don't count as part of the steps.

Maintenance Task 1: Make Your Code Easy to Read

What I like to see when I crack open code are methods named in a way they they actually tell you what they do.  They are also no bigger than about 25 lines and do no more than one task each.  I like it to be so blindingly simple to read or understand that even non-technical people can look at my code and sort of understand what it is trying to accomplish.

Maintenance Task 2: Make Your Code Easy to Run Right From Source Control

I came onto a project a long time ago that it took me a couple of days just to get the thing to compile. Two days! Imagine how much money in lost productivity that was for the company! The other developers on the project never really thought about what would happen if they blew away everything locally and pulled down from source. So they had certain things that were not right. They also kept some things checked out because each of them had conflicts and didn't really think about how to make it relevant for all of them.

Please make sure to get everything into source that you would need to run the application.  This makes it easy for someone coming in to just download the source and be off and running. This will save your company money.  It makes it really great when someone who has never even seen a line of code of yours that may have to suddenly work on it to be able to have an easy experience getting your code from source and running it as fast as possible.  What does that mean? That means if you have a file you are picking up and processing when running an application, put one in source and check it in. Make sure it builds to the output folder.  You don't have to have it deploy to other environments, but you need to think about the guy who is developing it locally.

The other thing is don't ever, ever, ever put yourself in a situation in team development where people have to keep a config file checked out locally because you didn't use a relative path.  If the path is important to running the application, please make sure it is part of your (local) build process. That also means it should be in source control.  If there is a file that is important to your application, it needs to be in source control as well. 

Maintenance Task 3: Include a ReadMe File For Additional Setup Required After Getting Source

One thing I have seen that I really like is when I pull down open source projects and they come with readme.txt files that I can take a look at and instantly know what I need to do to get the darn thing running besides just getting the code. 

That file you created in the challenge?  Check that puppy into your project's source control, preferably at the top level.

If any of the steps in the readme file involve creating files or folders, remove them and/or find a way to automate them. Don't make me create a file in a certain way. Provide me one or the means to build one automatically. Otherwise you are making me think too much. Make it easy for me or I will think you are not really being thoughtful and polite.  I already have enough to think about having to fix something in code I may have never seen before.  Make it blindingly simple for me.

Challenge 2: Give it to Someone Else

Now give that readme.txt to someone and have them follow it. Someone that is not on your project or has used your code before. When they are done, can they run the application locally?  How long does it take them?  How many questions did they need to ask?  Do any changes need to be made to the file to make it easier to understand (or for missed steps)?

Do not give them anything other than the readme and point them to the location to get the source. If they ask for any thing else, you have failed. If they cannot get the code running by the instructions alone, you have failed.

Conclusion: Make it Super Simple

Why do I promote making your code easy to maintain?  Very simply.  What would that person do if they don't have anything other than the source? They may have no one to ask because it has been five years and you and the rest of your team has left the company. Or they have to put a fix into production in the next hour and no one is around that would be able to help them.  They have to make it happen. 

If you believe situations similar to these can't possibly happen, we can still be friends, but I regret to inform you that you are very wrong.  If you think you write perfect code that never breaks, you are also sadly confused. It is a gamble to continue believing that someone could get in and work with your code without verifying it.

The question that you should ask when you develop code is: "How long would it take someone who has never seen your project before to be off and running?"

I just recently started using BareTail (which is a free Tail for Windows) and I have to say it is fantastic at what it does.  What is a tail? In Unix it is used to mean the end of the log file.  The follow (-f) option translates into staying with the bottom, or tail end, of the file.

BareTail is a Log File Monitoring tool that you can leave running all the time and it will refresh file changes without ever locking the log files. It has a tab for every log file you would like to monitor and it can be set up for files that don't yet exist; it will start monitoring the file once it is created. 

From the Product Site

· Real-time file viewing

· Follow tail mode

· Tail multiple files

· Configurable highlighting

· International character sets

· Many file formats

· Flexible configuration options and storage

· Single small executable, no installer

Thoughts On BareTail

Did I mention that FREE is one of my favorite 4 letter F words?! There are other tools out there like this that don't perform as well as this tool and they cost much more.  Now being said that it is a free tool, if you find the tool useful, you might think about contributing back to the person that took the time to help you be more productive.  You can register the product for $25.

Three really good ideas are incorporated into this product.

1. No installer required.  Put it where you want and run it. That's awesome.
2. As Dru says, the best tools get out of your way.  You can leave BareTail running all day and it has a very small footprint.
3. You can script out the logs you want it to watch by setting up a batch file with the path to each log file after the filename.

Easily Script Out Paths to Log Files

If you call baretail.exe on a command line, you can give it paths to log files as parameters. Instead of doing that every time, you can script out paths in batch files. Below is a simple example of calling baretail.exe with paths to three log files on the same server.

SET SERVER=TEST

SET DIR=\Logs\Applications\

START baretail.exe \\%SERVER%%DIR%Application1.Console.log \\%SERVER%%DIR%Application2.Console.log \\%SERVER%%DIR%Application3.log

Notice that I put the server variable as the first line.  For each environment, my paths are exactly the same, so I only have to change the server variable.  Right now I am watching four log files for a set of applications we are creating.  I have four environments and we are in three of them currently. I name the batch files like this: baretail_appName_Environment.bat.

Here is a more advanced sample, where you get log files for your web server from today and tomorrow (UTC anyone?). I started with a batch file but found it to be too flaky on date math and turned to VBS, which handled this very easily.

Option Explicit

Function GetLogName(theDate)

    Dim strYear

    Dim strMonth

    Dim strDay

    strYear = Mid(Cstr(Year(theDate)),3)

    strMonth = CStr(Month(theDate))

    strDay = CStr(Day(theDate))

    if Len(strMonth) = 1 then

        strMonth="0" & strMonth

    end if

    if Len(strDay) = 1 then

        strDay="0" & strDay

    end if

    GetLogName="ex" & strYear & strMonth & StrDay & ".log"

End Function

Dim server

Dim directory

Dim application

server ="serverName"

directory ="\\" & server & "\c$\WINNT\system32\LogFiles\W3SVC1\"

application = "baretail.exe"

Dim args

args = ""

Dim today

today = DATE

args = args & directory & GetLogName(today) & " "

Dim tomorrow

tomorrow = DATEADD("d",1,today)

args = args & directory & GetLogName(tomorrow) & " "

Dim WshShell

Set WshShell = WScript.CreateObject("WScript.Shell")

WshShell.Run application & " " & args, 1, False

Set WshShell = Nothing

WScript.Quit

When you run the script you get log files for today and tomorrow. Why would I want tomorrow's date for a log file? Tomorrow because we leave IIS log files to the default UTC time which means it has created a new log file for the next day around 7PM.  If the file doesn't yet exist, there will be a red X instead of a green dot.  That will go away once the file is created and you will be able to watch the logs.

When there are changes to a file, the green arrow show up.

Launchy and BareTail - A Great Combination

Having the batch files available, you can hook it up with Launchy and be even more productive.  I put the BareTail application and batch files in a self-created Launchy applications folder. Then when I want to run baretail, I hit the Hotkey for Launchy (default is Alt+Space), type baretail_ and pick the one from the drop down I want by pressing {Down Arrow} and hitting {Enter}.

BareTail - A Great Product

If you find yourself looking at log files, I would say that you will find this product will save you quite a bit of time (between opening and closing and reopening log files to see the changes). I am finding it to be a very useful tool because I am looking at log files quite a bit.  I started using it for watching log files that I never thought to monitor before because it makes it so easy to do now.  BareTail is a delightfully small product that is free and does one simple thing very well, which is exactly how I like my tools.

Get it here: http://www.baremetalsoft.com/baretail/

Scott C Reynolds (no known relation) wrote an excellent post a few weeks ago that is definitely worth reading on Why Alt.NET.  He talks about the us vs. them and the reasoning that might be behind it.

I will forgo the use of labels that may be seen as derisive and divisive, and state my observation from my career that developers fall into two very broad camps: those who at least lurk but maybe participate in "community" activities (blogs, conferences, mailing lists, etc) and those who, for whatever reason, do not. I will call the former Group A, and the latter Group B. Group A may or may not be doing things right. They may or may not be up on the latest tools or methods, but they are out there trying to learn. Group B, contrary to popular may still be out there trying to learn. Those guys just do it primarily through books, magazines, Google, the MSDN library, and their immediate coworkers. Just because a developer hasn't plugged into a community does not mean he doesn't care.

I bring this up because the Godfather of Alt.NET (Dave Laribee) commented with:

The Group A & B thing. Again, reach is part of it. Education is part of it. But we *must* keep a kernel of innovation going. That kernel should have an open door policy. Meritocracy and first mover advantage over elitism.
A number of ideas (street kit, reach, topical OSTs, enhancements to social networks) have been pitched, but participation remains appallingly low. There's a few people making things happen and we need to expand that if we want to take it to the next level. Hope won't get us there.
Action. Organization. Participation. Engagement. It's very hard to eek out the time, but if people do believe in making progress and innovation happen, time must be made.

Dave was really starting to get to the idea of what I am presenting here.  It takes time. It takes time?!  Why is that?

At lunch today we were talking about how a couple has been married for over 50 years and a family member recorded their marriage ceremony. Fifty years ago! Camcorders were not in wide stream acceptance by the general public at that time, plus they were really expensive.  That means that the member of the family was an early adopter because although camcorders were brought about over 60 years ago, it took a long time to become mainstream and widely accepted.  When VCRs came out and people could see that, they really started to adopt the use of the camcorder.  The idea of the camcorder had to be around for many years before people accepted/adopted it.

It seems today that the acceptance cycle is becoming faster and faster, but this is not central to my point.  The point is that there is an adoption (or acceptance) cycle and we must acknowledge that it applies to the idea of Alt.NET.

I think that all adoption comes down to how a culture adopts technology.  When I was in college, I took some courses on leadership, and one of the things we talked about was the technology adoption lifecycle, also known as Diffusions of Innovation.  Basically diffusion is how long it takes an idea or product to be accepted by the market.

The picture below is from Wikipedia under the GNU Free Document License.  The picture links to the original.

I am going to use the definition for what each group is from the business idea of diffusion:

• Innovators – venturesome, educated, multiple info sources;
• Early adopters – social leaders, popular, educated;
• Early majority – deliberate, many informal social contacts;
• Late majority – skeptical, traditional;
• Laggards – neighbors and friends are main info sources, fear of debt.

What the diagram does not tell you is how long it takes to get to each point of the diffusion cycle.  You want to get to the early and much of the late majority before your idea/technology is widely accepted.  So how much time does that take?  The answer here is that it is hard to tell, but I don't believe that we are yet getting to the point of a 1 year cycle, even a 2 or 5 year cycle.  So this means we have to allow for time, as Dave was talking about.

We are a relatively young culture in .NET so many of the adopters of .NET are just getting used to what Microsoft is ramm-- *ahem* asking us to accept as the best approach.  They are relatively ignoring many of the tools available out there that may be great and many people feel are better.  Many of the innovators and early adopters of Alt.NET came into .NET early on and have tried the Microsoft way for awhile and have since started looking and finding (or creating) new innovations/better ways to do things.  It's kind of the "Been There, Done that, Got the T-shirt, What's Next?" approach.  Many of the innovators and early adopters are the ones who are producing these tools. I feel Alt.NET is really just starting to touch the tip of the Early Majority Iceberg although it could still be in the early adoption phase still.

The one thing we need to remember is patience because this movement will not gain overnight acceptance.  Many will eventually come around.  Given enough time we may even start to get the laggards (stragglers anyone?) because they will make the change out of fear.  This is where Agile is getting to at this point in time. 

Each group comes to these decisions on their own terms.  If we don't understand and respect that each adopts in their own way, we may be quick to turn those would be adopters off.  This is perhaps a little psychology.

There is another story I like to tell that talks about these different groups of people. Sometimes when you are wanting to recruit people, you find that they fall into these groups.  So if you think of basketball, you play the game by giving them information and working the ball for awhile with them.  Then you toss the ball in their court and see what happens. If they toss it back, they are an early adopter/innovator.  They are ready to get started and you can immediately start working with them.  Some people want to examine the ball, understand it, take their time before they toss the ball back.  This takes awhile.  These people are the early majority.  Some people ask a lot of questions and are very slow to make a decision, if in fact they ever do toss the ball back into your court.  They usually come off as very skeptical.  These people are the late majority.  Then there are the laggards.  They only toss the ball back if there is a fear of loss in not accepting.  They take the longest to make a decision, and many times they are not accepting of new ideas.

I would say I fall into the early adopters/early majority area with most everything.  This is how I base where Alt.NET is.

I have two particular posts that I have talked about Alt.NET and what it means to me. To sum up those two articles, Passion is my Alt.NET and I want to see others enjoy what they do.  I believe in some way we are all Alt.NET because we should want to get better at what we do and find better alternatives when tools/ideas are lacking.

I leave you with this thought:

“Don’t worry about people stealing your ideas.  If your ideas are any good, you’ll have to ram them down people’s throats.” - Howard Aiken

I know you see this post and think that I am going to shock you with the best approach to software development and I am!  The great thing is I am not a consultant being paid for this so you don't have to spend countless thousands of dollars for me to come into your organization and tell you what processes are working for you and what you need to change to have successful projects.

Why not?  Shockingly, I don't want to take your money!  I don't want your organization's money either.  What I really want is for you to be successful.  I want you and your project to go as well as it possibly could.

So what's the big secret?  What is the best methodology? What is this utopia I speak of?  It's quite simple really.

The best methodology for successful projects is to:

Find what works for you, and do it. 

I'll let that sink in for a moment.  Take a deep breath.  Breathe out slowly. It's all so simple, yet what does that mean to do what works for me?

• Pair programming works for you? Do it. If it makes sense to only do it say 20% of the time, do it.  If it makes sense to do it more, do it. If it doesn't make sense, don't do it.
• Continuous Integration works for you? Do it. (Gosh I hope it always makes sense to do CI.)  If you don't already do it though, find out when it makes sense to implement and do it then.

Can you see the beauty in this common sense approach to development? If you think about it, it is really about being pragmatic.  Less analyzing about how to get better about the process and more focus on getting things done is the answer. 

Is there a time for analysis? Sure there is. Reserve that for when you are figuring out if something worked for you that you just tried out.  Call it a retrospective (if that term works for you). Does it work for you? Keep doing it. Something needs tweaked? Do it. Not working? Stop doing it.  To be fair, sometimes you need to try things more than once to be sure (you know, give it a fair shake), but don't lock yourself into doing something if it isn't working for you. 

Does it make sense to look out across the software development industry at what others are doing? Sure it does. It makes sense to get new ideas from others, but remember that even though you are fundamentally all doing software development, what others are doing is not what you are doing.  Heck, other people on other projects at the same place you work are not even doing what you are doing. Even more alarming, you are not doing what you did on your last project! If you are, it means you didn't learn from the mistakes you made on the last project. You are not doing what you did on your last project because you have grown. You have gotten better. You have, shall we say, evolved. You are better than you were yesterday, and six months from now you will be even more evolved!  I digress.

What I am trying to say is that what works for one project won't necessarily work for another because there are so many differences.  So many inputs go into software development that there really isn't a set recipe.  It's more of a concoction that is different every time you make it because you can't always control the ingredients.  That is why you have to find what works for you.

Now remember, the most important part of this novel approach is the do. You need to make sure you implement this part of the process. ;-)

And because it bears repeating I'll mention it again.  The best approach you can take to a successful project is to Find what works for you, and do it. 

Those that know me know I am very passionate about my craft.  I have recently been thinking of a great domain name that really addresses how I feel.  There are two things I wanted to address with my domain name. The first is that as a developer we are always seeking perfection and never finding it.  That is a coding utopia. A utopia is defined by Wikipedia as:

An unrealistic ideal that is impossible to achieve.

That is really how I feel about programming.  We can do it our whole lives and never achieve perfection.  But our obsession is to always strive to get there.  We do so in a fervent or ardent way.  That is the second idea I wanted to address.  We also fervently share our ideals with others.  The Free Online dictionary defines fervent as

characterized by intense emotion; Having or showing great emotion or zeal; ardent

Also, fervent explains the passion I have for development as well. That is why I am pleased to announce that the new domain for this blog is http://ferventcoder.com!  I am still hosted by GWB so you can still access the content by going to http://www.geekswithblogs.net/robz if you would like. Or you can use the new address.  All