-
Get a monthly update on best practices for delivering successful software.
When you're in software development you sometimes get called in via the Bat Signal -- a project is going sideways and management feels they need more bodies or different bodies to get the thing back on track. For a while now we have turned down "gasoline" work (see The Mythical Man Month on throwing gasoline on the fire by adding more developers) but still do a fair amount of toxic software project remediation.
In one particular case the system in question was several months late and substantially over budget. After a few days of reading documents, interviewing developers and meeting with stakeholders, one thing stood out. This system -- we'll call it "Cool Beans" -- was in fact "Cool Beans 5," i.e. the fifth version of this system. I asked the product manager the obvious question: "What was wrong with versions one through four?"
A whole lot of years ago, maybe back in 1992, I went over to Gary Becker's home to install a gopher client on his mac. I remember it was one of those brick macs, though those were already being supplanted by newer mac models. I also remember making a decision to install an early web browser on his mac, even though there wasn't a whole lot of content there compared to gopher. I talked his ear off about how it was so easy to put in actual links to other documents, sort of like citations that would take you to the other documents instantaneously. I thought at the time that this would change the very nature of how people would read and use written materials. Given how little text was actually online at the time, this seemed pretty far fetched. Witness that I got fired from a project in 1994 for having the temerity to suggest that Ameritech put it's Yellow Pages online. Well, it turns out that I was right.
Fast forward 16 years. Now that same Gary Becker is sharing a blog with the well known Federal Appeals Court judge Richard Posner. In a post from this past June 23rd, Judge Posner takes on the accelerating decline of the newspaper industry and proposes some legal solutions to the crisis. The nutgraph is this:
[I]t is much easier to create a web site and free ride on other sites than to create a print newspaper and free ride on other print newspapers, in part because of the lag in print publication; what is staler than last week's news. Expanding copyright law to bar online access to copyrighted materials without the copyright holder's consent, or to bar linking to or paraphrasing copyrighted materials without the copyright holder's consent, might be necessary to keep free riding on content financed by online newspapers from so impairing the incentive to create costly news-gathering operations that news services like Reuters and the Associated Press would become the only professional, nongovernmental sources of news and opinion.
Judge Posner's assessment of the situation and his proposed solution constitute a cognitive, practical and freedom of speech failure.
Topics: newspapers
The flip side of my advice to business people to start treating your developers like adults is that developers have to start behaving like adults. What does that mean? Well, my point is that in order for business people to include developers in business discussions, developers have to be ready and willing to understand and participate in those discussions. And that means a little bit of homework.
For developers to understand why this is important, just think about the client/stakeholder you've worked with who has been the most willfully ignorant of the software development process -- the sort of client that demands things that are hard or impossible to do with software and then throws a tantrum when someone tries to explain this to them. Who wants to work with that person? No one. Think of how ineffective that appdev team is with this person gumming up the works and whipsawing the team with unreasonable demands.
Now put yourself in the shoes of a business person who is dealing with developers who are ignorant of basic business concepts. Why would you entrust such folks with any degree of authority for developing a new software product for your company? You wouldn't.
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
-- Tom Smykowski
I get a lot of grief when I talk about agile practices and how it ends some inefficiencies, i.e. less personal activity during work hours by developers. One commenter on my last article on the benefits of pair programming put it thusly:
It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.
He's right, but not for the reason he states. Pair programming is still better than solo programming in almost all cases. Treating developers like children, however, is a sin that is pervasive in many businesses. In my advocacy for pair programming, I was subconsciously pitching my message to product and development managers in large organizations.
Continue reading »
Well, GWT 2.0 RC1 (yes!) is out. I was going to wait for a while with some of my new projects until switching them over to GWT 2.0, but given the pace of the GWT 2.0 project, I may just switch them over now rather than going through a painful migration.
I'm especially eager to use UiBinder to do declarative UI creation. Just specify how your interface should look in XML:
Continue reading »
I used to scratch my head at the name for the JavaScript library qooxdoo. That's until I ran into the developers of the library at an Ajax Experience event in Boston a few years ago and they pronounced it "Kucks Du" as in "Was kucks du" or German for "what are you looking at?"
Beyond the basics, qooxdoo is a mature collection of JavaScript widgets, despite the authors' conservative versioning policy (they're still only at 0.8.3).
It's taken them long enough, but they've finally released a wrapper for GWT, named QxWT. Best of all, they have a commercial-friendly open source license. If you're put off by GXT and it's license, you owe yourself a look.

I'm gathering as much as I can on Griffon and how people are using it. Some things you can translated from Grails, but not everything. So here, as a public service, is the first of many Griffon tutorial pointers.
Dabble->Scribble has a nice blog entry on including log4j logging in Griffon. My favorite part? One of his goals for logging is to "Filter out the cruft from Groovy's massive stacktraces." Amen.
We're currently in the process of interviewing candidates for 1-2 Senior, and 2-3 junior level Rails Developers, and I'm wondering about the skills that are most critical, and how best to identify the best candidates.
My normal interview process flows like this:
Independent of the language they will be working with, I've found decent success with having candidates answer some standard dev questions, solve a basic coding problem, and demonstrate their ability to whiteboard a design.
The problem is that it doesn't scale. When we've opened up positions in the past, either Senior or Junior, there have been so many applications that its hard to contact them all. This leads to a reshuffling of the tasks and matching criteria, in an attempt to identify the 'best' matches, and 'filter out' the others. So instead of calling each candidate first, we might simply reply to them with the details of the coding assignment. I've seen 40 people send the "I'm an extremely hard worker, very interested in your position and would do anything to join your wonderful company" cover letter and resume, and then get whittled down to only 10 candidates that actually submit the assignment. (Note to applicants: 'showing up' is an important first step!)
I came across an interesting post titled '11 tips on hiring a rails developer' which mentioned some 'filtering' criteria to identify the best candidates
You can read the full description of each one, but there are a few of these that I wanted to highlight:
So each of these tips is meant as a heuristic or proxy of the true underlying ability. Any time you are making generalizations you are going to miss out on a few exceptions, but hopefully you end up with what you are looking for.
Starting with the most controversial first, (#5) while I like the idea of giving a strong preference to someone that has a rails blog, and loves Ruby, Rails, and Web Development enough to be opinionated and spend their own time ranting about it, I'm not sure I could make it a filtering criteria. Doesn't that seem a bit strong?
I feel the same about (#4) Open Source contribution. I think its great if they have it, but I'm not sure I would reject any candidates that haven't contributed to open source.
While I've met many systems administrators that (#6) don't have a degree, and are very good at their craft, I haven't really encountered many solid developers that don't have a degree. That's not to say they aren't out there, I'm just saying I've never encountered them, and I'm reluctant to use it as a filter. Do you think that there are many strong Rails developers out there without degrees? (I don't care if they have a CS degree, but I think I prefer that they have some kind of degree)
As it relates to (#1) and (#11), I know for sure that the economics of finding a candidate through your own network and contacts can be less expensive than the recruiter fees (assuming you find a decent candidate and don't waste a lot of your own time doing it), and if you are able to find someone directly, it frees up cash for such amenities as 'New Macbook Pro', 'RailsConf', and 'Fridge full of XXX'.
I really like what Andy Singleton describes regarding how his team at Assembla is organized and tackles Agile Development, and on the right project, I'd really like take his advice and try this one:
"Don’t interview. Just pay people to join a project, pull a task from the queue, and find out what they can do."
Anyways, I'd be very interested in your thoughts regarding what makes for a Solid Rails developer, where you find them, how you keep them, and what you've learned.
(Oh, and if you know any passionate Rails Developers in the Chicago area, send them over!)
Topics: assembla, blog, career, developer, development, Interview, job, Open Source, rails, ruby
Never get involved in a land war in Asia.
-- Vizzini, The Princess Bride.

Also, never get involved in a religious war about statically versus dynamically typed languages. Well, maybe just this once.
Periodically, an angry Javascript developer will let loose and flame GWT as a misbegotten spawn of evil. Then all the GWT developers point and chuckle and move on to developing more cool applications. Every so often, though, someone will make a thoughtful comment about GWT, and then we have a fruitful discussion that helps clarify what GWT is and what it does and doesn't do well.
William Shields has either posted such a thoughtful comment or a very high end version of a flame, entitled Lost in Translation or Why GWT Isn’t the Future of Web Development. It is well worth reading, along with Google's Joel's somewhat heated response.
Topics: dynamic languages, GWT, PHP, ruby, static typing
It's been out a few weeks, but I thought I'd point out that's it's been pushed. Mostly some changes to the LayoutPanel.
Topics: GWT

With the release of Google's Closure Tools comes the perennial misunderstanding of what a compiler is. When we have a compiler that takes in C or C++ code (pick your poison) and produces machine code for a particular chip, it's clear that the output is not the same as the input. But when you have a JavaScript to JavaScript compiler that' supposed to make the resulting code more "efficient," it may be tempting to think of it as something just like a compressor, like Packer.
Continue reading »
Topics: Compilers, Compressor, Google Closure Tools, Javascript, Packer

Google has release Closure Tools, the set of tools they used to write applications such as Gmail. What is it? It consists of three parts:
So it compiles JavaScript into JavaScript and makes it behave more like a statically typed language.
Since this system has been in use at Google to develop real applications over a long period of time, I expect it to be a fairly robust system. In many ways it solves some of the same problems that GWT is trying to solve, but in a different way.
I'll see if I can kick the tires over the weekend and post about it next week. So many cool tools and frameworks, so little time...
Topics: Closure Tools, Google, Javascript
Whenever you can get a free, publicly available place to deploy your applications, your first instinct is to grab it with both hands. Google App Engine is one of those places. Each developer can deploy up to 10 different apps in development mode.
I've been working on a grails app recently that uses the grails App Engine Plugin. Along with the GORM-JPA Plugin, which gives you some of the usual grails GORM goodness, you can write some reasonably interesting grails apps.
Continue reading »
Topics: App Engine SDK, Google App Engine, Grails, Groovy, Java
Just got my hands on a copy of Android, Wireless Application Development by Conder and Darcey and have been working my way through the first three chapters (really, the actual development starts in chapter 3).So far so good. Some of the pseudo JVM (Dalvik) takes a little bit of getting used to, but it's not really that bad. I'd say that the real thing that pops out at me is that I want a way of developing iPhone and Android applications at the same time, without having to jump through hoops to do so.
I should have a full review of it up in a week or two.