weblog.masukomi.org

I just read an article that compared the crowd management techniques used in the stadium in ancient Pompeii to modern techniques, and while it’s an interesting read all by itself, and I do recommend you read it, I got to wondering about how similar ideas would apply to software design.

Build a bigger bathroom.

He’s actually talking about the bathrooms and concession stands but there are a couple applicable bits here: The bathrooms are an incredibly important part of any stadium. They also have nothing to do with the core purpose of a stadium. Keith recommends three things in regards to their creation:

It’s so obvious you have to wonder why people haven’t been doing this for years now…

Witten proposes an incredibly simple and good way to evaluate a potential employee’s code skills during the interview. Instead of asking arbitrary code questions ask them to send in a code example they’re proud of before they come in and actually go over that code with them during the interview.

This is a much more realistic test for exhibiting coding prowess than some sort of artificial string manipulation problem. Additionally, and this is a hugely important point when performing any interview, it tends to put the candidate at ease to talk about their very own pre-written code, so they’re not sweating bullets and thereby giving you an inaccurate reading.

Update: I just came across a similar post by raganwald wherein he discusses the need for advanced programming skills…which you don’t get without math. ;)

When I was in high school no-one ever convinced me of why math was important and that is my biggest educational regret. Children, and adults for that matter, will neither seek out, nor retain, knowledge they don’t value. It’s all well and good to tell them algebra is important but unless you show them WHY algebra is important they will have no reason to retain it.

I think I understand why people tend to not write tests. Because they believe that tests aren’t something that’s either needed or important.

“Duh,” I hear you say, but bear with me.

Why don’t people believe that tests are something that’s either needed or important? Well, I think one of the biggest contributing factors to WHY is that essentially zero of the learn to program in language FOO books ever mention unit testing. Unit testing has been around in a formal sense since the creation of SUnit back in 1994 ! 1994 I say! That’s thirteen years now. Thirteen years and I could probably count on one hand the number of introductory language, or language reference, books that not only mention unit tests but actually explain why their important and how to use them. Even worse, most languages don’t have unit tests tools built into their core libraries. All the modern languages have fairly comprehensive test coverage but they have to use external tools to write those tests. How crazy is that? We have this common programming task that we all agree is critical to releasing a stable version of the language but it’s not important enough to build into the language. Wha?!?! The end result is that since we don’t teach tests as being even noteworthy when teaching a language no-one learns that they are important. For the most part people just don’t seem to understand the value of tests until they’ve been in the industry so long that their feet are riddled with holes.[1]

Mike Clark, and others, suggest [writing “Learning Tests”](http://clarkware.com/cgi/blosxom/2005/03/18#RLT1 “writing “Learning Tests””) as a way, not only to learn a new language, but as a way to accrete a repository of what you’ve learned about a language. I think this is a GREAT idea. Imagine if every book that taught a new programming language showed you not only how to do something but then followed it up with how to confirm that you didn’t screw it up by demonstrating how to write a test for it? People would start to see test writing as a standard part of the software writing process. It would be “just what you do.”

Imagine the impact that including unit testing as a standard part of the learning process would have on the software industry! Sure it might take five to ten years before we started to see the results from it but wouldn’t it be worth the wait?

[1] From having shot themselves in the foot on many prior occasions.\

If you look at Mingle, the project management tool we’ve been working on… On that tool I happen to know that their test base is twice as much as their code base. So, two-thirds of the code in that product is tests, and that allows them to do quite violent things. I know that a couple of months ago they made a very fundamental change to the database scheme. I mean, we’re talking, utterly to the guts of the database scheme. And they did that and… it wasn’t even an event worth talking about. And, when they were planning to do it they were saying ‘Yeah, yeah, we’ve got to fundamentally alter the core tables in this application… Yeah we’ll do that, and it’s not a big deal.’" -Martin Fowler (paraphrased)

I just had a thought. Companies looking for new developers should try to only ever hire from startups and similar small team companies. Why? Because people who work for small startups can’t hide. You can be reasonably certain that someone who has managed to survive for more than a few months in a small dev team puts out decent code at a good pace. Small companies just can’t afford to keep crap coders or non-producers on their payrolls. Such a simple filter. And, I think most of the time it’s an even better filter than that. In my experience small co people tend to be more flexible and more self-motivated.

The software development industry is plagued with bad practices even though so many of us know better. A HUGE portion of this problem is that to really start, and continue, working the way we know we should requires buy-in from our managers and coworkers. And it’s not just a conceptual buy in that we need. People need to really get the religion. But, you and I both know that we can’t realistically expect the rest of the company to change everything at once.

Most web developers will agree that unit tests are great, and some even write them…but I know very few developers who write unit tests for their JavaScript, but it’s not really their fault. Most don’t know of good unit test systems for JavaScript and / or don’t write their JavaScript in such a way that you even could test well. This means breaking all the functionality into discreet functions and objects instead of writing old-school procedural crap. There’s also the obvious problem that most of your JavaScript is tied to the browser and the current page. So how do you test stuff in the page? Well, JsUnit lets you do just that and, seeing as I’ve just added a javascript implementation to the FizzBuzz Overthink you can run over and see how to do it for your apps too.

Another graph for another friend who asked for a flow chart of the branching and merging described in Best Practices for Web Development html
pdf.

Update:

Michael says: I’m a little unsure, from you diagram, how, if your trunk contains two completed and merged features that aren’t yet live (video upload and REST API, say) you put one feature live without putting the other live. It looks like code only gets to the live branch via the trunk, but it seems from your diagram that the trunk could contain all manner of complete and semi-complete features.

A flow chart for a friend demonstrating, step by step, how you’d go about using Darcs (or any other distributed version control system) with SVN / CVS. He needs to do it for the most common reasons:

1. it’s a pain to branch and merge with CVS.\
2. he’d have to coordinate with other departments like QA to get them working off of whatever the current release branch happened to be at the moment and convince them that it was a good idea.
3. currently his co., like so many, is working off of a single development trunk. There are no other branches.

Click on the image to get a full sized version. Or download the dia file here.