admin

Agile Pioneer?

by

Was John Gall the pioneer of agile development? His little known book Systemantics (published in 1977 and currently out of print) has been influential in shaping the views of several prominent practitioners of software development:

“A complex system that works is invariably found to have evolved from a simple system that worked…A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
— Systemantics: How Systems Really Work and How They Fail. John Gall

Gall’s Law has strong affinities to the practice of agile software development, where under-specification rather than over-specification is the key to success.

‘I’ is for…Interface

by
Roy Osherove has posted an excellent blog entry Interface Naming – Anything But Java’s Standard, Please, on his thoughts on the use of ‘I’ for interfaces. I agree with Roy that using ‘I’ to prefix interfaces is a good idea because it makes code clearer. This is in line with the .Net Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina. You should name interfaces to describe the behaviours they bestow on the implementing class, for example, IPersistable.

I personally believe that the ultimate aim of a programmer is to write code that reads like prose and should be clearly understandable by the reader. Any naming convention or coding standard that leads directly to more understandable code has to be a good thing.

As a young, naïve programmer writing C code over 20 years ago, I, like many others, took delight in writing convoluted, hard to understand code! Writing code with others in mind is not only more productive, but also a sign of maturity:

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand. – Martin Fowler

Another interesting point that Roy mentions, is the reliance on an IDE to understand code through the use of ‘hover’ tooltips. Do you think it is inevitable that we should require tools to understand code, or should language syntax and the printed page be sufficient?

Reporting Best Practices: 10 Things Every Report Should Have

by

Every report should have a footer containing the following:

  1. The name of the report. Give each report a unique identifier in addition to its name e.g. “Cost Summary By Month, By Area” could be “CS-MA1” This is especially useful in applications with a large number of similar reports.
  2. The date and time the data in the report was generated (or the time period represented by the data) and where appropriate, the execution time taken to generate it.
  3. The date and time the report was printed.
  4. Who printed it.
  5. “Page x of N” Just using “Page x” is not sufficient.
  6. If the report is filtered in any way (date range etc), it should include details of the filter parameters in the footer. If there are a large number of filters, it should include a report header page that describes the parameters and the values filtered on.
  7. Alternating shaded lines for the data detail sections (like the old computer printer paper)
  8. Don’t print empty reports. Alert the user that the report is empty (perhaps offer to filter with a different set of parameters).
  9. If printed as paper copy, a URL to the ‘live’ report (reporting services, or aspx page) and a contact email in case problems are found with the report.
  10. Where similar reports exist in different applications, the system name.

Intellisense for SQL Server – Free!

by

I meant to post this a few weeks ago: Red-Gate have made their intellisense for SQL server editors, SQL Prompt, available for free download until September 1st 2006

“SQL Prompt works with Microsoft Query Analyzer, SQL Server 2005 Management Studio, Visual Studio 2005, Visual Studio .NET 2003, SQL Server 2000 Enterprise Manager, UltraEdit32”

No time-bombs, no restrictions!

Go get it!

Bits and er, Bans

by

As most people are aware, the term bit is short for ‘binary digit’. The coining of this word is credited to the mathematician John Tukey, sometime in the late nineteen thirties or early forties.

Claude Shannon, the father of information theory, was a colleague of John Tukey at Bell Labs, and his way of defining the bit was the amount of information required to distinguish between two equally probable outcomes. Around the same time, the British cryptographer, Alan Turing, had also come up with an idea which represented the amount of evidence that made a guess ten times more likely to be true. He called this unit the ban. (Although I suppose that had this been the ‘winning’ formulation, the dit or ‘decimal digit’ might have been coined!)

These historical insights into the information age and many more can be found in “Fortune’s Formula” by William Poundstone. This is a great read featuring gamblers, mathematicians and gangsters with some classic one liners: “In 1974…A computer was something you saw in a movie (often it went berserk and killed people).”

SQL Server 2005 Database Snapshots

by

I recently had one of those “ahha!” moments with the new SQL Server 2005 Database Snapshot feature (not to be confused with the new transaction Snapshot Isolation mode). Dr Greg Low gave an overview of this great feature at the Perth .Net User Group last year, and I was going over some notes and e-learning material.

When you create a snapshot of a database, SQL Server 2005 efficiently creates a NTFS sparse file that initially contains effectively no data.

When you read data from the snapshot, SQL Server checks to see if the page the data resides upon exists in the snapshot. If it does, it serves the page from the snapshot; otherwise it serves the page from the original database.

How do pages appear in the snapshot? Each time a write is made to the original database, SQL Server checks if the page is already in the snapshot, if not it copies the page into the snapshot BEFORE the write is made to the original, thus preserving the point in time snapshot of the data. For some reason, I had wrongly assumed the page was copied after the write, but that just did not make much sense.

Database snapshots can be applied wherever you want to preserve a point in time state of a database. An excellent example of using a snapshot is point in time reporting. This is just one of many reasons why you should consider upgrading to SQL Server 2005.