Advertisements

Watts Humphrey, Software Engineering pioneer and giant, dies today at the age of 83


I was saddened today to see this on the newswire today.  Watts Humphrey is a luminary in the creation of the field of software engineering.  I know many of his methods have been vilified by Agile enthusiasts; but we would not be where we are today without him.  He has my respect, admiration, and gratitude.

Advertisements

Deconstructing the TFS 2010 Default Build Template Part 1: Get the Build


The very first activity in the Default Template is named “Get the Build” and is of type Microsoft.TeamFoundation.Build.Workflow.Activities.GetBuildDetail .

Now unfortunately, Microsoft does not provide any documentation for the above namespace.  Sooo, it’s time to break out .Net Reflector!!  This is a great tool that allows you to basically get the code or reverse engineer compiled assemblies.  So we put the Microsoft.TeamFoundation.Build.Workflow.dll assembly (can be found at C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies) in the tool and here’s what we get:

public sealed class GetBuildDetail : CodeActivity<IBuildDetail>
{
    // Methods
    public GetBuildDetail();
    protected override IBuildDetail Execute(CodeActivityContext context);
}

Interesting… so we know that the Execute method is the one run by the activity and it apparently
returns a IBuildDetail interface.  Going to the interface, we find that the only derived type is BuildDetail.

Okay, now we’re getting somewhere.  I can tell you from already going all the way through the Default template workflow that the BuildDetail class is very important and used in a lot of other activities.  It is basically a container for a whole lot of properties.  Here is a list of those properties, so get out your pencils!

public IBuildController BuildController { get; internal set; }

public Uri BuildControllerUri { get; internal set; }

public IBuildDefinition BuildDefinition { get; internal set; }

public Uri BuildDefinitionUri { get; internal set; }

public bool BuildFinished { get; }

public string BuildNumber { get; set; }

public IBuildServer BuildServer { get; set; }

public BuildPhaseStatus CompilationStatus { get; set; }

public string ConfigurationFolderPath { get; }

public string DropLocation { get; set; }

public string DropLocationRoot { get; }

public DateTime FinishTime { get; }

public IBuildInformation Information { get; private set; }

public bool IsDeleted { get; }

public bool KeepForever { get; set; }

public string LabelName { get; set; }

public string LastChangedBy { get; }

public DateTime LastChangedOn { get; }

public string LogLocation { get; set; }

public string ProcessParameters { get; }

public string Quality { get; set; }

public BuildReason Reason { get; }

public string RequestedBy { get; }

public string RequestedFor { get; }

public string ShelvesetName { get; }

public string SourceGetVersion { get; set; }

public DateTime StartTime { get; }

public BuildStatus Status { get; set; }

public string TeamProject { get; }

public BuildPhaseStatus TestStatus { get; set; }

public Uri Uri { get; }

internal VersionControlServer VersionControl { get; }

So, not only are these properties used all over the place, you can use them too!  Want to know if the build succeeded?

Put in a If activity and test for

BuildDetail.CompilationStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded

See how learning the Default template leads you to customization mastery!?!  Now go use your new found knowledge and create your own cool customizations!!

Deconstructing the TFS 2010 Default Build Template


When you create a new team project in Team Foundation Server 2010, there is one directory created automatically in the team project’s home in source control: BuildProcessTemplates. In that directory there are 2 – 3 Windows Workflow xaml files depending on if you have Lab Management installed or not. The one that is most used and the one I will concentrate on in the next series of posts is DefaultTemplate.xaml.  If you want to really customize your builds, you need to know the Default Template inside out.

From Art Form to Engineering Discipline?


This is the title of a new paper that is to be published in the IEEE Annals of the History of Computing by Christopher McDonald.  This paper starts to answer how software processes became so formal and heavy-handed in the 70’s and 80’s.  It is interesting to see Barry Boehm advocate waterfall in the 70’s and then back away from it in the 80’s with his spiral process.  It is also interesting to see that iterative software was alive and well in the late 80’s and the Agile movement did not invent it (as many Agile zealots will want you to believe).

Following this paper’s narrative; you can see that Software Engineering was born out of the so-called “Software Crisis” of the late 60’s and early 70’s.  The answer was scientific management espoused by Frederick Winslow Taylor.  This did not work as they were comparing apples and oranges.  Taylor was dealing with the mindless work of blue-collar factories workers; while software is engaged in by highly educated, creative white collar workers.

It seems that a lot the first ideas of “Software Engineering” came from this factory analogy.  Interchangeable parts and software components is another example.  There is a reference to the quality movement in the early 1900’s that I’d like to explore more fully.

Overall, this is a good read and elucidating history of Software Engineering.  As the military’s influence on software development wanes; it becomes less relevant.  But the history shows you how we got to where we are today in software development.

TFS 2010 Build Process Customization


The MSDN documentation on the subject is minimal.  Ewald Hofman has a great series on the subject here.  Really gets into the weeds of how things are done with the new Windows Workflow Foundation team build.  Enjoy!

CAST Study shows software industry still has a long way to go


CAST’s recently released “Worldwide Application Software Quality Study” is the first study to give real numbers, based on a good amount of data, to code quality.  This is a notoriously difficult problem to address given the millions of lines of code most applications have.  They do a very admirable job of not going too far in their assumptions; but also delivering valuable results.

A key finding for me was that code quality does not go down with increasing lines of code (p. 10); unless you are using COBOL.  Thankfully I don’t :).  What did cause code quality to go down in modern languages (Java, .Net, etc.) was module fan-out.  It seems that David Parnas’ theory of modularity has won out in modern languages; as it is encouraged in the language design.  But this has produced the un-intended consequence of developers creating too many complex dependencies between modules.

The study also puts a price tag on maintaining code that all bean-counters will love.  But is also gives real research for developers to point to for getting more time and money to re-factor code.  I highly recommend this study.