I was a reference for a senior manager yesterday. At first, the reference started to ask me, “What do you think are so-and-so’s weaknesses?” I hate that question, because it all depends on the context. And I’m smart enough to turn that question around so a weakness doesn’t sound like a weakness. Grr. But then,
At Boston SPIN last night, Tim Lister of “Waltzing with Bears” fame gave a talk about recognizing and managing risk. It was great. If you ever have a chance to see Tim speak in person, do so (Yes, Tom DeMarco is also an excellent speaker, but he wasn’t there last night :-). When I
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