Possibly the best description of why programming is fun

This is possibly the best description of why programming is enjoyable I've ever read. It's taken from The Mythical Man Month by Frederick P. Brooks, Jr.

"Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. 

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in
from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air,
from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. 

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men."

Why I don't trust code coverage

I had a discussion with a colleague about code coverage the other day where I suggested that 100% code coverage meant very little because you may have covered every line of code, but not necessarily every path through the code. After the conversion ended I thought I'd better check I wasn't talking utter nonsense.

Here is a contrived method and two unit tests.

Here are the code coverage results.

As you can see, 100% code coverage is reported but not all paths through the code have been tested. Yes, the code is dreadful but I think it makes my point. Just because every line of your code has been tested, it doesn't mean that your code has been thoroughly tested.

To make matters worse, lets say 90% code coverage is reported by whatever tool you use, there's no indication of the importance of the code that has been tested. What if the 10% of code that has minimal coverage is the most critical part of your application?

Don't get me wrong, I'm not saying code coverage is a complete waste of time. As a general indication that an area of code needs a few more tests it's great. But other than that, not so much.

Other people's code - Suteki Shop

It occurred to me a while ago it would be a good idea to have a dig through some open source code. Why? Primarily because in the last few years I've spent the majority of my time working on two codebases, one at home and the other at work. I feel very much in my own little code bubble. Working with the same code day in day out you become familiar with the conventions and patterns chosen and you can get into a rut. 

So, the point of this exercise is to get me out of my comfort zone and learn something new. How have other people solved problems I've faced? What is their code like? How to they handle errors? What new ideas or ways of working can I apply to my code?

Suteki Shop

Suteki Shop, written by Mike Hadlow using NHibernate and .NET MVC, is an open source eCommerce site aimed at the fashion and retail industry. I figured it was a good place to start because looking through an unfamiliar codebase is difficult but.NET MVC is my day job so that will give me a head start.

Observations

• The UnitOfWorkAttribute is a great way of encapsulating all database operations in a single action into a transaction and committing on success or rolling back on exception
• Exception handling is minimal. It seems to only be added where it's really required resulting in really clean code
• Really nice use of fluent interfaces to create more readable code when mapping data to view models 
• Generic repositories make CRUD operations ridiculously simple
• On the whole the controllers are short. Unnecessary code hasn't leaked into them which I find often happens in my work codebase
• Some domain objects fire events whose handlers call methods on services classes, which is a mechanism I've never considered using. E.g. The Order object has no dependencies on any other class, but if you call Confirm() it will set OrderStatus to OrderStatus.Created and fire an OrderConfirmed event whose handler calls EmailService.SendOrderConfirmation. It's a nice way of running non critical tasks
• Object values can be retrieved from the database as if by magic using the power of the EntityModelBinder

ScaffoldController<T>

This is really interesting. It's CRUD done right. Several controllers inherit from this and they contain a couple of attributes and no other code. 

Repository operations are possible because the generic class that applies to the controller also applies to the repository. That generic class is also used to build the view which can store a single item, list of items or return data for a drop down list.

Obviously there are down sides to this approach. It can't be used if you want to do any non standard operations and you still need to create the view.

What can I take from this?

• Chaining methods with fluent interfaces is great for creating readable code, I don't use it enough
• There's really no reason to put any kind of logic in the controller, it can always go elsewhere
• I don't understand generics quite as well as I'd like 
• Model binding is something I should read up on
• Not all actions in a web application need to be done synchronously. If something isn't critical it can be carried out using events or some other async process