Mitch Wheat - Treat the cause, not the symptoms!

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.

Design Principles:

#1: Whenever you design anything, always do so from the user’s (consumer’s) viewpoint. If you are designing a framework, write examples of its intended usage; this will highlight any deficiencies.

#2: Encapsulate what varies. It should be possible to alter or extend the parts that vary without affecting everything else

#3: Program to an interface, rather than an implementation (i.e. exploit polymorphism). Use a factory.

#4: Favor composition over inheritance. Do not overuse inheritance; a blend of the two often works best.

#5: Don’t Repeat Yourself (DRY principle). Every fact must have a single, unambiguous, authoritative representation within a system.

#6: Aim for loosely-coupled designs between objects that interact. Low coupling and high cohesion lead to designs that are more resiliant to change.

#7: Classes should be open for extension, but closed to modification. Able to extend existing functionality without breaking existing code.

#8: Depend on abstractions, rather than concrete classes. Use a factory.

#9: Principle of least knowledge: talk only to your immediate friends. How? Only call methods on:

• The object itself
• Objects passed in as parameters to a method
• Any object instantiated by a method
• Any composite objects (Has-a)

#10: Low level components should never call into a high-level component directly.

#11: A class should have only a single reason to change (high cohesion)

#12: Raise Exceptions only in exceptional circumstances. Do not use exceptions for normal program flow.

(these are largely due to the excellent book ‘Head First Design Patterns’ by Freeman & Freeman, O’Reilly)

Came across this collection of ASP.NET videos ranging from beginner to stuff that's 'coming soon':

Updated: might be more useful if I actually posted the link!

On this page you will find dozens of videos designed for all ASP.NET
developers, from the novice to the professional. If you are new to ASP.NET,
you can learn the basics of how to create dynamic web applications with
ASP.NET 2.0 and Visual Web Developer 2005 Express Edition, using either
Visual Basic or C#. If you have a bit of development experience, you
will learn how to employ some of the great new features introduced in
ASP.NET 2.0.

Scott Guthrie has posted a really useful collection of links to his ASP.NET 2.0 articles: ASP.NET 2.0 Tips, Tricks, Recipes and Gotchas. Scott is a General Manager within the Microsoft Developer Division, so to say he knows his stuff is a bit of an under statement!

September is shaping up to be a great month for the Perth developer community. Greg Linwood will be presenting two different sessions on SQL Server indexing on the 6th and 7th Sept.

The two sessions will be "Designing Indexes for Developers" (6th Sept) and "Managing Indexes for Database Administrators" (7th Sept). Although each session has a slightly different target audience, both have a common theme and will contain material that will be of interest to anyone who deals with SQL Server on a day-to-day basis. (I'll definitely be attending both)

Both sessions will be held in the Colonial Ballroom - Melbourne Hotel, 942 Hay St (cnr Milligan St), starting at 5:30pm. Another 2 events not to miss!

You can download the english version here (approx. 156MB).

If you're a developer in Perth, Australia then come along to hear Ron Jacobs talk about "Patterns and Anti-Patterns for Service Orientated Architecture (SOA)" at the Perth .NET user group meeting:

When: 12:00 PM, Friday, 1st September 2006
Where: QV1, level 2 Theatrette, 250 St. Georges Terrace, Perth
Cost: FREE!

Are you setting out on your programming career? Do you want to be a better programmer? Here is a very short, set of guidelines (there’s nothing really new here, and it is not comprehensive, but if you are already following the majority of these then you are on the right track):

• Be Consistent. Be consistent in everything you do. Periodically, examine the way you do things and the reason you do them that particular way; periodically re-assess to see if there are better ways.
• Always name things as accurately as possible. If you find yourself unsure of how to name something, then you are probably unsure of its intended use. In the case of a class, it is often an indication that you should break it into smaller, multiple classes.
• Always put yourself in the role of the user (= consumer). This Zen-like approach is ubiquitous: always design things from the point of the view of the consumer, regardless of who (or what) the consumer is. This includes frameworks, UI, objects, methods; basically everything! If you want an alterior motive, that consumer might be you in 6 months time!
• Great software takes into account People, Process, Business, and Technology in that order.
• Expect and design for CHANGE. Well designed software is flexible and resilient to changes in requirements. BUT do not over design. The art is in finding the right balance.
• Never ‘invent’ your own encryption or random number algorithms (there are some classic coding horror stories of programmers rolling their own. This is an excellent article if you can find it: S. Park and K. Miller. Random number generators: good ones are hard to find. Comm. ACM, 31:1192—1201)
• Never use Bubble sort! (and that means ever!) (see my previous blog entry)
• Always use ISO date format when outputting dates as strings. This site is highly recommended reading.
• Use and believe in testing. Use Nunit (or your platform specific xUnit) for unit testing. Watir is a good candidate for web UI testing.
• The majority of runtime bugs/problems encountered are usually related to:
  (1) Permissions and Roles
  (2) Dates and Date Formats
  (3) Timing Issues
  (4) Configuration (which includes the previous 3 points)
• When you have the choice of scripting a sequence of actions or just using an IDE tool to implement changes in an ad-hoc manner, ALWAYS script, script and script again!
• When you are unsure of how something works, ask someone. There really are no stupid questions (only the ones you needed to ask but didn’t!).
• Get a mentor (if you can). Either a senior programmer where you work or someone online. The online development community has flourished in the last 5 years and it abounds with talented people that give up their time to share best practices, such as Agile or Test Driven Development.
• The software industry is somewhat unique with regards to the rate of change: if the thought of continuous change coupled with continuous learning throughout your career seems un-appealing then you should probably look for another vocation!
• In my experience, the developers that write the fewest bugs tend to be the ones that have the smallest egos. When a bug is found in an application that includes your code, assume the bug is yours (within reason) and take responsibility for it. If it is yours it will probably be easier for you to fix than someone else, plus it is always easier to find out it is actually due to code written by someone else (help them fix it, the problem is still yours!), then to look foolish by pretending the problem lies elsewhere only to find it was you who made a silly mistake
• When converting code between languages, be mindful of ‘off by one’ or boundary condition errors, as some languages have 1-based arrays by default. (I was going to remove this point as I wasn’t sure it was still as relevant, but having just found a subtle bug in converted code, I’ve included it).
• Get closure on problems: bugs do not just go away! I have heard programmers actually say “Oh that bug?, it just went away!” This may be an indication that you are in the wrong profession! One trait that distinguishes good programmers is a burning desire to get to the root cause of problems.

Early last year (2005), I wrote a Powerpoint presentation that discusses steps you can take towards becoming a better programmer. I’ve delivered it at 2 companies, and it was well received. If anyone is interested, let me know and I’ll post it here.

I’ve been a subscriber to the printed version of MSDN magazine for a number of years, and lately I’ve been wondering if I should continue, as most (if not all) of the content is available online here at msdnmag. The printed version usually arrives sooner, but by the time I get to it in my reading pile, the online version is already out! Maybe they should give it away to MCSD’s!

September’s issue has a wide range of articles including guidance for building smart clients, enterprise library custom application blocks and integrating Virtual Earth into your applications. There are also links to past issue articles such as preventing SQL injection attacks, crucial security tips for developers and a selection of performance related information.

MSDN and Microsoft.com are full of great learning resources, but it's not always obvious what's available. Here's a great series of webcasts Architecting Modern Desktop Apps in .NET by Dr. Joe Hummel (recorded third quarter 2005), describing the design and development of smart client applications.

There is also a series on Modern Software Development Using C#: Develop in .NET (with a equivalent series for VB.NET) at the same URL.

You will need to sign in to MS Passport to download these webcasts (and the 2005 offline player) and go through what seems like a ridulous number of clicks to download a single webcast (Microsoft: when are you going to make this processs easier, say download a complete series???). Who said the road to continuous improvement was supposed to be easy!

Now I’m sure most developers and DBAs are aware of this, but I mention it because it crops up every once in a while in production code. There are 3 ways to retrieve the last generated identity value for table: @@IDENTITY, IDENT_CURRENT(‘tablename’) and SCOPE_IDENTITY().

If you want to make sure that retrieved identity value is correct, use only SCOPE_IDENTITY().
In fact, it’s worth doing a search for the other 2 possibilities across all your projects’ stored procedures just to be sure.

From Books Online:

• SCOPE_IDENTITY() returns the last identity value generated for any table in the current session and the current scope.
• IDENT_CURRENT(‘tablename) returns the last identity value generated for a specific table in any session and any scope.
• @@IDENTITY returns the last identity value generated for any table in the current session, across all scopes.

Over on gotdotnet there's an article ASP.NET 2.0 Internet Security Reference Implementation detailing an internet facing ASP.NET 2.0 web site complete with code and guidance. If you're about to develop an internet facing site then this is a good starting point to see security best practices in a full blown sample application.

I came across the Power Toys for Visual Studio site at Rob Caron's blog

Power Toys for Visual Studio are small tools that provide aid to developer
pain-points or assist in diagnosing development-related issues. In addition to
providing support, the power toys are released as Microsoft Shared Source to
provide sample code to real-world solutions and allow for
collaborative-development.

It contains information about the various power toys under development, such as the Best Practice Analyzer for ASP.NET and the MSBuild Extras - Toolkit for .NET 1.1 "MSBee" and developer tools such as IronPython.

There's an Announcements RSS feed you can subscribe to here to keep up date on what's new.

I probably missed the fact that this new feature existed in Visual Studio 2005 due to not doing much XSLT lately. I was re-reading an article by Nick Weinholt which made reference to this feature. Several third party tools have had this ability since VS2003, so it is a welcome addition to Visual Studio 2005’s feature set.

If you are learning XSLT, then this can be a valuable tool for stepping through transforms and getting a feel for how they work.

To show just how old this information is I’m linking to a MSDN article An Introduction to the XML Tools in Visual Studio 2005 from July 2004!

Simply open the XSLT file with VS2005, set a breakpoint(s) as you would with .NET code, go to XML->Debug XSLT and you will prompted for a XML input file. Browse to your XML document to be transformed and away you go.

I’ve been familiar with the concept of MapReduce for some time (a less generic form of MapReduce formed the basis of a paper I wrote circa 1988, ‘Sorting with near-linear speedup on tightly-coupled multi-processors”), although I’ve never used a functional programming language in anger. I’ve just finished reading an excellent research paper by Jeffrey Dean and Sanjay Ghemawat (both at Google) titled “Simplified Data Processing on Large Clusters”. MapReduce is a programming paradigm and an associated implementation for processing large datasets. The key point being that “Programs written in this functional style are automatically parallelized and executed on a large cluster of commodity machines.”

This is a very accessible paper regardless of your computing background. Well worth reading, if only to get a glimpse of how the Google distributed indexing engine performs its work.

A few of my colleagues, have asked me if anyone reads my blog and why do I bother.
I have to admit it’s mostly for selfish reasons! It’s a great way of keeping track of topics that interest me or subjects I’ve researched, in a single location, and in the process perhaps help someone else. If you find something useful here please feel free to leave a comment or email me. I’ve recently signed up to Technorati and FeedBurner to try to track usage (if you had previously used my direct blogger feed in your aggregator, please swap over to feedburner).

Since I’m on the subject of great quotes, I came across this one some time ago. I think it contains advice that we should all take to heart:

Any society that would give up a little liberty to gain a little security will
deserve neither and lose both.

Have a guess who said this? I bet you're thinking it was some modern radical? It was non-other than that great and diverse American, Benjamin Franklin (1706 – 1790).

Maybe we should display this on gigantic bill boards instead of promoting the ‘war’ on ‘terror’. He also said:

If you would not be forgotten, as soon as you are dead and rotten,
either write things worth reading, or do things worth the writing.

Certain quotes seem to resonate in the mind. One of my favorite is from a man who was born in the 15th century, but whom I feel would not be too out of place in the world as we know it today:

In the land of the blind, the one-eyed man is king.
[In regione caecorum rex est luscus]

DesideriusErasmus, Adagia (III, IV, 96)
Dutch author, philosopher, & scholar (1466 - 1536)

Desiderius Erasmus was a spiritual man, but loathed the corruption inherent in the organised religion of the time. Erasmus stands as the supreme type of cultivated common sense applied to human affairs.

He is the author of a surprising number of well known quotes that have endured through 500 years of history:

Prevention is better than cure.

He who allows oppression shares the crime.

And rather surprisingly!:

Women, can't live with them, can't live without them.

1. Make Sure the Promotion System is Unassailable: In companies where promotions are not available, merit pay systems tend to become contentious, because merit increases are the only way to earn more money. When promotions are available, employees tend to focus on promotions rather than the merit pay system. A promotion system should be founded upon a series of job grades, each with a salary range in line with industry standards and regional averages.
2. De-emphasise the Merit Pay System: Studies have shown that, when information sharing and coordination are essential, organisations that reduce pay differences between the highest and lowest paid employees tend to perform better over time.
3. Tie Profit Sharing to Economic Divers: Identifying a key economic driver and tying team profit sharing to it avoids suboptimisation by ensuring rewards are linked to improvements as a whole.
4. Reward based on Span of Influence, Not Span of Control: Evaluating individual results rather than group results, creates competition rather than collaboration amongst team members. Profit sharing should reward large teams rather than individuals or small groups. This reward system fits well within an Agile environment, which takes the broad approach of involving everyone in the development process.
5. Find Better Motivators than Money: Do not use money as a primary motivator. Invest in people by developing their skills, share information widely, emphasise Leadership rather than Management. Emphasise the intrinsic rewards of fun, growth, teamwork, challenge and accomplishment. Monetary rewards should be treated like explosives! Use them lightly and with caution.

(Taken from ‘Team Compensation’ by Mary Poppendieck, Aug 2004, reprinted in ‘The Best Software Writing I’, selected and introduced by Joel Spolsky)

Noticed this String Formatting in c# compendium via Mitch Denny's blog. A nice reference to bookmark. Most of this information can be found in MSDN, it's just that I have trouble finding it every time!

If you have already subscribed to this feed in an aggregator, could you redirect it to the new feedburner feed at the link on the left hand side. Thanks!

...So I'm having this nightmare about a marauding robotic giant Squid controlled over the internet by masterminds unknown...Bruce Schneier continues his squid themed Friday blog posts!

Microsoft have recently released Performance Console (PerfConsole) 1.0 a tool that can be used to simplify and analyse Visual Studio profiler output:

“PerfConsole is a simple performance investigation tool which tries to adopt a
debugger like experience to drilling into Visual Studio Performance Profiler
generated data.”

This is for those managers who believe they can promote team work by giving raises to just a few members of a team! If you are a manager that has recently experienced high staff turnover, I suggest you read this carefully:

1. When team members are in competition with one another for their livelihood, team work quickly evaporates.
2. There is no greater demotivator than a reward system that is perceived to be unfair. It does not matter whether the system is fair or not, only that there is a perception of unfairness.
3. When management exhort team members to do what is clearly impossible through the offer of rewards rather than helping to make the task possible, people are likely to be insulted and give up without even trying.
4. Optimising a part of chain invariably suboptimises overall performance. One example is separating software development from support and maintenance. If developers are rewarded for meeting a schedule even if they consequently deliver error-prone code without automated test suites, then support and maintenance will cost far more than was saved during development.
5. Once team members get used to receiving financial rewards for meeting goals, they begin to work solely for the rewards, not the intrinsic motivation that derives from doing a good job and making their company successful.
   

(Taken from ‘Team Compensation’ by Mary Poppendieck, Aug 2004, reprinted in ‘The Best Software Writing I’, selected and introduced by Joel Spolsky)

I’ve been hearing a lot of good things about this book Beyond Bullet Points by Cliff Atkinson. I haven’t actually got my hands on a copy yet (one topic sure to get me on a rant, is how it is quicker to get a shipment of books from Amazon in the US to my doorstep, faster and cheaper than going to a technical bookseller in Perth), but I will presently.

I noticed that a recent talk by Brad Wilson on the topic of agile pair programming was written using these techniques, and several other high profile presenters seem to be taking Cliff’s advice on board. Definitely one to add to the reading list.

Want to hear something really scary? On average, a programmer reads just one technical book a year (Code Complete: Steve McConnell). It got me thinking; let’s be optimistic and say that the average every programmer reads 2 technical books related to their work each year. Now assuming you have a productive working career from the age of 20 to 60. That means you will read just 80 technical books in your entire working life! As a consequence, it means you should be very discerning about which ones you read. You may not have realised it but you just don’t have time to read any poor or out of date technical books!

OK. Now you have decided to only read useful books, how will you pick which ones you should read? Jeff Atwood put up a list of recommended reading for developers, and I’ve previously posted a list of recommended computing books. One that is on Jeff’s list that I really should add to mine is The Pragmatic Programmer: From Journeyman to Master. You could probably read this book together with Code Complete and be well on the road to enlightenment!

Brad Abrams has posted these useful answers to common .NET Framework deployment questions.

Microsoft profits fell to a paltry $2.8 billion this quarter, due largely to huge legal expenses.

Microsoft executives have known for some time that sales in the Operating System market will inevitiably fall off and that Microsoft’s period of explosive growth is at an end. Once that happens, if you want to continue to grow then you need to take market share away from others. Which means leveraging your dominant position into other areas, such as business document management, document workflow and CRM, to name a few.

Just under 3 years ago, I was working alongside a team producing document management software for fairly large companies. I tried to warn the manager of this team that there was a strong likelihood that Microsoft would be moving into the area of document management and workflow (i.e. in addition to the existing SharePoint software) and that they should draw up a 3 – 5 year business risk/strategy plan in order to decide what could be done to mitigate this risk, and indeed how long a market would exist if Microsoft entered the arena. Instead, he choose to put on the blinkers and completely ignore this advice…

Whilst I don’t have a crystal ball, it seemed inevitable that the outcome would be that in 1 – 2 years, Microsoft will have a product (something like ‘WorkPlace 2007’ or OfficeFlow or OfficeAdvance, you get the idea!) that it will compete with existing content management systems like Documentum, DocsOpen, HummingBird or OpenText. EMC, the owners of Documentum, already seem to be moving away from this area.

If you haven’t heard or read Bruce Schneier on Security I suggest you head over to his blog. He’s a leading expert on all things security and a voice of reason in a mad world. It makes you wonder to what extent the ‘war on terror’ is simply a replacement for the ‘reds under the bed’ of the cold war.

I’ve spoken with several experienced developers in recent weeks, discussing whether the .NET framework’s two main languages, C# and VB.NET, are in danger of becoming too complex for the ‘average’ programmer, or indeed for the average programming task (whatever that might be). While you could argue that complexity is necessary to model complex problems and domains, the continuing abstraction of programming languages does not provide much support for this view. A complex, general purpose programming language will rarely be a good substitute for a domain specific language (generalisation versus specialisation).

Maybe I’m just getting old and my shrinking brain can’t handle all this complexity, but deep down I feel that code should read like prose. I do not want to waste valuable time trying to figure out what a chunk of code is trying to do, it should be apparent almost immediately. Is this unrealistic? Possibly, but the driving force behind the evolution of computer languages has always been to simplify and increasingly shield programmers from the low level implementation details so that they can concentrate on solving higher level business problems.

I have programmed in C/C++ for over 20 years. When I first encountered VB in 92-93, my first thought was that it was a ‘toy’ language designed for non-programmers to write quick and dirty GUI applications. I could not have been more wrong. I did not have the maturity at that time to realise what it represented and its possibilities. It has had a profound effect on the software industry not only in terms of what could be achieved quickly but it also raising the expectations of what could be achieved quickly! VB’s obvious attraction and strength was that it empowered less experienced programmers to achieve results that were previously only within the reach of ‘guru’ programmers. Of course, you still had to delve into the Win32 API to get at some of the more ‘advanced’ features (exemplified by Dan Appleman’s work in this area ).

What made VB so attractive was that it was simpler and much more productive than coding in C/C++. If VB.NET and C# both increase in complexity, is there a reason for having two languages that serve the same purpose? As C# and VB.NET evolve further, will a single generic .NET framework language emerge, or will a ‘new VB’ diverge from C#?
In this terse example on anonymous delegates from Developing for Developers “…, here's two lines of code that produce a list of all files larger than a given size in a given directory”, it is not immediately obvious what is being performed inside the method even with the previous description (BTW that post at Developing for Developers provides a good introduction to anonymous delegates):


OK, this is a hand-picked, contrived example and not even the most efficient way to accomplish this. You could break this down into separate lines, but the point is the language is enabling, perhaps even encouraging us to write hard to understand (and therefore maintain) code. This reminds me a little of ‘dense’ C code! [In fact, this issue has recently been addressed in C# 3.0 using Lambda Expressions…]

You could argue that less experienced programmers will simply not use the new, more complex features of the language(s), but experience would suggest otherwise.

Please don’t misunderstand me: these powerful language features obviously have their uses. I’m just intrigued about the direction these two languages are taking. With power comes complexity, and with it also the possibility of subtle, hard to understand bugs.

Is there a need for a ‘new VB’?

I had to maintain some fairly straight forward pre-.NET C++ code today. It really made me appreciate the .Net Framework! I was experimenting with a few performance ideas and spent an hour researching why it wouldn’t compile (a conflict between STL library and MFC) which could only be fixed by moving an include into “stdafx.h” to precede all others, then another involved solving a linking problem caused by the common runtime library conflicting with the statically linked MFC library, which required an explicit library link order to be defined!

.NET really does rock!