Month: August 2006

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.