In my last post, I argued that functional and non-functional requirements are unsuitable for the art of describing requirements. I prefer to discuss attributes of the system instead, and then talk about functionality. (Gause and Weinberg wrote Exploring Requirements, Quality Before Design describe how to do this.) But Laurent, in his Misfits, or there’s […]
David, a reader, recently asked for tips about reviewing resumes. Here they are: Read the resume from the top to the bottom. Don’t start somewhere else. Candidates try to grab you with the cover letter or resume. Let them. If there’s an objective, read it. But don’t believe it. Seriously, how many objectives say, “challenging
I read somewhere in the past week that candidates should be willing to work for a couple of weeks or up to a month as a contractor to show potential employers how great they are. (I thought this was in the Boston Globe, but I can no longer find the article, nor the pointer to
I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation. IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months)
I didn’t see NBC’s show “The Apprentice,” but I did hear about it on the news this morning. (Live through a few weeks of “work” with Donald Trump and then he’ll hire you for a job.) Seems as if the first hurdle the contestants had to overcome was selling lemonade in New York. What a
In this issue of Better Software, I have the featured article, No More Second Class Testers! and Frank Patrick has a great article, “Promises and Prescriptions, How the Theory of Constraints can help cure common project ailments.” I can’t give you a URL to Frank’s article, but maybe in a month or so he’ll
I normally recommend against Panel Interviews for most technical positions. However, I’ve recently worked with a group whose panel interviews were quite successful. The positions were for a senior technical leader and a manager, so the candidates needed to be able to present and discuss issues to several people at once as part of their
I’ve been thinking a lot about the comments people made on the Best Practices Don’t Predict Project Success post. (Thank you for your comments.) Here’s my experience. Great people, people with sufficient functional skills and domain expertise can trump process, good or bad. Good process, process appropriate for the context, will help those people. But great people
© 2004 Johanna Rothman. This article was originally published in Better Software, January 2004. “We have world-class developers, but our testers are second class.” I hate hearing that. Too often, it’s true—and it’s not the testers’ fault. How did things get this way? I’ve been in the software industry for over twenty-five years. I can remember
© 2004 Johanna Rothman. Hiring technical managers is different — and more difficult — than hiring technical people. When I hire a technical person, such as a developer, I look for design, implementation and debugging abilities as part of the candidate’s technical skill set. But when I hire managers, the rules are different. Technical managers