Programming is a Craft

Here are my initial thoughts after reading: Programming is not a Craft

“craft -noun 1. an art, trade, or occupation requiring special skill, esp. manual skill: the craft of a mason." (dictionary.com)

“In English, to describe something as a craft is to describe it as lying somewhere between an art (which relies on talent) and a science (which relies on knowledge). In this sense, the English word craft is roughly equivalent to the ancient Greek term techne." (wikipedia.com)

In my opinion, on a whole, software development is a combination of craft and primitive engineering (which is slowly emerging as a true engineering discipline). The term craft usually means how something was made, not what was made or the perceived value of the end result by the layman. One of the commenters on the original post mentioned carpentry as a craft that may not always be defined by the value placed on the end product by the layman. In this vein, I will also mention that witchcraft is considered a craft.

One of the hallmarks of craft is that that it is filled with heuristics and folklore. Much of the work of today's software developer is squarely within this realm. More often than not, there is no clear-cut way to solve a problem. We craft a solution based off of our experiences and the folklore we encounter. It is worth noting that I consider blogs, google searches, MSDN, visits at a coworker's desk, irc, and stackoverflow.com to be sources of folklore.

I must say that I do agree with much of the post, but I think the terminology that is presented is incorrect. I think it would have been wiser to say that software development is most often not an art, and ego has no place in it.

I also have to concede that in hindsight, I believe that the software craftsmanship manifesto was a bad idea. I recently learned there was a period of time when it was being debated if there should be clause in it to forbid using anything (tools, languages, etc...) that was not OSS. In my opinion the manifesto only serves to force a definition on something that needs no additional definition.

The Mythology of Commodore Told in about 15 Minutes by Jim Butterfield

 

 

 

 

 

 

 

I was cleaning up the data drive on my computer tonight and I came across this gem, which is also hosted on blip.tv:

Click To Play

Many of us owe our career to Butterfield, and the father of the 65XX - Chuck Peddle.
If you are interested in the history of Commodore, please check out Brian Bagnall’s: Commodore: A Company on the Edge.

 

Getting RVM to Work when GVim is Launched from Ubuntu's Menu

If you want to use GVim as your Ruby editor in Ubuntu (and most likely any other Gnome based distro), you've probably found out that your .bashrc file is not read when launching GVim from the Gnome menu. This means that your RVM paths are not available in the scope of apps launched from the menu. However, when launching apps from the menu, the launcher can access your .profile file. That being the case, here is a quick work-around for this issue:

1) Add the following code to your ~/.profile file:

# This loads RVM into the session scope of the launcher.
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

2) Create a script that you can use to start up GVim. Example ~/Apps/GVim/gvimstart.sh. In this script, place the following:

#!/bin/bash
source ~/.profile 
gvim

3)Right click on the applications menu and choose "Edit Menus". Then find your GVim launcher and point the command entry to your script.

I am, by no means, a Gnome expert, so please let me know if you are aware of a better solution.

Happy coding!

Learn WPF for Free

In my last WPF related post I spoke a bit about my WPF learning experience. I was fortunate enough to have an MSDN Universal subscription and any book I wanted via my employer as I went down the path. Unexpectedly, I recently received an email from a reader who wanted to learn WPF on a budget of $0.00. After thinking for a bit, I came to the conclusion that WPF can be learned without spending any money (assuming you have a computer that can run the tools). Below is a roadmap on how to do so.

Get the tools for free

Visual Studio Express, which is able to create WPF apps can be found here:
http://www.microsoft.com/express/Windows/

If you need any other tools, such as SQL Server Express, you can most likely find them via the Web Platform Installer here: http://www.microsoft.com/web/downloads/platform.aspx

Learn the Framework

Between MSDN and the community, there is more than enough well-written documentation out there to help one become an expert on the WPF framework itself. In his book, “Advanced MVVM”, WPF expert, Josh “The Maestro” Smith, recommends the following documents to come up to speed with the WPF framework:

Introduction to WPF: http://msdn.microsoft.com/en-us/library/aa970268.aspx
WPF Architecture: http://msdn.microsoft.com/en-us/library/ms750441.aspx
A Guided Tour of WPF: http://joshsmithonwpf.wordpress.com/a-guided-tour-of-wpf/
Customize Data Display with Data Binding and WPF: http://msdn.microsoft.com/en-us/magazine/cc700358.aspx
ItemsControl: ‘I’ is for the Item Container: http://drwpf.com/blog/2008/03/25/itemscontrol-i-is-for-item-container/

A lot of the information in the above links is difficult to absorb, but I think it is very worthwhile to go through the material, and work through the examples, at least once. If some of the documents are unclear, you can always go back to them as you learn more and need more clarification.

Learn MVVM

Many people blow off MVVM as “the latest popular design pattern”, but learning MVVM is essential to working with WPF. This is because MVVM is a natural pattern to use considering the way databinding works with WPF. Yes, you can write WPF apps using tried-and-true code-behind and click event handlers like people did with winforms, but you’ll be doing yourself a disservice.

When learning MVVM, the first place to look is this very simple video by the Jason “The Enigma” Dolinger, where he explains what MVVM is, and what the pattern’s strengths are: http://blog.lab49.com/archives/2650

The next place I would look is the “MVVM In the box” training by Karl “The Educator” Schifflett:
http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/

As a lesson summary, an in-depth overview of MVVM written by Josh Smith can be found here: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Apply what you’ve learned

While there is no WPF “best practices” sample that I am aware of, I think the following can get one to see how WPF fits into an application architecture.

Building a Desktop TO-DO application with NHibernate: http://msdn.microsoft.com/en-us/magazine/ee819139.aspx
Understanding the MVVM Pattern: http://live.visitmix.com/MIX10/Sessions/EX14
Build Your Own MVVM Framework: http://live.visitmix.com/MIX10/Sessions/EX15

Not strictly MVVM, but worth looking at as application and framework samples:

PRISM: http://compositewpf.codeplex.com/
Caliburn Micro: http://caliburnmicro.codeplex.com/
Caliburn Micro Soup To Nuts Series: http://caliburnmicro.codeplex.com/documentation
MVVM Light: http://mvvmlight.codeplex.com/

Keep Learning

Read Blogs! Search out WPF related blogs. There are enough out there to fill your news reader every day. Pete “6510” Brown  puts out a Windows Client roundup frequently which is a good starting point.

Read and participate in the knowledge dump at http://stackoverflow.com/questions/tagged/wpf.
At first you may find that some of the questions are the same things you are wondering about. After awhile, you will find that you can answer some of the questions. As you answer questions, you’ll reinforce what you’ve learned.

Share

Software development is still largely a folklore based discipline. It is your duty to share what you have learned in the best way you know how.

Katamari Code

We’ve all worked on projects where the codebase is a mess. Here are a couple of common messy codebase analogies I’ve heard over the years:

The House of Cards Codebase:

The Jenga Codebase:

Although I can appreciate the above analogies, more often than not, I think Beautiful Katamari is the most appropriate analogy.

Time Until Productivity In WPF

One of the things I see over-and-over-again when reading about teams that are deciding if they should adopt WPF or not is the fear of the learning curve, and the worry that they will not be productive for a huge period of time. Given that I’ve recently become productive in WPF myself, I thought I would talk about my experience in this area.

A little background about myself: I would consider myself to be your average mid-30 year old ALT.NET developer. I got my start programming BASIC and 65xx assembly as a kid in the early 80s on a Commodore 64, got my first programming job doing Java in the late 90s, and started using ASP.NET in the late 1.0 beta days. Programming is one of my hobbies, but I am not the type that stays up all hours of the night working on my pet OSS project. I am also not a “computer scientist” or language wonk. However, I am passionately interested in software craftsmanship. S.O.L.I.D. is prominent in my tool belt.

My attention was first turned to WPF in the early fall of 2008. My group was facing a large desktop project. The question came up as to if we should go with Winforms or WPF. No one on the team had any practical Winforms experience, so the initial reaction was that we should go with WPF since Microsoft had made it clear that it was the future of Windows desktop development. However, we all had heard rumblings about how difficult WPF was. That being the case, each member of the team created a very small drag-and-drop application to test the waters. The general consensus was that if you ignored the more advanced features of WPF, it was just as easy as Winforms drag-and-drop + code behind development. Mind you, we did not want to do that sort of development, but it became apparent that that style of development would be equally painful using either framework. Note that at this time, I really had no idea how to make a real application using WPF, but I did understand the very basic concept of how XAML markup changed the game from Winforms development.

Estimated time spent learning WPF during this period: 8 hours.

After the initial decision making process, I returned to ASP.NET and WCF development. The WPF project didn’t really get started until spring 2009. I was not slated to work on the project, but I was enlisted to help decide the preliminary architecture. Once I was given that task, I began to look around for application frameworks, or at the very least, some patterns that had momentum behind them. At this time, I learned about the MVVM pattern via the still insightful Jason Dolinger video. It really seemed to click in my mind so I began looking for an application framework to support this pattern. I did not find a mature application framework per say, but I did come across PRISM. There were a few other budding frameworks at the time, but PRISM was way ahead of the game. Therefore, we decided to go with PRISM using the MVVM presentation pattern on the client side of the application. Once that decision was made, I was back off the project and doing other things. I did however start following a few WPF blogs at this time, but I did not do any WPF coding.

Estimated time spent learning WPF during this period: 8 hours.
Total estimated time: 16 hours.

This July, my schedule freed up and I was put on the project 50% of my time. I was tasked with a reporting interface that had to show a list of available reports and then dynamically show parameter UI elements depending on which report was selected.

As soon as I was assigned to the project, I got a copy of WPF in Action with Visual Studio 2008. I read the book half the day during my work week, and then a few hours each night at home. As someone who learned programming through type-in programming, I made sure that I recreated all of the samples myself. Also at this time, I grabbed the latest version of PRISM and took a peek at the examples.

Estimated time spent learning WPF during this period: 30 hours.
Total estimated time: 46 hours.

The first week of actual development was pretty brutal. MVVM was not the problem. PRISM was not the problem. XAML and databinding is where I was banging my head against the wall. It kind of worked like HTML, and it kind of didn’t. That first week was pretty aggravating, but pretty much every problem I encountered was just an internet search away.

Estimated time spent learning WPF during this period: 30 hours.
Total estimated time: 76 hours.

I became productive after that first week. I’ll be the first to admit that I don’t intimately know how WPF works behind the scenes (like I do with ASP.NET). However, I do think that I became productive within a reasonable amount of time.

Looking back, I can safely say it took me about 80 hours to go from expert ASP.NET programmer to productive WPF programmer.  That being said, I do not know how long it would have taken me to go from expert ASP.NET programmer to productive Winforms developer. Something tells me it wouldn’t have been a number that would have made us use Winforms instead of WPF.

Should .NET Auto Properties Have Unit Tests?

Should .NET auto properties be unit tested? It is very easy to argue that testing auto properties falls into the “testing the .NET framework” smell and is a waste of time. However, experience has shown me otherwise. This is something that I’ve gone back and forth on many times since auto properties were introduced. For the time being, I think I’ve reached a conclusion. That conclusion is yes.

 

I typically do two types of testing: 1) Test Driven Design, and 2) Test while/after unit testing. Let’s consider these two scenarios.

When doing test driven design, there is no question. You should write tests for your auto properties. Test driven design is not about testing; it’s about design. The rule of thumb is that you don’t write any code without a test dictating its need. Case closed (in general).

Things get trickier when doing test while/after unit testing. This type of testing is more about creating a test harness. When writing tests after the fact, I know that the property is implemented using auto properties. Therefore, if I am taking a white box approach, I know that my implementation of the encapsulated property is simply the .NET framework. Following that line of thought, testing auto properties is testing the .NET framework. However, I tend to view test while/after testing as a test harness of the public contract. This is black box testing. A public property is an encapsulation, and therefore it should be tested. It’s not uncommon for an auto property to be converted into a regular property as an application lives on. I’d have to say that I would want a test there to capture any publicly facing change in that encapsulation.