I discovered Tess’s blog fairly recently. She has some great material on low-level debugging and internals. Her blog led me to this blog post with an excellent reading list of books and articles on the topic of .NET debugging.

David Lemphers has had a great idea that I think we should all try to support and contribute to. It’s a Wiki for developers, but not for the technical nuts-and-bolts stuff. It’s for all the other stuff that developers often give little priority to (and I don’t mean washing!): things like career development and life skills, people skills and presumably chatting up the opposite sex for a spot of pair programming! But seriously, I think its a great idea.

It’s almost live: Daily Developers…coming soon Drop David an email and let him know you’re interested.

The only thing I don’t like (and I realise I run the risk of being excommunicated) is that it’s hosted on Sharepoint and it just doesn’t look as calm and soothing as the standard Wiki look and feel. Does it have a standard Wiki skin?

The whole reason that the term ‘master craftsman’ exists, is to distinguish those people who take their craft beyond that of others. If everyone could build software to the same standards at the same speed, then we would all be machines!

Large projects are (and always have been) about managing large numbers of people with greatly differing skill levels, personalities and idiosyncracies.

It’s unreasonable to assume that what you can achieve with a small team of highly skilled, highly self-motivated individuals can necessarily be scaled up to larger teams, even with a in-house framework of standards, guidelines, tools and best practices.

Programming is knowledge work, it just doesn’t scale like manufacturing.

I came across a very nice collection of VSTS videos and webcasts compiled by Jeff Bramwell here.

Over at the Microsoft MSDN site there is an excellent set of ASP.NET 2.0 tutorials written by Scott Mitchell (of 4GuysFromRolla fame). These very useful and up-to-date (June 2006) tutorials walk you through creating a Data Access Layer (DAL), a Business Logic Layer (BLL), using Master pages (one of the great new features in ASP.NET 2.0) and wiring up UI elements to business objects. Each includes downloadable source code.

The series consists of:
Tutorial 1: Creating a Data Access Layer
Tutorial 2: Creating a Business Logic Layer
Tutorial 3: Master Pages and Site Navigation

Tutorial 4: Displaying Data with the ObjectDataSource
Tutorial 5: Declarative Parameters
Tutorial 6: Programmatically Setting the ObjectDataSource’s Parameter Values

Tutorial 7: Master/Detail Filtering With a DropDownList
Tutorial 8: Master/Detail Filtering With Two DropDownLists
Tutorial 9: Master/Detail Filtering Across Two Pages.
Tutorial 10: Master/Detail Using a Selectable Master GridView with a Details DetailView

The .NET Framework 3.0 RC1 has been released:

.NET Framework 3.0 RC1 (containing Workflow Foundation RC5) http://www.microsoft.com/downloads/details.aspx?FamilyId=19E21845-F5E3-4387-95FF-66788825C1AF&displaylang=en

VS Extensions for Workflow Foundation RC5 http://www.microsoft.com/downloads/details.aspx?FamilyId=117ECFD3-98AD-4D67-87D2-E95A8407FA86&displaylang=en

Windows Vista RC1 SDK (optional: provides SDK samples and help) http://www.microsoft.com/downloads/details.aspx?FamilyId=117ECFD3-98AD-4D67-87D2-E95A8407FA86&displaylang=en

I found this great idea while ago in Bob Walsh’s book “Micro ISV: From Vision To Reality”: keep a summary of all decisions you make in a “Decisions Document”. Bob was talking about it from the point of view of a one person start up (or micro ISV), but it can apply equally well to a software department. This should be done for each project individually as well as another document for the department as a whole.

The Decisions Document should include a short description of the decision, the reasons for making it, the date, references to any documents or research material, and where appropriate the people involved in making the decision. It allows you to re-visit decisions at a later date and re-assess whether they still apply.

Design is not just about what you put into an application or product; it is also about what you decide to omit. An excellent place to keep your decisions document is in a Wiki (along with your other development artifacts).

The army of Scott Hanselman clones (!) have been very busy installing and evaluating just about every developer and power user tool available here on planet earth: Scott Hanselman’s 2006 Ultimate Developer and Power Users Tool List for Windows (I suspect they may be busy on other worlds as well…)

I already use a fair few of these, but I’ve just noticed a couple I will be definitely checking out.
Now, if only I was clever enough to know the Latin for this post’s title…

I just finished listening to a TechEd Webcast “Lessons Learned Shipping TFS” by Jeff Beehler based on content recorded during Jeff Beehler‘s trip to Australia earlier this year and produced by Charles Sterling. The audio quality in the copy I downloaded was poor in places, but if you are currently in the process of designing new software there are several lessons learned on how you can go about improving the end application.

Jeff discusses development processes in the SDLC such as continuous integration and ‘dogfooding’ (and how it enabled them to realise they had made mistakes and fix them before they became show-stoppers). He also makes an important point about making shipping and deployment part of the build-cycle so that it’s not the first time you do it on release day! (I know there are plenty of people out there nodding to that one…)

Or are we just in danger of running out of acronyms!?!

I just re-read this short article “Software Is Too Darn Hard” by Rockford Lhotka, which talks about software from the users perspective and how most changes in languages over the last 10 – 15 years have had very little impact on improved experience for end users. (Don’t be put off reading it by the comment about a ‘rant’ at the start…)

“Expressing business requirements in software would be more efficiently
done by people who work in the business, who understand the business, language
and culture; and who have tools that allow them to build that software rapidly,
cheaply and in a way that actually meets the business need.”

The reason VB was so successful was that it enabled the people who work in the business, who understand the business, its language and culture, to cheaply and rapidly build software that actually meets the business needs.

Problems are encountered in areas where the language no longer enables non-programmers to accomplish their goals, or does so in a way that is prone to misunderstanding and mistakes. This also applies to programmers and was borne out by framework usability studies done by the designers of the .Net framework (as described in the Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina).

That’s why I believe there is a real need for a ‘new’ VB, and that the LINQ ‘flavours’ are huge steps in this direction. Why should a domain expert have to be versed in the subtleties of writing an N-tier application, consisting of lengthy boilerplate code, when the tools should perform this task and generate it for them?

If tools did what they were supposed to do (model the business needs, make us more productive by reducing the amount of code we have to write, and therefore create software faster) domain experts would be in a better position to create solid, useful software, and in the process bring the software closer to the users’ needs and expectations. In other words, helping to put the user back into software.