Tag Archives: software development

Hiring Programmers – The One Question Interview

Posted on by

First off: the blog is back. I will refrain from commenting at any length on why it had gone away, as introspective blog posts about the process of blogging are boring. Sometimes you’re blogging a lot, sometimes you’re not.

I’ve been thinking a lot lately about hiring programmers. I’m launching a new venture, and I’ve been very luck to bring one of my favorite people on board to lead our development team. He’s brilliant, hard working, polymathic and generally willing to dive into things which have to be done but may not be massively interesting. I’ve hired a few other people like this in the past, and when I have the opportunity to hire them again (and the role is appropriate) I always go for it.

I do that because it’s a complete crap-shoot otherwise.  I’ve got it easy – since I wrote a few books on software development between the late 90s and middle 2000s I have a good reputation as a boss who knows how software gets developed. That’s made it easier for me to attract top tier people – much easier than if I was a pure business guy, regardless of however good a business guy I may have been.

So I enjoyed reading Jon Evans’ Why The New Guy Can’t Code. It’s a nice overview of some of the pathologies, particularly the idiocy of the brain teaser interview. Evan’s suggestion is that you don’t even bother interviewing people who can’t say “I got this done” where “this” is a self-contained project. And I basically agree.

The guy I brought back for the new company has been a friend for fifteen years. We went to high school together. So when I hired him I was cheating – I knew exactly what I was getting into (and I made sure my then-business partner was on board so that I had a check on any desire to hire a friend). After that point, however, I was out of rock-star friends who were looking for jobs, so I had to go looking the more conventional way. And in each case, the interview went the same way – we sat in a room and talked about projects for an hour. In some cases I had other people on the team do more conventional technical interviews, but I usually found I didn’t need them – by having someone clearly explain what they had done to build an application I could easily tell whether they actually had the skills they claimed. I could also tell how they worked in teams, and how they thought about problems.

The sample size is pretty small – maybe 30 people interviewed over the last five or six years. And everybody we hired wasn’t perfect. In those cases we usually had some misgivings to start, and we corrected fast. But by and large, we got the rock-stars, or at least the guys in the band. And we never had an issue with competence.

Of course, having a good HR department that knew how to source candidates properly (by going after the already employed at companies that were closing up and filtering out the top few people) helps. But the best people can have a conversation. And phone screens help – you can start this discussion on the phone, and if they can’t start telling you about a project they did within the first few minutes, time to move on.

Another good take on this issue is Why Can’t Programmers.. Program? which describes a great simple test to weed out the obvious non-coders in five minutes or less. Surprisingly, it excludes quite a few people with C/S degrees.

 

Introducing Clickframes!

Posted on by

I’m sure at least a few people have been wondering where we’ve been the last few weeks. We’ve been busy on a number of products, and we released one of them at the end of June. It’s called Clickframes,  and it’s a set of frameworks for building usable, reliable, scalable software faster, better and cheaper.  The original Clickframes concept was based on three observations:

  • Good software requirements can be very useful.
  • Most software requirements aren’t very good.
  • Even when requirements are well thought out, they’re generally created in a format that limits their usefulness.

At ISG, we develop software using a design methodology that focuses on understanding user needs through interviews, observations and deep research. We learn as much about the problem space up-front, do as much work as possible to validate our designs with real users, and only then proceed with the implementation.  This approach works very well for us (and the one time we allowed ourselves to be persuaded to approach a problem differently the results were a lot more typical for the industry), but it requires a lot of agility. Clickframes helps give us that agility by turning static software requirements into a dynamic specification of how the application should work.

Here’s how it works: at some point during the design process we start building an application specification (or “appspec”), which is a description of the web application we want to build. The early iterations can be very schematic – identifying a couple of pages, perhaps a form or two, and a few buttons. As we learn more about the application we can extend the appspec to include additional detail, including specific requirements, security, and flows between different pages in the application.

That’s actually all pretty standard, so here’s where things get a little different. The appspec isn’t a Microsoft Word document, or a stack of index cards, or a drawing on a wall. It’s an XML file, and it’s maintained by the application’s lead designer. By managing requirements in XML, we can generate a whole range of useful artifacts on the fly. The most important is the Clickframes Interactive Preview (click the link for a sample from our Issue Tracker demo), which provides an easy to navigate HTML representation of the application. As requirements change the CLIPs can be easily regenerated. Clickframes also provides generators for conventional requirements documents (the system shall…) and a visualization tool that generates interaction maps of the application. Here’s the Issue Tracker example, generated from the same appspec as the CLIPs linked to above:

A Clickframes Project Map

Once the design stabilizes, we move on to implementing the software itself. Clickframes helps here too. We’ve built code generators for three different web architectures – PHP, JBoss Seam, and Spring WebFlow (the latter two, for the non-technical reader who has stuck it out this far, are Enterprise Java platforms, and the first is a very common scripting language for web applications). This is an area where conventional prototyping tools break down – they don’t provide a bridge to development.  With Clickframes, the plugins give us a skeleton of the application immediately, and our developers and designers can go in and immediately start creating content and the final look and feel, rather than worrying about details like implementing edit checks on form fields.  If you want to see the Clickframes Issue Tracker demo, just click on the link (to log in, enter anything for the username and password).  This isn’t a complete application, by the way – it’s just the generated code, before being customized by a programmer.

We’ve spent a lot of time on the Clickframes code generators and on the architecture of the underlying applications. We’ve implemented a range of features we call “CodeSync” that allow us to regenerate applications even after the development team has started to customize them. This is critically important, because it keeps the requirements from becoming out of date. If a business user, or a a designer, wants a change made, they can have the appspec updated and the programmer can re-run the code generator. It creates a feedback loop that’s often missing.

The final step in the Clickframes project lifecyle is testing. Since we have a version of the software requirements that a computer can understand, we can use it to generate a suite of automated tests, as well as templates for test strategies and manual test scripts. It’s not magic – the quality assurance team still has to do some work, and we can’t automatically generate every single test, but we can save a tremendous amount of up-front work. And developers can have access to automated tests of the final application almost from the first day of development. It saves a tremendous amount of time.

Clickframes is software to streamline development of enterprise applications.  So how much would you pay? Don’t answer, because it’s free – we’re releasing Clickframes as Open Source Software under the LGPL.  You can download Preview Release 1, sign up for the mailing lists, and see some demo screencasts at www.clickframes.org, and you can find a lot of documentation on The Clickframes Wiki, including instructions on how to get started without downloading anything.  The Preview Release is out there to gather feedback – we’ll be releasing new versions at a pretty rapid clip over the next two months, with a goal of 1.0 by the end of the summer. We’re also rolling out some new web site features in July that will make it easier to explore the Clickframes model.

This has been a long road for all of us – we started working on Clickframes back in May of 2008, so it’s been over a year to get to this point. So give it a try and let us know what you think!

(And if you like it, or like what we build, give us a call – we’re always looking for interesting new projects).

Checklists aren’t just for pilots

Posted on by

My father runs a flight school, and over the years I’ve met more than my share of private pilots.  A lot of them fly aerobatics, which involves taking a perfectly good airplane, flipping it upside-down, and performing feats that are not intended to make my mother particularly calm. It’s a fascinating little subculture, and a few years ago I spent a weekend at an aerobatic competition in upstate New York, hanging out with the pilots and generally poking around. What struck most was how safety conscious all of these pilots were. For one thing, nobody took off without going through a simple checklist of key flight safety operations.  They were all expert pilots – one had flown with Chuck Yeager in the Air Force in the 1950s – and had taken off thousands of times. And they did the checklist every time.

More recently, checklists have become a big deal in medicine. The best layman’s introduction is Atul Gawande’s 2007 New Yorker article on the subject. The short version is that by making a list of simple steps, and following those steps every time, you can eliminate “never events” (like taking out the wrong kidney), and dramatically cut a lot of other risks as well. It sounds like a no-brainer, and it probably is. But checklists have met with a surprising amount of resistance, which are nicely summarized by the following two clips from the penultimate episode of NBC’s “ER”:

And the punchline:

It’s network television, and so it’s a bit over the top – but my surgeon and medical resident friends tell that the attitude of the lead surgeon is pretty typical – and that without a champion in the room, the checklist won’t get used. I’ve observed this myself when visiting ORs – checklists were completed, but they were completed after the procedure was over, when the nurse had a few minutes to spare (so my colleagues don’t go after me, I should say that this was not at a Harvard teaching hospital).

So they’re good for pilots, and good for doctors and nurses. And, of course, they’re good for just about everyone else. They’re definitely good for EHR deployments, and for decisions about personal health planning. And they’re good for software development, too. Over the last few months I’ve written several checklists to govern different aspects of our software design, review and deployment policies. We’re all smart people, but we’re not going to remember everything. Over the next few weeks I’m going to share some of the software development checklists we’ve developed, and I hope readers will pitch in with their own ideas.