Uncategorized

I’ve just noticed that Jeff Atwood has posted comments on Steve Yegge’s most recent post. I think he puts it much more eloquently than I did:

“In order for programmers to be effective, they have to believe in what they’re doing. Whether that belief is scientifically and empirically provable or not is completely irrelevant”

A colleague, Vaughan De Vos, emailed me to ask if I knew about Google’s Code Search site. I saw this briefly last week, and thinking it was just Google with a few query modifiers, I didn’t pay it enough attention. I’ve tried a few searches and the results are interesting.

EDITED TO ADD (11th Oct 2006): Static Code Analysis Using Google Code Search

Steve Yegge caused such a stir with his original post on Agile methodology that he’s written a follow up, Egomania Itself (in case you’re wondering, it’s an anagram of Agile Manifesto!). He covers a lot of ground with references to some very important concepts such as “selective reinforcement” and advocates commonsense when he observes ‘Whenever you hear Agile people asking around for “success stories”, remind them politely that only looking at the positives is pseudoscience.’

Using Agile will not guarantee a project’s success. People will. But the central tenet of Agile is “People First”. Rather than talking about whether Agile works or not, we should be extracting those things that do and applying them where appropriate. Test driven development to me seems a no-brainer (despite the fact I still struggle to write code this way). Steve Yegge writes well, and I believe he makes several excellent points, but I don’t agree with every point.

“Most great software developers around the world don’t use Agile. They just work hard, they stay lightweight,…” but wait, isn’t lightweight exactly what the Agile camp say is the second most important thing you should take care of (after people)?

Steve references a superb ACMQueue article by Jef Raskin titled “When we don’t understand a process, we fall into magical thinking about results.” I believe that every developer should read that article. I have long believed that one of the personally traits that benefits programmers greatly, namely seeing patterns quickly, can also become a drawback if we make connections where none are present. Seriously, if you read just one article this week, read Jef’s.

This article on how to spot bad security/cryptography by Bruce Schneier dates back to 1999, but is still relevant today. I have several of Bruce’s books; he’s always a good read.

Rob Farley just pointed me to Crucible’s blog where he has a write up on the sessions held at SQL Code Camp in Wagga over the weekend. Sounds like it was well worth attending. Some of the material is available online from the various presenters blogs. We were lucky to have Greg Linwood here in Perth a few days earlier where he presented two SQL Server indexing talks, so I didn’t miss out entirely!

Planning the Meeting

• Whenever possible do not meet!
  – Meetings are time consuming, so decide whether a meeting is the best way to handle the issues/topics?
• Define the purpose of the meeting
  – Write down a clear goal and desired outcomes
  – Decide who should attend based on the desired outcomes
• Keep meetings short
  – Do not allow meetings to overrun
  – If there is unfinished business, schedule for another time
• Always issue a meeting notification
  – Give attendees sufficient notice to enable them to prepare any relevant material
  – State the place and time for meeting
  – State the duration of the meeting
  – Confirm attendees acceptance
• Always distribute an agenda to attendees before the meeting takes place
  Include:
  – Meeting objectives
  – List of discussion topics
  – Place highest priority items first on agenda
  – Provide attendees with any required background information
• Make sure that speakers are prepared for the meeting
  – Unprepared speakers will contribute little
• A meeting should have an owner or chairperson
  – The chairperson should open the meeting by describing the meeting objectives and expected outcome of the meeting
  – The chairperson should ensure speakers adhere to the agenda and time allocated
• Make sure that speakers are prepared for the meeting
  – Unprepared speakers will contribute little
• Make sure the facilities are prepared for the meeting
  – Arrange any audio-visual equipment or materials in advance. Arrive early to set up and make sure everything is ready to use

Running the Meeting

• Start the meeting on time
  – Do not wait for latecomers
• Start the meeting by reviewing the meeting agenda and objectives
  – Begin by introducing anyone who is not known to the other attendees
• Appoint someone reliable to take minutes
  – Ensure that the minutes are accurate
  – If it is not recorded it probably will not happen
• Stick to the agenda
  – Maintain focus, keep the discussion on track
  – Summarise conclusions or decisions as each agenda item is completed
  – Non-agenda issues/topics should be noted and discussed in the last 5 minutes of the meeting, and if unresolved, tabled for another meeting.
• Assign action items
  – Identify and assign any action items to specific people with completion dates
• Explicitly close the meeting
  – Before closing the meeting determine if the objectives were met
  – Request comment from all attendees, and enter into the minutes
  – Chairperson should provide a concise summary of the meeting’s outcome
  – Issues/topics requiring further discussion should be noted
• End the meeting on time
  – Often people will have other scheduled work to go to
• Minutes should be published and made available to all attendees

Meeting Follow up

• Communicate the meeting’s decisions to those who are affected by them
• Make sure copies of the minutes are distributed
• Remind people what they agreed to do

I was interested to see that Nick Randolph mentioned the role of interaction designer recently on his blog, when discussing the demarcation of roles in the design/development process, prompted by disagreeing with Brian Madsen’s blog post, following Greg Linwood’s presentation. I’ve been talking about this essential role for a number of years and I mostly get blank stares or a bit of eye rolling, and/or finger twirling when I do!

Although I agree that interaction design is a vital part of the development process, I disagree with Nick when he states “This role [developers] should NOT be concerned with how indexes are structured etc,…”. I believe that developers SHOULD have an understanding of how indexes are structured and used. In fact, the principle of treating systems in a more holistic fashion avoids ‘pigeon holing’ and the “it’s not my problem attitude”. In larger teams, it is highly beneficial to have people spanning roles so that they can bring understanding and promote communication between disciplines and teams.

Interaction Design is something I passionately believe in as a way of ensuring that software meets and (better still) exceeds users’ expectations. The aim should be to create applications that need little or no help, “I shouldn’t have to read the manual to understand how it works”. It is possible. I have used the technique to produce a very successful application, which required minimal training even though the system contained a reasonable amount of complexity. One recent UI technique that I think should be highly valued is the ability to add ‘watermarked’ text (pale gray) to empty controls. For example, in a person’s name control you could set the watermark text to “Wheat, Mitch” explicitly showing the format the field expects data to be entered in. This eliminates ‘cognitive friction’ on the part of the user because they don’t have to think “Is it last name first, followed by a comma, or should a name be entered the way it is read?”.

In fact, more than just creating systems that are easy to use, our aim should be to create passionate users. Kathy Sierra and others, post wonderful articles on creating passionate users here.

Interaction design is something Alan Cooper (the father of Visual Basic) has been involved with for some time (you could even say he pioneered it), and has published several great books on the topic, the most notable being The Inmates are Running the Asylum, but also About Face 2.0.

For anyone about to convert an existing .NET 1.1 application to 2.0, here is a list of runtime breaking changes.

These four words encapsulate the most important and fundamental rule of design:

Be Your Own Client

or to put it another way: Put yourself in the place of the user (consumer).

One of the most common uses of reflection is in the use of plug-ins, such as toolbars or hosting third party plug-in functionality. A developer I worked with recently was unaware of the appropriate uses of reflection (let’s call him Bugsy!). I’d like to direct him to the words of Joel Pobar, who you might say is an expert on this topic (Joel is a Program Manager on the common language runtime (CLR) team at Microsoft, at least he was till last week!):

When Should You Use Reflection?
You should always think carefully about how you’re using reflection. Using reflection occasionally without enforcing strict performance criteria is probably fine. If reflection APIs are only invoked when you’re calling the part of your app that loads and invokes a third-party plug-in, then the cost should be reasonable. However, if your scenario involves a high-volume ASP.NET Web site that requires good throughput and response times, and if it makes significant use of the heavy reflection APIs in your “fast path” (the code in the application that must run very fast and is used repeatedly), you should really consider an architectural review to decide if you’ve made the right decisions on your use of reflection.

Where was he using reflection? Between the business rule and data access layers in an ASP.NET 2.0 financial application! (and no, he seemingly had not heard of code generation, despite several attempts to enlighten him). That architectural review sounds appropriate…

Relative performance of Invocation Mechanisms (image from MSDN article)

Scott Hanselman has a Hanselminutes webcast on the subject here.

How can you improve the speed of reflection based calls? J.D. Meier’s post details the use and the performance benefits of the new .NET 2.0 reflection API:

“RuntimeMethodHandle works approximately twice faster than compared to equivalent GetXxx API call, if the MemberInfo is not present in the back-end .NET cache”

To round off this post, here’s yet another free resource from Microsoft “Improving .NET Application Performance and Scalability” (all 1150 pages of it!)

“Information is segmented by roles, including architects, developers, testers, and administrators, to make it more relevant and actionable. This guide provides processes and actionable steps for modeling performance, measuring, testing, and tuning your applications.”

By complete coincidence, I’ve been talking to a colleague about .NET performance tuning and I’m hoping to put an article together in the near future, so stay tuned.