Previously, I posted how to support developers running Visual Studio 2008 and Visual Studio 2005 on the same .Net 2.0 solution on the same team, built, CI server, etc. The solution is to have 2 solution files. These files have to be kept in sync to keep a healthy build process.
It is very important to keep the VS2005 solution the main solution and the solution used in the continuous build because VS2008 supports everything there, but if you add a project using VS2008, VS2005 might not recognize some things. An example of this is with the path to the Microsoft.CSharp.targets file.
If you create a new project using VS2008, you’ll see the following in the newly created project:
Note the $(MSBuildToolsPath) property. This was added in .Net 3.5, and Visual Studio 2005 and MSBuild for .Net 2.0 doesn’t understand this property. Changing the project file to the following makes both versions of Visual Studio happy. (change it to $(MSBuildBinPath)
DevTeach starts Monday in Vancouver, and after the pre-con we’re kicking it off with a blow-out Party with Palermo. This is the official social event of the DevTeach conference, and it’s open to all conference attendees as well as the local community. In short, if you are in Vancouver Monday night, come on out to Steamworks. Click over here for all the details and to see the nearly 200 people who are already RSVPed and the sponsors who are helping to make it happen.
Tuesday afternoon I’ll be filling in for Ben Day in the architecture track and giving a talk outlining how NHibernate (an ORM) fits nicely into your application architecture without coupling too closely to the framework itself. (Tuesday 1:30pm) Be sure to attend James Kovacs “The Persistence Ignorant Domain Model” talk about NHibernate earlier Tuesday morning.
Wednesday morning be sure to come to my session on the ASP.NET MVC framework. This framework is set to change the way so many developers make ASP.NET web applications. It won’t be long before we’ll be able to say goodbye to Web Forms. . . except for all the legacy Web Forms code out there :-(. Check out the DevTeach session schedule for more details on the talk.
And if you want more MVC goodness (and who wouldn’t), then you should go to Justice Gray’s session also on MVC architecture. Our sessions will overlap a tad, but he’ll cover a lot of things that I won’t, so I highly recommend you hit both.
I’ll be attending the AltNetConf. Convenient for me that it’s in Austin, TX. It’s an open space conference, and I consider it the founding conference of a conversation that is “Alt.Net”. I’ll be proposing the topic: What are the Alt.Net principles?.
The definition of Alt.Net isn’t defined yet. It’s not even at a point where I can explain what it is and actually have other agree with me.
First, Alt.Net inherits Agile, and IS Agile. Therefore:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Excellence and quality
In a world of wizard-generated, disposable software (disposed 2 years later by necessity, not choice), Alt.Net focuses us on excellence in the software we create. While the world may pay for and accept software that lives for 2 years before becoming utterly unmaintainable, we don’t accept shoddy work. We know that we can deliver high quality software faster than others can deliver low quality software, so we accept no less than the highest in quality. We strive for excellence through solid engineering practices and a high level of software education. Coincidentally, Extreme Programming helps in this area, but Alt.Net does not specifically _mean_ XP.
- Alternative Vendors
A common theme in many .Net shops is they are “Microsoft” shops. In other words, if it doesn’t come from Microsoft, they won’t use it. This makes no sense. Microsoft is not a large enough company to be the vendor to the whole world. .Net is a great platform, and we as a community have chosen the platform and choose to participate in this segment of the industry. We strongly believe that 3rd party vendors complement the .Net platform in a way that can contribute to excellent working software. In fact, some 3rd party offerings are superior to Microsoft’s offering. For instance, in a strive for excellence in an e-commerce website, a team may choose a mature O/R Mapper like NHibernate to accelerate team speed and produce a flexible data layer; however, Alt.Net does not _mean_ ORM. Open source software is a source of excellent 3rd party alternatives built on the .Net platform, and it should be used over Microsoft alternatives when they contribute to excellence; however, Alt.Net does not _mean_ open source.
- Joy in our work
We know that we will produce better software if a team is motivated and morale is high; therefore, we use libraries, tools, and practices that add joy to the working environment. We abandon or correct libraries, tools, and practices that make it a drag to work on the software. For instance, many find that Visual Studio is a bit slow to work with and that adding Resharper to the IDE adds a high level of joy while working with .Net code; however, Alt.Net does not _mean_ Resharper.
We know that we will never know everything there is to know. We strive for a greater understanding of software through studying successes and failures of the past as well as the present. We educate ourselves through many sources in order to bring the most value to our clients. We keep up with other platforms, such as Java and Ruby, so that we can apply their good ideas to .Net development and increase the quality of our .Net software. The technology is always changing, but the knowledge accumulates. We know that the knowledge applies no matter how the technology changes. With knowledge comes humility because without humility, knowledge would pass us by.
The above are principles, so they are intentionally abstract. Below, I’ll list some items that are concrete. These items apply the principles but are more directly applicable:
- Read more than just MSDN magazine and MS Press. Authors like Feathers, Fowler, Martin, Evans, etc have a lot to give (Knowledge)
- Use Resharper. It makes working with Visual Studio a (Joy). But if another vendor comes along that does even better than JetBrains, consider switching
- Use NUnit over MSTest, Subversion over TFS SCC, Infragistics/Telerik over in-the-box controls, RedGate over in-the-box SQL tools. Each of these is a better alternative to that which Microsoft provides (Alternative Vendors). Use NHibernate over hand-rolled stored procedures and especially over DataAdapter/DataSet, but if EntityFramework proves to actually be superior to NHibernate in a meaningful way, consider using it.
- Use a responsible application architecture. Don’t put everything in Page_Load like you see demonstrated at MSDN Events. Use knowledge to create an application that can stand the test of time and not be rewritten every 2 years. Deliver (high quality and excellence).
- Automate every repetitive task; builds, tests, deployments, etc – excellence and joy
The concrete examples could go on and on, and I hope AltNetConf produces a long list. I’ll be interested in having my proposed principles accepted by the community there or revised into something better. Either way, I’d like to get to a point where there is an accepted definition of Alt.Net.
Please read this post by Brad Appleton (and some links off the post) about building trust in a software team. The notion is very profound, and we don't talk about much in professional circles. I, for one, can easily be drawn into only thinking about the technical aspects of software development. It's easy because it's something at which I excel. Years ago I went so far as to scoff at a previous employers attempted evaluation of "soft skills", but I know see the importance of it. Technical skills are necessary, but the greatest techy on earth can be rendered ineffective if no one will trust him.
For all you MVPs out there, I'll be at the MVP summit in March, so count on a "Party with Palermo" the night before everything starts up. I'll post more details (time/place) as it gets closer, but since tomorrow many people will be making travel plans, plan on arriving the day before the summit so you can Party with Palermo.
Past Party with Palermo(s) posts:
I've been reviewing Jim Shore and chromatic's upcoming Agile book, and I especially like the "No Bugs" section here: http://jimshore.textdriven.com/Agile-Book/no_bugs.html
Large, dusty bug databases abound. Some teams have a process where this is unavoidable. Some teams use a bug database as a roadmap *shudder*.
Personally, I believer that a "low priority bug" doesn't exist. If it's a bug, why would you ever think of not fixing it? If a product manager decides that the current behavior of the system is acceptable for the time being, then why would you call it a bug? You may find the behavior of the system undesirable, but ultimately, it's the product owner's call what is desirable or not. Maybe he agrees it's undesirable, but there are other things more undesirable (like the complete absence of several large stories).
In my experience, poor management leads to a code-and-fix culture – working off a bug list. It's "easy" if there is just a running list of bugs. The team stays busy, and you can track work (kind of). What is hard is to lay out a prioritized road map and manage the growth of the product. Managing the product is actual work.
Many things can contribute to a low bug count: proper roadmap planning, good developers, automated tests, good software design, etc. I think the average life of a bug is also very important for the team culture.
To drive a culture of "no bugs", bugs cannot be allowed to live long. If a bug is announced, and nothing happens, the team accepts that the bug is there, and they will fix it "when they get to it". If someone stops and immediately addresses the bug, then the team knows that bugs are not acceptable. From a management perspective, I give bugs top priority. If there is a bug on our wall (red index card), it has top priority – no questions. The bug is not allowed to live. This is key for driving a "no bugs" team culture.
I have printed out and posted the graphic from Plip's blog:
Testing WinForms UIs is tough. Manual testing is slow and difficult to repeat. Vivek Singh has just released a new version of SharpRobo, a WinForms testing framework. Vivek recommends running these tests through NUnit, and from practive, I’ve found that whatever I can test with NUnit, I can test with FIT, so I’m excited to try it out. Thoughtworks has previously produced NUnitForms.
Selenium and FIT are good for testing Web apps, but I am dealing with a windows application at this point. Kudos to Vivek for this library.
After lunch on Sunday, many of the speakers formed a panel,
and we had a panel discussion. One of
the hot buttons was Java vs. Ruby. Bruce
Tate does all Ruby consulting, and it’s working well for him. Others on the panel stress that Java and
other strictly typed languages can still be wildly useful.
One of the big points was that Ruby has turned the
conversation from compiled/interpreted and strictly typed vs. dynamically typed
to verifiable. Ruby has proven that strict
typing isn’t as important as working code.
The compiler has become a big spell-checker, but tests are the only
thing that can verify that the program is actually working as expected. Many times we have to add syntax to get the
compiler to shut up. What really matters
is how the program runs.
Venkat (author of Practices of an Agile Developer) added that many languages
check typing at runtime. For instance,
Ruby does do type checking at runtime, but you don’t have declare types when
writing the code. Even with compiled
languages with strict typing, he still wrote bugs and still had to write tests
to verify his code. He has changed his
opinion about compilers and the need. He
says that in dynamic languages, he can speak less, but the computer can infer
the rest from the context of the program.
Scott Bellware asked the question of tool support in Ruby,
and Bruce has acknowledged that the tool support isn’t there yet. Bruce says that every language has grown up
on the command line and then went to an IDE.
Bruce relates that some FUD is circulating that you can’t have
refactoring or write-time help with a dynamic language. The smalltalk browser was very strong, so
that’s an example of a good IDE for that type of language. There are some languages that are compelling
enough for folks to use even before they have good IDE support.
Ted Neward closed the panel with the following: “If anyone disagrees with anything said on
this panel, you are wrong!” 🙂