Well, that was a bit of smoke and mirrors. That behaviour doesn’t ship directly with SketchFlow at all. You can find it in the Snowboarding sample application and drag it into your project directly if you want, but that only works for WPF prototypes.

After hacking around a bunch of things that I would consider bugs in the Silverlight 3.0 SDK, I managed to port this behaviour to Silverlight. So, if you want to drag and drop items between listboxes in your Silverlight SketchFlow app, this one is for you.

Get it here: SilverlightDragDropCopyItem.cs

You just have to drag it into the [blah]Screens folder of your project, and it will show up under Assets -> Behaviors.

http://mags.acm.org/crossroads/2009fall

You can jump to it by clicking on the “Career Advice: …” link on the front cover. Unfortunately, I no longer have a print subscription to Crossroads, so I won’t get to see my work on paper. But I know it’s out there

Now to start working on the next one…

I think I’m going to work on the powerlifting article next. I also had a bit of inspiration at the 2009 Toronto Code retreat, where I threw together a solution to Conway’s Game of Life using signal processing primitives from SICP (unfold, map, reduce, etc) in Python. I should probably write that up as well.

Finally, I’ve been putting a lot of my spare effort into a script for a videogame… so looks like the writing bug has hit for realz. It’ll probably get even worse when the sun disappears and I stop spending so much time on the beach.

1. XML should/shouldn’t be used as a data storage format
2. The best/most maintainable way to approach concurrency for performance is X
3. The best/most maintainable way to approach concurrency for responsiveness is X
4. Object-oriented programming is better than / worse than / the same thing as functional/straightline programming

And so on.

One of the few things that graduate school taught me is that a lot of problems that identify as “new” have actually been treated rather thoroughly somewhere back in the annals of time. It’s somewhat embarassing to have to learn this lesson as a software engineer, I think, since we’re a pretty young field as far as intellectual disciplines go.

I suspect that our ignorance of the past is because a lot of the good discussions surrounding them are in the primary literature, which for some reason tends to bring out a stubborn streak in many of the practitioners I know. I think that by suggesting articles from academic journals, some might feel that I’m being snooty, stuck up, or otherwise just showing off my education. I haven’t quite figured that one out yet. But it happens.

However, I feel like people are missing out. There’s some really good stuff out there. For example:

• To address point 1, the aptly-named Michael Stonebraker wrote a great paper on why XML is a terrible data storage format. (Thanks to Rachel Pottinger, my data management professor and supervisor.)
• When researching point 2, I came across a bunch of wild algorithms from the early 80s for parallelizing problems that appear inherently sequential, like searching linked lists. These were written for the Lisp machines, which had hundreds of 1-bit “processors”.
• When talking about point 3 in an operating systems course, we read a pair of papers (here and here)that each put forth reasons why events or threads were more appropriate for this task.
• Point 4 has been discussed cogently in some very old books, many of which I babble about incessantly (the Structure and Interpretation of Computer Programs, and Object-Oriented Software Construction).

It seems counterintuitive to me that so many current problems could have been so well addressed such a long time ago, but I guess it’s the nature of academia to predict (or invent) problems long before they actually become a pain point. The result of this is summed up nicely by Michael Stonebraker in the paper I linked above:

Most current researchers were not around for many of the previous eras, and have limited (if any) understanding of what was previously learned. There is an old adage that he who does not understand history is condemned to repeat it. By presenting ‘ancient history’, we hope to allow future researchers to avoid replaying history.

While you’re hunting for a mentor, you can get the next-best thing by reading the writings and the code of “famous” software engineers. Books like Programmers at Work and Beautiful Code are great for this sort of thing. And tons of very clever people write open-source software that you can peruse.

While seeking a mentor is a somewhat obvious way to improve, inverting that relationship by looking for a mentee — even when you’re very green yourself — is, in my opinion, a great way to improve as well. Einstein’s old adage of “You do not understand something unless you can explain it to a six-year-old” comes into play here.

I’ve had quite a few opportunities to teach intro-level computer science and software engineering courses, and these experiences clarified a whole bunch of things for me in a hurry. As I sought explanations and examples that would click well with an entire class, I started to learn what methods of organizing programs in the small would communicate well across a broad audience. I try to carry those lessons over into “real-world” projects, so that other developers can (hopefully) make the appropriate modifications to work I’ve done regardless of their skill level.

Plus, working with people who are just starting their journey is refreshing. Their optimism and the breadth of (often strange) approaches that they take to problems that to us are old hat is a lot of fun.

So, get out there! Give, take, interact. Humans are the interesting part of this craft, after all.

The exercises in this chapter are interesting because they are so varied. They don’t really get more difficult, they just exercise a whole grab bag of different things that the authors are trying to show you. (The ones that the authors warn you are challenging are usually suffixed by “The answer to this would be worth a Ph.D/Turing prize/etc”. I haven’t been attempting those ones.)

Enjoy.

A few years ago, I read Code Complete, which I’ve talked about at length here before. One of the first things that impressed me about that book was that it laid out a very precise reading plan that all newcomers to McConnell’ company had to follow.

Until that point, I’d mostly picked up new books and tried new techniques whenever I felt like it. If I heard of some reference or thought of some activity that would be beneficial to my learning (e.g. reading book X, or doing programming exercise Y) I would jot it down in a looong to-do list, and hope to get to it eventually.

After I saw McConnell’s suggested reading list, I went back to my own bucket of learning items and loosely organized them into a sequence. I also defined what it would take to actually get the desired benefit out of each activity. For books, this meant anything from skimming the text to doing all of the exercises contained therein. For extended exercises or activities, I gave a bit of thought to the scope that would be required to actually learn anything from the attempt.

This has ultimately resulted in me getting more out of the time I spend learning about my craft. For example, I’d previously read the Structure and Interpretation of Computer Programs. It only took me a week, but I’d be hard-pressed to tell you anything about the last four chapters of the book.

I then read it again, about a year later. This time it took me significantly longer to finish, but I hadn’t retained much of it. I decided that, in order for this activity to be worthwhile, I’d have to do a significant portion of the exercises in the book.

So now I’ve been working on SICP for about a year, and I’m not even halfway done the work I believe I will have to do in order to consider myself done with it. Yes, that’s a very long time. But, the value I get from each session is much higher than it would be if I was just skimming the same material. That is, every time I sit down with SICP and a stack of paper, I come away an hour or two later feeling a whole lot wiser than when I sat down.

I feel that the few hours that it took me to organize my list of “things I’d like to learn about” into a loosely annotated and ordered plan has helped me a lot. Hopefully it might help you as well.

This is unsurprising. Object-orientation is (ostensibly) taught to most of us in school as the one-true-way of doing things. It’s rare to find people who do not equivocate software-design-in-the-small to object-oriented design.

A couple of years ago, I decided that I wanted to learn “functional programming”. My first serious attempt was in OCaml. However, once the wheels hit the ground, I felt like I had returned to highschool. At that time, I knew the syntax and vocabulary surrounding objects, but I had no idea how I was supposed to use them.

So, I reasoned, I needed to learn how to design functional programs. I needed to learn “functional design”, for lack of a better term.

After a bit of consideration, I remembered that there are a lot of very famous universities that teach the basics of program design using Scheme. (This is also true for OCaml, but the Scheme ones are arguably more famous .) This was perfect — I needed to learn how to design programs all over again, in a “functional style”. So, why not go back to basics? And thus did I seek out MIT’s CS1 old-style curriculum and the Wizard Book — also known as The Structure and Interpretation of Computer Programs (SICP). (They’ve since switched to Python, I think. I imagine the spirit is the same.)

You may notice that I’ve been putting “functional design” and “functional style” in quotations. The reason for this is that I quickly discovered that such things do not actually exist.

Let me explain.

The fundamental exploration that jumped out at me in SICP was this: Let’s say you have a programming model that supports first-class functions, and does a pretty good job of supporting immutable data. What reasonable methods of designing and implementing programs can we arrive at using this model?

And the answers are legion. A program can be viewed as a mathematical function. It can be viewed as a signal-processing device over finite sequences of discrete signal elements. It can be viewed as a signal-processing device over infinite sequences of discrete signal elements. It can be viewed as a processor of a domain-specific language. And so on.

What SICP really shows you is a variety of methods that you can use to design programs-in-the-small, with object orientation being only one of them. So now, when I’m working on a new chunk of some big project, I find myself thinking not “where are the objects”, but instead “what happens if I view this problem as, say, a signal processing problem?” Even more importantly, when I read someone else’s code, I can ask myself the same thing.

The reflex of explicitly asking myself this question when faced with a new design problem really helps to understand it from multiple angles, and to identify the things that are going to be the hardest to model or extend in any feasible design. And that lets me focus on clearing up the things that matter.

I won’t pretend to be a master of any design-in-the-small methodology. However, I’m now aware of a whole set of possibilities that I was once largely ignorant of, and this knowledge helps me in a bunch of little ways every day.

Analogies are useful things. When I have the pleasure of sitting down with a group of people who are really excited about what they do, and who are discussing a very challenging problem, what happens almost immediately is that someone will draw an analogy to help the discussion move forward.

This definitely gets the conversation moving. It’s the direction that is the rub. It’s really easy to let an analogy run wild, to the point that it gives you almost no insight on the problem you were initially trying to understand.

As an example: Just the other day, I was at a great lunch meeting where the discussion was centered around software testing. Someone mentioned that developers often write software with the assumption that the user is usually going to do things in a very predictable fashion, and that ‘weird’ cases are exactly that — weird. In this sense, the developer is living with the same set of assumptions as a traditional performance artist, where interactions are scripted, and mess-ups are assumed to be few and far-between.

It was mentioned that perhaps a better mindset would be that of the improv performer, where the fundamental assumption is that everything is going to be unexpected. The analogy was a good one — it clarified that there were two sets of axioms we could be working against, and perhaps that one of them was more appropriate than the other.

Within twenty minutes, we were talking about this one time that someone had been to a play where the lights had gone out, and the crew decided finish the performance by candlelight. The analogy had run amok. We were certainly still having a stimulating conversation, and possibly there was a lot of value in what was being said. But we’d completely lost the original point.

Usually when I’m involved in a conversation that is centered around an analogy, I try to bind the concepts within it to concepts in the topic that we’re actually trying to understand. When I hear a lot of those threads breaking, that’s how I know the analogy is taking on a life of its own.

Why do I think this is so important to being a good developer? I have two reasons. The first: When I encounter software that I think is particularly pleasant to work with, it is because the high-level metaphors that are being used to describe things are obvious and are used consistently throughout the product. If you look at a lot of patterns in software design, they’re essentially dressed-up analogies. (A “bridge” is sort of like a physical bridge because etc… an adapter is sort of like a power adapter because etc…)

The second is that I’ve observed that many smart people that I like to learn from tend to use analogies heavily. I don’t often get a lot of time with those people. And so, to really make sure that I’m getting the most out of my time with them, I like to carefully monitor the evolution of their analogies. After all, I can spend my afternoon talking about botched performances with pretty much anyone, really

(Steve McConnell does a good job of dissecting several analogies used to describe software development as a whole in his massive Code Complete, 2nd edition. I can’t say that I particularly like the one he finally arrives at (“it’s like construction”), but at least he is thorough in itemizing the components of the analogy that work, and the ones that don’t quite mesh well. It’s that sort of exploration that really helps you understand the original problem, in my opinion.)

I struggled with this for a while. This makes it really easy to cut corners. It makes it really easy to think of your job not as a craft, but as a requirement that just needs to be fulfilled as cheaply as possible. At least, that’s what it does for me.

I’ve managed to reconcile this within myself by the analogy of the contract artist. While in Italy, I read and heard countless stories about great works of art that were commissioned by the state. These works had very real and often very challenging engineering requirements that had to be met. And yet, there were myriad details that went into the creation of those works that had nothing to do with explicitly fulfilling the requirement, but that essentially gave each work its own life.

That’s how I think about what I do. And if you look around, there are a ton of other professions that are essentially the same. A cobbler just has to fix your shoes, but it’s the material he uses, the lessons he has learned, the attention to detail that he takes, that affects how well the job is done — even if it’s in the details that only another cobbler would notice.

When I worked in a restaurant as a teen, I learned that being called a ‘shoemaker’ was an insult. It meant you’d paid no attention to what you were doing. Now, years later, I see ‘shoemaker’ as kindred spirit.

Anyways, I’ve decided to start fleshing out these ideas by writing them out in short-form. I’m calling them “software-shorts”, and the first one is going to be posted in about 2 minutes.

Whenever I start agonizing at how long it takes me to get through projects like this, I am reminded of Peter Norvig’s essay Teach Yourself Programming in 10 Years. Damn these epic journeys.

Recently I’ve actually been applying myself (no pun intended) to the exercises and assignments that come along with the free online distribution of the book. This sometimes necessitates some minor porting efforts, because the book and materials were written for MIT Scheme, and I’m using PLT/mzscheme with DrScheme since I’m too feeble to learn emacs at this point in time. (Every time I punch a keychord to do anything significant in emacs, I expect to hear it shout “HADOKEN” or something as Ryu would in response to my comparatively-less-complex controller gyrations in Street Fighter.)

Anyhow, I’m dumping all my SICP related stuff on a project page, in case your day is going so badly that perusing a neophyte’s Scheme code appears preferable to what you are doing. That page is right here.

It’s challenging to work with code that has a history, but I find it to be a lot of fun. (From a 30000 foot view, that is — at any given time when I’m in the thick of it, you will hear me cursing under my breath just like anyone else would be.) I’ve developed my own little arsenal of techniques that I use to get things done in such an environment. (The most useful one is to always remind myself that this is software that has been _successful_, and that it has intrinsic worth, even if I am working in a particularly hacky corner of it.)

Anyhow, a few months ago it occurred to me that it would be great to have a book about this sort of thing; about the mindset you should be in when working with old code, the techniques you can use to mitigate the complexity, etc. It didn’t take much poking around to discover Michael Feathers’ book, and I’m glad I did. This is, in my opinion, one of those books that anyone in a software-related field should read.

While I picked up quite a few little tips from Feathers’ book, there were three major contributions that I considered to be the main ones:

1. The definition of ‘legacy code’ as ‘code that is not under test’. By casting the problem of maintaining an older system in this light, Feathers moves the problem from the realm of genericity (our code is hard to work with and we need to do something) to the realm of specificity (our code is hard to work with, so we need to find ways to get it under test.) This gives you a specific problem to attack.
2. The identification of the “seam” as the primary concern in a legacy system. A seam is defined as any point in the system where one component may be stubbed out or otherwise decoupled so that you can test an interacting component in isolation. This focus on seams essentially turns your “testing quest” into one of decoupling components from one another, which is (in the opinions of many people much smarter than I) perhaps the most critical precondition for keeping a system maintainable.
3. The simple fact that Feathers has obviously been in the trenches himself many times, and that he speaks of the experience not with despair, but with acceptance and even mild amusement. While many software engineers I know would bemoan the idea that the status quo of system development should be a gradual decay towards unmaintainability, it’s pretty obvious that it happens and that this is a thing that all of us will one day have to deal with, as inevitably as death, taxes, and all that sort of thing. Having a respected individual in the field talk about it so frankly is, well, downright comforting, and I find it helpful to recall that I am not alone when stuck trying to disentangle some particularly heinous code-rot.

I could go on, but there’s little need. In summary: I strongly recommend Working Effectively with Legacy Code. This is the sort of book that I intend to read not just once, but once every couple of years or so to keep the lessons fresh in my mind.

Some things they don’t tell you:

In IIS Manager, you will probably have to:

1. Click Web Service Extensions, allow things that look like they should be allowed (ASP, for one thing). I also had to add an extension for ASP.NET v2.0.50727 that linked to the same ISAPI file that they tell you to add in the configuration of the virtual directory in the ThoughtWorks instructions.
2. Once I did that, the dashboard would at least start to render, but then it would crash while trying to write to some obscure equivalent of /tmp/ in the Microsoft Framework directory. I just right-clicked on that directory, selected Security, cursed at how useless the resulting dialog was, and then set the group IIS_WPG to have write permissions to the directory.

Happy CruiseControlling.

P.S. Thanks to Jimmy for channeling my rage and providing helpful hints here and there. Probably would have taken me a couple hours longer to bang these out if he hadn’t been online.