Month: June 2006

Recommended Computing Books

by

I was just about to order Jeffrey Richter’s book “CLR via C#” to supplement my copy of his previous book “Applied .Net Framework”, when I saw the announcement about the new version of the .Net framework, .Net 3.0. At this rate of change, buying platform specific books is becoming less and less appealing and relevant.

I can’t recall who said it but “you can avoid technical obsolescence by choosing timeless books” is great advice. Here’s a list of recommended reading for all software developers:

Code Complete, Second Edition: Steve McConnell. If you’re in the software industry and you only ever read one book, then this is the book you should read. Every developer, regardless of language, platform or domain, should have read this book at least once. There is no single work that contains so much of relevance to developers. At the last count, I’m on my fifth re-read, cover to cover.

Rapid Development: Steve McConnell. If you only ever read two books on software development, make this the second! Keep this on your desk at all times. Buy two copies; one for work and one for home. It will pay for itself many, many times over. If you are beginning a career in software development, this book could short-circuit 5 years of lessons learned on the job.

The Pragmatic Programmer: Andrew Hunt and Dave Thomas.If you are only going to read one book and you want something a little shorter than either Code Complete or Rapid Development, then this is the one. If you loan it to another developer, do not expect to see it again! The first line of the book states “This book will help you become a better programmer”. It will.

Don’t Make Me Think: A Common Sense Approach to Web Usability. Steve Krug. Great for web, and equally applicable to windows. Short, easy read, but valuable. A little gem of a book. If you design web sites, this is required reading.

The Inmates are Running the Asylum: Alan Cooper. Discusses real world examples of usability, and is a highly enjoyable read. You probably won’t agree with everything (I didn’t), but it certainly gets you thinking.

The Medical Detectives: Berton Roueche. Not a computing book, but a great book on the approach to debugging. A good read to boot, although the prose can be a little laboured at times.

Refactoring: Martin Fowler. A great book that takes the reader on a journey through the process of refactoring actual code.

Head First Design Patterns: Elizabeth Freeman and Eric Freeman. This is a truly amazing book. If you want to learn about design patterns and more importantly how to apply the underlying OO design concepts, this is the best book available on the subject. I recently recommended this to several people.

Patterns of Enterprise Application Architecture by Martin Fowler. Coupled with “Head First Design Patterns” this is a superb reference to have to hand.

UML Distilled: Martin Fowler. If you seriously want to learn UML (and do it quickly without struggling) then this is the book to read.

Behind Closed Doors, Secrets of Great Management: Rothman and Derby. Practical advice on managing a software team. Excellent.

Test-Driven Development: Kent Beck. A slim, very readable, hands-on book that introduces and builds upon the concepts of the ‘write tests first’ development approach. Some would say that this is a natural evolution in the way that software should be created.

SQL Tuning: Dan Tow. A new approach to platform independent tuning of SQL queries. Took a while to get into, but well worth the effort.

The Mythical Man Month: Fred Brooks. Perhaps the classic work on managing software development projects. “How does project slip its schedule? One day at a time”

Programming Pearls: John Bently. An oldie, but a goldie! Insights into how algorithms are conceived and implemented. Introduces the concept of ‘back-of-the-envelope’ calculations. Very useful.

Writing Solid Code: Steve Maguire. Aimed at C programmers but full of insights equally applicable to other languages. This book had a profound effect on the way I write code and the approach I take.

The Psychology of Computer Programming: Silver Anniversary Edition by Gerald Weinberg. An insight into the mind of the programmer, also described as “computer programming as a human activity”.

Design Patterns: by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. This classic work is currently being updated.

The Guru’s Guide to Transact SQL: Ken Henderson. If you write T-SQL as part of your day-to-day job, then should be the first of several Ken Henderson books you should read.

Programming Windows Security : Keith Brown. Everything you wanted to know about Windows security but were afraid to ask.

The last two are platform specific, but excellent nonetheless.

I started this list of books some time ago, but was prompted to finish and post it by a colleague whose son is studying computer science, and was concerned about what books he should read.

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).”