Archives

photo credit: Daquella manera

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?”

Share/Bookmark

photo credit: Ian Muttoo

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.

Share/Bookmark

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.

Share/Bookmark

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

photo credit: sdminor81

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.

Share/Bookmark

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:

Share/Bookmark

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.

Share/Bookmark

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.

Share/Bookmark

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:

1. Quick Phone screen evaluating basic development skills, background, availability, personality
2. Basic coding problem (less than 1hr to complete)
3. Phone call to review coding problem, ‘how would you handle X?’ questions, etc
4. On site interview targeting: Communication, Communication, Communication, (and tech)
5. Final decision

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:

1. Don’t use Monster.com or recruitment agencies.
2. Poach Talent from other companies!
   
3. Don’t hire someone that doesn’t know Rails at all.
4. Look for open source contributions.
5. A personal Rails blog is required.
6. A university degree is not important.
7. Be wary of holes in proficiency.
8. Avoid brand-name superstars.
9. Hire perpetually.
10. Have a company Rails blog
11. Special compensation.

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’.

If I was in charge of everything

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!)

Share/Bookmark

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.

Share/Bookmark

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.

Share/Bookmark