Archive

Posts Tagged ‘project management’

The impassionate and NNPPs are not that destructive

January 8th, 2009 Comments off

I’ve just read two interesting blog posts this week, Jeff Atwood’s Programming Love It or Leave It and Jay Fields’ The Cost of Net Negative Producing Programmers. Jeff Atwood basically thinks that people who don’t have passion for programming should not go into the field while Jay Fields thinks that poor programmers add significant cost to any project and should not be in the industry as well. If I were to read these a year ago, I would have wholeheartedly agreed with them. After all, I too had to maintain the very poor code written by incompetent programmers and couldn’t help but wishing they were never programmers in the first place. And I had strong opinion in passion being one of the top criteria for hiring programmers and felt bad about those who are not passionate enough to spend extra time learning stuff beyond the work at hand. But a year working exclusively in a managerial role has changed my view on that quite a lot. Don’t get me wrong, I still think passion and talent are important attributes of developers, it’s just that they are much less important than what I used to believe.

Indeed, when you are in a position to receive projects from clients and responsible for hiring people to accomplish those projects, you’ll quickly realize one thing: there are just not enough talented or passionate developers, much less those who are both passionate and talented. Truth be told, I was extremely selective in my hiring to the extent that I was infamously known among the HR department as a “candidate eliminator”. And yet, I think less than 5% of those I selected into onsite interview met both criteria. That said, if I had rigidly maintained my rules of placing passion and talent before any other, I would never have found enough people for all the projects. In such situation, there are 2 things one can do: give up and reject the client projects for not being able to find enough members to staff in, or staff the best you can and find ways of accomplishing the projects. Now, nobody in his or her right mind would go with the first option.

After spending more than a year working with impassionate and not talented people, I have come to realize that a team which has such developers can still deliver good result. Now, among those people, I have yet to find a person who is passionate but has poor programming skills, but the remaining categories (impassionate but talented and impassionate and not talented) turned out to add value to the team in one way or another. Specifically, I realized that impassionate developer can still be good developers. These developers would rather go home early and spend time taking care of their family or pursuing their real passions. They never write any blog or participate in any open source projects nor do they have any plan to do so. And they only learn things as they are needed instead of browsing through latest books and blogs to learn about the trendy things. But when they do something, they do it with utmost attention and most importantly, they write good code. That should not be a surprise. You just need to realize that good developers are, well, good developers regardless of whether they spent 8 or 16 hours per day programming. (Although the one spending more time may learn more.) As a matter of fact, two developers in one of the projects I worked on were not passionate about software development at all. They just realize that programming is something they are good at, so they do it to get the money to spend on the things they really love. One guy’s passion is photography, but he is smart enough to know that he can’t make as much money being a photographer. He loves it, but he simply has no talent for it.

I’ve been talking about good developers who are not passionate. How about those who are both impassionate and have bad programming skills? I worked with them too, and I have to say: such people are NNPPs mostly because they are mismanaged. A good manager will recognize the strengths and weaknesses of their members to put them into the right position. Before you laugh at the idea, think about all the work that need to be done for the projects to be successful. Are you sure that all of such work require really smart developers to do? Do you need good developers to maintain the project’s build scripts? Or setup a build system? Or evaluate a tool? How about writing project documentations? Or migrate one source control system to another? Simple bugs of well understood components (or even more complex bugs but have the new code reviewed by good developers, but that’s another story)? The point is, in just about any software development project, there are always some work which smart and passionate people hesitate to do (and may not do it well if they have to do it) but enthusiastically accepted by others. Let the latter do such work, they are neither passionate nor smart but they work for the pay in order to do things they really love. Therefore, they are willing to do so and even feel happy for not being asked to do more than what they are capable of doing. And you, the passionate and smart developer, can be happy too. The right-person-for-the-right-job is the name of the game.

Having said all these, sometimes some people just don’t fit to your project, then you have to let them go. But the point remains the same, things would be much easier if we can find all the top guns and put them into the team. But we simply can’t. Sometimes, we have to live with what we get and do the best about it. Just face it. And happy programming.

For God's Sake, Forget Brooks' Law and Staff More People!!!

February 15th, 2007 7 comments

In 1975, Frederick P. Brooks wrote one of the most influential books in the software engineering field, The Mythical Man-month.  Within this book, the essay with the same name, The Mythical Man-month, is cited the most by many software managers, but unfortunately, it is much less often read or understood.  Read more…

Are Quality Control Engineers Necessary?

February 5th, 2007 13 comments

Hai raised a question about the need for QCs in a project team.  Basically he described an situation in which a manager was probed by a developer who believed QCs were not necessary for the project team because developers and BAs could handle all the QC’s tasks, and thus, having the QCs was an unnecessary effort. Read more…

Book Review #1: Behind Closed Doors

January 23rd, 2007 Comments off

Behind closed doors – Secrets of great management, by Johanna Rothman and Esther Derby, walks the readers through a story of a mid-level manager, Sam, who turns a group of “disconnected” people into a single jelled team who works together to achieve the organization goals. Read more…