free html hit counter
Posted on: Friday, December 5, 2008 by Rajiv Popat

Selecting Candidates Based On IQ And Educational Background Is Highly Overrated.

When I was asked to join a team of recruiters in their recruitment drive in one of the top-notch colleges I discovered how utterly screwed up their recruitment process for hiring college interns was. Almost a hundred students showed up for the recruitment drive. By the time the selection ended that evening this team of recruiters had recruited for their company, what they referred to as the ten best-of-the-best students.

If you ask me the recruitment team had done just as good as they would have done had they written the names of the students on really small post-it notes, stuck the post-it notes on a dart board, blind-folded one of the recruiters and asked him to throw ten darts, hiring students whose name the dart hit.

Saying that they would have done just as well as hitting a dart-board with eyes blind folded isn’t such an exaggeration as it might seem. When you’re hiring from a decently good college that admits students who had studied computers for the last five years, the laws of probability kicks in and you tend to pick ‘some’ excellent candidates. If you randomly picked ten guys my guess is that you would end up with a pie that looked somewhat like this:


This interview drive was quite a long day consisting of questions on the line of:

  1. If you had three balls and were not given a measuring scale to weigh them how would you find the heaviest ball of the three balls?
  2. If you had a cake and an irregular piece had fallen off from the side how would you divide the cake into exactly two equal halves?
  3. How would you find the number of cigarette shops in town?

The parade of funny-questions continued all day and then in the evening when I was told that we had picked ten best-of-the-best-guys out of that drive I looked blankly at the person telling me we were done and after a lot of thinking I said something on the lines of - “Ok. Let’s go home.” 

During the recruitment drive I had approached one of the recruiters and asked him to let me talk to all hundred guys in a room and see which ones of them participate in a group discussion and have opinions of their own. I was told I couldn’t because it wasn’t on the agenda and I had to mention what it is that I was going to speak on. The ‘agenda’ had consisted of one written exam after another on topics like IQ, English and a couple of other exams.

I considered the recruitment drive nothing more than a practical joke both on the organization and on the candidates. When it ended, I was glad it was over; but then the same drive brought up some really important questions about how I recruited my team members, the kind of recruitment I had just witnessed and how distinctly different both approaches were.

Most organizations around the planet seem to give way too much importance to IQ and theory while recruiting but the fact remains that Software Development is a rather practical craft. A huge part of it is done in small and tightly knit teams where not everyone happens to be the smartest of the lot but everyone contributes in the orchestration adds their very own Niche to the mix of successful implementation. Contributions range from developing or testing and goes all the way to being a catalyst.

Using IQ as the only measuring scale of how good a contributor you will turn out to be sounds like a rather impractical thing to do. After all, as sizzling as the idea sounds, IQ does not guarantee applied intelligence, results or success in the real world.

Michael Brotherton makes some rather interesting point in his rather opinionated post, where he describes ‘Why Mensa Is Stupid’:

Here's the latest piece of evidence, a 47 year-old Mensa member who is auctioning off his hand in marriage on eBay. I can't tell if he thinks he's a steal at the $100k "Buy It Now" price, or he just doesn't value his life that much. He's offensive, too, and in my opinion a lazy bastard who should get off his butt and make a better contribution.

I qualify for Mensa (my PSAT score twenty years ago was plenty, and every similar test since). I don't belong to Mensa. I like doing some of the puzzles and games they do, but if that's what being part of Mensa is all about they could drop the qualifications. What's the point to having a "smart club" and keeping others out except to feel elitist? I don't have a problem with people feeling elitist, per se, although I think they're shallow and people so dang smart should go out and do something more productive with their lives!

I've got a PhD, use the Hubble Space Telescope among other facilities, and write novels on the side. I usually don't have time to sit around doing puzzles with people I've chosen to be with based on their SAT scores. I like people of many sorts, and don't pick my friends based on test scores.

Marilyn Vos Savant, "smartest person in the world" and Mensa poster-girl, writes an insipid column. Is that the best the "smartest person in the world" can do? I like to think our best and brightest on this world would contribute something a little more valuable than she has. I mean, she's supposed to be the "smartest," after all. I may not score as high as she does on an IQ test, but I know underachievement when I smell it.

There are a lot of different intelligences, and a lot of different skills. Some great chess players are kind of stupid when they don't play chess (Bobby Fischer comes to mind). Some hunters I know have "wood smarts" that leave me in awe. And there are brilliant artists whose Verbal and Quantitative SAT scores would impress no one, but whose spatial sense would let them toast most Mensa members on many a puzzle. 

Michael is rather correct when he comments on different intelligences. The idea of appreciating diverse set of good qualities and not just labeling someone as good or bad dawned unto me when I saw a struggling developer being heavily criticized by his manager as a ‘mediocre performer at everything he does’; moved to testing and become one of the best testers I happened to work with. The notion that IQ defines intelligence and someone who has a high IQ should be good at everything is just stupidly absurd.

Malcolm Gladwell in his latest book, The Outliers breaks the myth of mapping IQ to success:

In 1921, Terman decided to make the study the gifted his life work. Armed with a large grant from the Commonwealth Foundation, he put together a team of fieldworkers and sent them out into California’s elementary schools. Teachers were asked to nominate the brightest students in their class. Those children were given an intelligence test. The students who scored in the top 10 percent were given a second IQ test, and those who scored above 130 on that test were given a third IQ test, and from that set of results Terman selected the best and the brightest. By the time Terman had finished, he had sorted 250,000 elementary ad high school students and identified 1470 children whose IQs averaged over 140 and ranged as high as 200. That group of younger geniuses came to be known as the “Termites” and they were the subjects of what would become one of the most psychological studies in history.  

Malcolm then goes on to describe where the Terman experiment of the gifted with high IQs went wrong: 

He (Terman) fell in love with the fact that his Termites were at the absolute pinnacle of the intellectual scale – at the ninety-ninth percentile of the ninety-ninth percentile – without realizing how little that seemingly extraordinary fact meant.

By the time the Termites reached adulthood, Terman’s error was plane to see. Some of his child geniuses had grown up to publish books and scholarly articles and thrive in business. Several ran for public office, and there were two superior court justices, one municipal court judge, two members of California state legislature, and one prominent state official. But few of his geniuses were nationally known figures. They tended to earn good incomes – but were not that good. The majority had careers that could only be considered ordinary, and a surprising number ended up with careers that even Terman considered failures.      

Malcolm refers to this excessive dependence on IQ or intelligence and mapping it directly to success as the ‘Terman Error’ and offers practical advice on how to judge individuals when you cannot be just relying in IQ as a measuring scale for an individual. He offers the ‘divergence test’ where candidates are asked to write down as many different uses of objects like ‘a brick’ or ‘a blanket’ as a better alternative. The divergence test requires not just the use of intelligence but imagination in as many ways and in as many directions as possible. He then analyzes results from one of the divergence test and uses it for his assessment of an individual named Poole:

It’s not hard to read Poole’s answers and get some sense of how his mind works. He’s funny. He’s a little subversive and libidinous. He has the flair for the dramatic. His mind leaps from imagery to sex to people jumping out of burning skyscrapers to very practical issues, such as how to get a duvet to stay on a bed. He gives us an impression that if we gave him another ten minutes he’d come up with another twenty uses.      

Malcolm then compares the results with another individual with a much higher IQ level and questions our fundamentals of selections based on IQ and Intelligence:

Florence’s IQ is higher than Poole’s. But that means little, since both students are above the threshold. What is more interesting is that Poole’s mind can leap from violent imagery to sex to people jumping out of buildings without missing a beat, and Florence’s mind can’t. Now which one of these two students do you think is better suited to do the kind of brilliant, imaginative work that wins Nobel Prizes?      

Malcolm seems to highlight the fact that a high IQ does not seem to equate to more success. If you are the kind of the guy who had a traditional outlook to intelligence and success you should get yourself a copy of Outliers. A very interesting read which challenges conventional wisdom with research and data rather ruthlessly.

So much for IQ; and while we’re at it let’s also challenge the to-recruit-the-best-hire-from-best-of-the-colleges thought process shall we?

Janet Rae-Dupree challenges the conventional wisdom that hiring the best of the students from best of the colleges always works out well in her The New York Times, Unboxed article:

“Society is obsessed with the idea of talent and genius and people who are ‘naturals’ with innate ability,” says Ms. Dweck, who is known for research that crosses the boundaries of personal, social and developmental psychology.

“People who believe in the power of talent tend not to fulfill their potential because they’re so concerned with looking smart and not making mistakes. But people who believe that talent can be developed are the ones who really push, stretch, confront their own mistakes and learn from them.”

In this case, nurture wins out over nature just about every time.

While some managers apply these principles every day, too many others instead believe that hiring the best and the brightest from top-flight schools guarantees corporate success.

The problem is that, having been identified as geniuses, the anointed become fearful of falling from grace. “It’s hard to move forward creatively and especially to foster teamwork if each person is trying to look like the biggest star in the constellation,” Ms. Dweck says. 

A couple of years after the college drive I was genuinely curious about what happened of the the bunch of these elite students who had been recruited after they had been labeled ‘the best of the best’ so I thought I’d call up the managers in the organization they were working in and find out. The results were interesting:

  1. Two of them had turned out to be good and productive.
  2. Three were pretty average and were decently productive.
  3. Three were mediocre and were struggling to keep alive.
  4. One of them was fired because of gross misbehavior and use of random abusive language in office.
  5. One of them wasn’t confirmed because of bad performance and decided to quit.

By the way, any guesses on how many other employees who had been picked without any IQ test had been fired by that hundred person organization that very year? Just one.

Net-Net, the recruitment results would have been similar had the recruitment team downloaded names with three years of experience from a job portal and started throwing darts at the names with a blind-fold.

So much for using IQ and Educational background as a measuring scale for success and the people you want on your team. If intelligence and IQ are your only measures of success, you might be leading your team into the classical ‘Terman Error’ and throwing random darts completely blindfolded while pretending that you are picking the ‘best-of-the-best’.

Remember, there are multiple kinds of intelligence and no single test, not even the divergence test, can measure for sure, who will work out for your team and who won’t. You have to get your best, and trust them to do it for you and then if they make mistakes, learn from those mistakes and get better the next time. As much as organizations crave for one simple answer in the art of recruitment, fact remains that there is none.

If you’ve been reading this far, dear reader, all I’ve done is attempted to sell the idea that neither college nor IQ scores can guarantee that you hiring the best. If you’re ready to buy the idea, it would mean that you now need to get your best guys and ask them define the best that joins your organization.

If you don’t buy the idea and feel that reaching out for the best of the colleges and hiring the guys with the highest IQ can solve all your problems associated with quality of recruitment, I offer you a big round dart board, lots of post-it notes, a sketch pen to write names with, a few darts and wish you good luck at hiring.

posted on Friday, December 5, 2008 9:07:20 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Monday, December 1, 2008 by Rajiv Popat

Detailed Planning And Comprehensive Project Plans Are Highly Overrated.

If you've been a regular reader of this blog you probably know my stance on Gantt Charts. I've often went out of my way and said that it's a team of competent programmers that builds applications and not your software development process and Gantt Charts. This post is not about reiterating any of those posts or my opinion on Gantt Charts. I am here; on the other hand; dear reader; to tell you that project plans and planning as we know it traditionally has already become utterly useless in the world of software development.

Don't knit your brows and frown on me just yet. Don't call me a just another happy-go-lucky Maverick out there dying to write code every time he sees a problem. Yes, I do understand the importance planning in software development and as important as you might consider planning to be; I am here, to tow with the idea that maybe; just maybe; planning in software development is not as important as most of us make it seem to be. I am also here to suggest, dear reader, that maybe there's something other than planning plays an important part in deciding the success or the failure of your next project.

Joel Spolsky in his article describes how he and Jeff Atwood started out with without any plan what-so-ever:

Then one day this guy named Jeff Atwood called me up. Like me, Jeff had a blog, on which he mulled various programming topics. He wrote well, so he was attracting quite a following. He had begun to put advertisements up here and there, and was making a little bit of pocket change, so he started thinking, Gosh, I can do this for a living. It sure beat the heck out of his day job working at a California company called Vertigo Software, which is where he was when he called me, asking for advice.

"Hey, I know exactly what you should do!" I said. And I told him the idea about the Q&A site with voting and editing. A site like this would need a lot of smart programmers to ask and answer questions. Between our two blogs, we felt we could generate the critical mass it would take to make the site work. Jeff liked the idea, so we decided to make it a joint venture.

We named it Stack Overflow, after a common type of bug that causes software to crash -- plus, the domain name happened to be available.

I had no idea if the site would work or exactly how it might make money, and I didn't have a ton of time to put into it. I have pretty deeply held ideas about how to develop software, but I mostly kept them to myself. That turned out to be a good thing, because as the organization took shape, nearly all these principles were abandoned. 

Joel admits Jeff and him committing six mistakes but ends the article with a positive note and a rather happy ending described in his own words:

I advocate a fairly simple method of creating software schedules. At the very least, I think, you have to make a list of all the things you plan to do and how long you think those tasks might take, and only then can you reasonably start work. Jeff kept telling me, "It's going to take six to eight weeks." I knew there was no chance that would happen, given that Jeff pulled his timeline completely out of thin air, but I humored him. In reality, it took about twice as long as that, which wasn't that bad, but it was still a 100 percent overrun.

In summary, Jeff and I made six major mistakes.

Oddly, though, none of it mattered.

In August, Jeff unveiled the site, and instantly it lit up. Programmers used the site to pose their technical questions, and more important, they got great answers. The voting system worked well - you could see that the answers to a given question were getting sorted with the best at the top of the rankings. 

What Joel and Jeff lacked in planning they made up with something that is much more important. That something is called coordination. They had started their conversations and pod-casts on the idea of even as they were taking their first steps to building it. The community was involved with not just selection of the name but designing the logo for the system as well. With a coordination level this high you hardly need a detailed project plan.

Clay Shirky, in his talk on Institutions vs. collaboration at TED describes how modern day collaborative systems like Flickr and Wikipedia are overcoming challenges institutional setups have faced for years as these institutions continue to rely heavily on planning while the modern day collaborative systems rely on coordination. Clay explains in his TED talk on Institution vs. collaboration:

What Flickr does is it replaces planning with co-ordination and this is a general aspect of these cooperative systems. You would have experienced this in your life whenever you bought your first mobile phone and you stopped making plans. You just said, "I'll call you when I get there."; "call me when you get off work"; that is a point-to-point replacement of co-ordination with planning.

We are now able to do that kind of thing with groups; to say instead of, "We must make an advance plan. We must have a five year projection of where the Wikipedia is going to be" you can just say - "let's coordinate the group effort and let's deal with it as we go because we're now well enough co-ordinate that we don't have to take on the problems of deciding in advance what to do. 

I've always compared software development to fighting a war and irrespective of how well your war plans are; in the midst of confusion and panic solid communication and co-ordination should be your primary tactic and is your only chance against continuous defeats; not an elaborately detailed project plan. Both your project plan and your dead-lines will change every single day; and that to be honest, doesn't matter.

If all of us in the world of software development understood the importance of communication and coordination it would be much more easier for us to realize just how much un-due and non-deserving importance we tend to given to project plans when clearly, they are nowhere close to being that important.

For your next project, try spending lesser time creating a detailed plan, fixing deadlines which run two years in the future and then panicking. Instead, try building a concrete relationship with your client and if they ask for the delivery dates two years from where you stand, talk about the first sprint, where you are trying to get to when the first sprint ends. Once you've told them all where you will be when your first sprints end, tell them; "I'll call you when I get there".

After all, when you “get there”, chances are, that the rest of your project plan might not even be relevant at all.  Software Projects change all the time and all we need here is some good old coordination; not a whole lot of planning. As far as software development is concerned planning is just one of those things that is highly overrated.

posted on Monday, December 1, 2008 3:59:29 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, November 28, 2008 by Rajiv Popat

Have You Thrown Away Your Gantt Charts Out Of Window Yet?

Gantt Charts are impressive artifacts conveying a huge deal of information intended to send out a perception of control to everyone involved with the project including the people who sign the pay-checks; sometimes technically refereed to as the 'stake-holders' . As a Project Manager, you typically make a Gantt Chart to flaunt this false illusion of control by documenting it in the form of a very technical-looking artifact.

After years of building Gantt charts, a few years ago, I came to one conclusion:  Like most project artifacts of the traditional days, Gantt carts are useless, built to impress and pamper false egos of Project Managers who build them and the stake-holders who ask for them. In most cases, an elaborate project plan in a Microsoft Project file is a symbolic representation of a non-technical-and-traditional project manager screaming at the top of his voice, in a desperate attempt to make a statement that even he contributes 'something' to the project.

Jeff Atwood compares the picture of the Gantt Chart above to the Traditional Waterfall Model. After all the above picture does seem to have striking similarities to something we all recognize.

Besides the fact that Gantt Charts look and act like the planning strategies deployed in traditional waterfall and other Big Design Up Front methodologies; Gantt Charts and Microsoft Project are considered useless by Agile practitioners around the world for multiple reasons:

Reason #1: Microsoft Project Plan And Gantt Charts end up sounding like a Know-All-Document

Ever worked with a Microsoft Project File? By It's very nature Microsoft Project expects that you would know every single task involved in the project, every single sub task in the task, the start date for the sub-tasks and the end dates of the sub-tasks. If you don't type them in, Microsoft Project inserts question-marks making the document look incomplete.

Reason #2: Microsoft Project Plan And Gantt Charts encourage Micro-Management

When you have every single task and sub-task, itemized with an end date attached to it, it's easy to sit in your management-ivory-tower, find out who isn't meeting his deadlines and act like a Prick in a desperate attempt to make the project move faster by speeding things up.

Reason #3: Microsoft Project Plan And Gantt Charts Encourage Status Reporting In Percentage Complete

The Percentage Complete field sits boldly on your project plan sheet tempting you to update the value on a regular basis. Everyone likes to report that they are ninety percent done where Agile clearly pushes for a mutually agreed definition of done.

Reason #4: Microsoft Project Plan And Gantt Charts glamorize the idea of dependencies and concurrencies

While kick-ass programmers are always scratching their heads on how to reduce dependencies Gantt charts clearly seem to suggest that everything can be classified as having a dependency on something else or being an activity which can be executed in parallel. Everyone knows the perils of multitasking. Besides, agile practices like Extreme Programming have always pushed the idea of developing and testing in isolation using mock objects followed by continuous integration rather than integrating in the end.

Reason #5: Microsoft Project Plan And Gantt Charts propose and push the idea of 'resources' and gives you a tool for Policing

When you have every single task broken down at a micro level and you have twenty individuals at your disposal, it's tempting to assign a task to an individual who is idle just because he is idle. Gantt charts, to some extent, tempt managers to see their teams as isolated resources which can replace each other The idea of not considering strengths and weaknesses of individuals is one of the biggest mistake you can make as a manager. It is the kick-ass programmers who get the projects successful; not the Gantt Charts.

Besides having an 'end date' associated with every single sub-task encourages the traditional project managers police their team.

Simply put, for managers who have nothing to contribute in a project, Gantt charts make them feel good about their existence by convincing themselves,  that they  are, in some way, contributing and adding 'some' value to the project.

Even as I type this, I can literally visualize a young and budding Project Manager, who has been recently told how awesome Gantt Charts are and how they are this amazing and cool time proven way to represent their project. I can visualize this young and budding project manager reading this post and going:

Hey Pops, are you telling me that Gantt charts are inherently evil and that Microsoft Project is a crappy piece of software that no project manager on this planet should be using? Are you trying to tell me that Microsoft Project and Gantt charts are evil tools developed to satisfy the ego of project managers and they cannot be put to any good use what-so-ever? 

No, not really. That's not what I'm saying here. To be fair to Microsoft Project and Gantt charts, they aren't essentially evil if you keep your project plans at a very high level and assign them to individual team leads.


Having said that, when you keep you Gantt charts at a level that is this high most Agile practitioners don't see the purpose of having the Gantt chart in the first place.

Just like the double-click-and-write-code model of Visual Basic 6.0 and even the current code behind model of ASP.NET,  Microsoft Project and Gantt charts provide you with an constant temptation of taking the wrong path and give out the I-know-all-signal to your clients instead of making them your allies and admitting up-front how little you actually know. Microsoft Project and Gantt charts in particular, gently nudge you to micro manage every single task item, introducing more problems then the ones they claim to fix.

The problem with Microsoft Project and Gantt chart, dear reader, is not that these tools are anti-agile; the real problem with Microsoft Project and Gantt charts is the approach and the thought process these tools seem to take aren't inherently the best approach and philosophies who want to run your agile projects on.

In his class post on 'The demise of the Gantt Chart in Agile Software Projects' the author David Christiansen believes that the approach and philosophy of the Gantt Chart can negatively impact Agility. David explains:

So, perhaps building software in a certain order isn’t really required, but surely it is more efficient to do it a particular way, right? I’m not one to favor the idea that there is always one best way, but it does seem intuitive that it would be more efficient for 5 different developers to be working in parallel on 5 different features if they were all building the features into a clear and complete application architecture. That way they could, for example, take advantage of existing persistence and security mechanisms instead of inventing those wheels themselves in their feature code.

Recognizing that, the good PM will develop a project plan that has the architect building the architecture first and then the developers showing up to build the features next. Of course the architect will need to know the requirements of all the features in order to build the architecture correctly, so the analysts will have to show up first to get the requirements right… Before you know it, you have a project plan with the standard set of phases all lined up into one gigantic critical path - which looks really cool on a Gantt chart.

Let’s go back to the roots of the scenario though. It assumes that the persistence and security mechanisms correctly support the needs of all 5 feature areas being developed. That, in turn, assumes that the requirements of those feature areas were captured accurately AND that they won’t change notably, which assumes that the users can articulate the requirements properly to begin with. Those are all assumptions that research (citations) has shown to be, well, problematic at best. 

Of course, some kick-ass developers and managers around the world might be capable of resisting the temptation and getting the Gantt charts to become Agile; for the rest of us mere mortals, survey results show that the trick is to throw your Gantt Charts out of the window and move to simple collaboration, high level planning, a kick-ass team that likes working with each other and iterating faster.

posted on Friday, November 28, 2008 3:58:28 PM UTC by Rajiv Popat  #    Comments [1]
Posted on: Tuesday, November 25, 2008 by Rajiv Popat

That's Not An Office. Software Shops Around The World Just Want You To Think It Is.

In my earlier posts, I criticized too many meetings and decided to call meetings 'the heroin-of-software-development-world. Even after announcing meetings as inherently evil I am a firm believer that software development is a team game and when given the choice between being the only solider or fighting with a team and allies I would opt for a small yet smart team that likes working with each other over working all alone any-day.

Having said that, as a developer, there is a limited amount of time each day when you communicate with the team and brainstorm. Then you need to get in the flow and get things done at least for a few hours a day.

For decent parts of their day software developers need to find a little corner, think and focus on complicated problems at hand without having people peek over their shoulders or indulge them in disturbances.


I've worked at numerous offices around the world and have written code ranging from tea estates in rural India to the fancy Microsoft Silicon Valley campus. While I'm not very picky about offices I set certain bare minimum standards on what offices should offer their employees, even if they are contractors there to work just for a few months, like I was when I was working at some of these clients. While quite a few of my client offices and the places where I have worked, passed the litmus test of an 'acceptable office environment' a huge number of organizations, clients and offices I've worked in fail the same test; miserably.

In my opinion of what an organization should offer to the employees, a quite and cozy cubical or office tops the list. In fact, quite working conditions are so important, that besides giving it a dedicated post, Jeff Atwood also includes it in the Programmers Bill Of Rights:

Every programmer shall have quiet working conditions: Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers' flow state, otherwise they'll waste most of their time bouncing back and forth between distractions. 

The discussion-thread on this topic at Joel's Discussion Group starts with a rather strong remark on the topic with certain opinionated individual makes very valid points on office environments:

Here is my description of a good workspace for software development: A quiet private office with a door and a clear window for each individual developer.  For team projects the offices should be arranged together with convenient common areas.

I happened to find the Fog Creek and JoS web sites a few years ago when doing a web search trying to find employers that provided good workspace.  As anyone who has worked in the field for long knows, the employers that provide good workspace are extremely rare.  The people who are in charge of facilities are usually concerned with costs, not usefulness. 

Employers that provide a good workspace are actually extremely rare. In one of the first organizations that I was contracted by my permanent organization at, five of us shared a long table with no partitions or private space. We would often use the meeting rooms and labs to spend more and more time alone; trying to focus and work without disturbances. A phenomena I see even today in most offices around the world.  Tom DeMarco and Timothy Lister in their book 'Peopleware: Productive Projects and Teams' describe this practice as 'Hiding Out':

When the office environment is frustrating enough, people look for a place to hide out.  They book the conference rooms or head for the library or wander off for coffee and  just don't come back. No, they are not meeting for secret romance or plotting political coups; they are hiding out to work. The good  news  here is that your people really do need to feel the accomplishment of work completed. They will go to great extremes to make that happen.  When the crunch is on, people will try to find workable space no matter where. 

The book does a rather good job at describing the environment that I've witnessed at countless organizations I've visited:

If you peek into a conference room, you may find three people working in  silence. If you wander to  the cafeteria mid-afternoon, you're  likely to  find  folks  seated, one to a table, with their work spread out before them. Some of your workers  can't be found at all. People are hiding out to get some work done. If this  rings  true to your organization,  it's an  indictment. Saving money on  space may be costing you a fortune. 

The cost implications of the whole open office environment is big enough for organizations to yield to the temptation of turning a blind eye towards employee productivity. The book  describes it with a real-life story:

California company that I consult for is very much concerned about being responsive to its people. Last year, the company's management conducted a survey in which all programmers (more than a thousand) were asked to list the best and the worst aspects of their jobs. The manager who ran the survey was very excited about the changes the company had undertaken. He told me that the number two problem was poor communication with upper management. Having learned that from the survey, the company set up quality circles, gripe sessions, and other communication programs. I listened politely as he described them in detail. When he was done, I asked what the number one problem was. "The environment," he replied. "People were upset about the noise." I asked what steps the company had taken to remedy that problem. "Oh, we couldn't do anything about that," he said. "That's outside our control."

It was as though the programmers had complained that there was too much gravity, and management had decided after due reflection that they couldn't really do much about it; it was a problem whose solution was beyond human capacity. This is a policy of total default.

Changing the environment is not beyond human capacity. 

What is even more ironic, is that during my career some of the best offices environments that I've been provided with have belonged to clients who had nothing to do with Software Development.

If I compare my overall experience in IT shops, other than selected few like Microsoft who a decently good work environment, most Non-IT clients that I've worked with seem to understand the need for a quite office environment much more than Software shops do. It is ironic, not very easy to understand but in my own personal case, very true.

I've jumped from a hard core software development client, who made me share office with a marketing guy chattering away on the phone to an oil and rig company that was generous enough to give me a plush office, a calm, silent environment and almost zero interference when I was working. It is almost as if clients having nothing to do with software seem to understand and acknowledge the fact that software developers need quite work environments and think-time. On the other client organizations that I have worked with and were in the business of software development just don't seem to get understand it or even consider it something worth giving any attention to.

If you happen to work in an organization where you have problems concentrating because of too much noise, I'm not going motivate you to try and change any of it. Walking up to your bosses and expecting them spend money so that you can focus better is too much to ask for from the business perspective. I'm going to try and give you three pragmatic solutions to this problem that 'you' can help yourself with:

  1. Find a quite corner - if you happen to work in a cross-cubical farm where four cubical's are slammed together in a cross, move to a cubical where you have a wall right behind you. A wall behind your back gives you some level of privacy and quietness.
  2. Work your way up the corporate ladder - work your ass off to get to the position of a manager while you continue to code; that way if only managers have offices, at-least you'll have one.
  3. Continue hiding out - if the first two sound impractical or at-least not easily achievable, continue 'hiding out' for work and look for nook-and-corners of your organization that are usually quite and yet to be discovered by anyone; at-least till you can get either points one or two implemented successfully. Alternately, you can also get an expensive head-phone with noise reduction and try to get used to coding with music on

The next time you are out there interviewing for a client gig of a permanent job, make sure you take a walk around the office premises before you accept that offer. Unless you're interviewing for a Non-IT shop, or interviewing for a managerial position, expecting an office for yourself or expecting a quite and cozy work environment might be too much to ask for; but taking a walk around your new workplace before you join in, at-least helps you find out if you'll have to look for a cubical with a wall behind your back or a hide out on the first day at work.

If you can get to do either at-least you would have carried your expensive noise reduction head phone to office on your very first day.

Loud and noisy cubical farms with crossed cubical having low walls or a wide open conference room are cheap substitutions for offices. They are not offices; even though a huge number of organizations in the business of software development desperately want software developers to believe otherwise.

posted on Tuesday, November 25, 2008 9:26:56 AM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, November 20, 2008 by Rajiv Popat

The Secret Sauce Of Successful Software Development Teams - Do You Really Like Them? Or Are They Just Colleagues?

This blog has been about my search for answers which have profound meaning in my life. As I write and learn, the goal, dear reader, is to involve you in my search for these answers. One of the things that has confused me as far as software development and life in general is concerned is 'success'. I've seen teams of really programmers having the best of the academic background fail project after project when a simple catalyst and a small teams of humble hard workers manage to break the infinite loop of failure  as they cruise through projects; successfully.

In my career I've been a part of quite a few projects. I've observed others from the outside and analyzed them like a black box is analyzed after a plane crash. A huge number of them fail because of lack of a kick-ass team; however, the more I analyze these failures and the more I 'grow' as a person, I continue to learn that of these huge number of failed projects that I've witnessed quite a few of them had teams comprising of some really smart individuals, who were strangely and weirdly, acting like perfect clowns leading their projects into the path of failure.


When I sit back to reflect on some of these projects I realize that none of the posts about successful projects that I've written in this blog, till date, explain some of the failures I've witnessed. I've seen small teams with technically competent developers fall flat on their face and their project snowballed into a massive failure because of little things. All of them were fairly competent individually; but when they came together they started acting like perfect clowns.

What is it then, besides competence, that results in successful projects?

I'll give you a hint - it's not RUP or CMM. No, it's not even 'just competence'.

Jeff Atwood describes the secret sauce of successful teams and does a good job at describing the source of all problems in software development:

Let's say I was tasked with determining whether your software project will fail. With the responses to these three questions in hand, I can tell you with almost utter certainty whether your project will fail:

  1. How many lines of code will your team write?
  2. What kind of software are you building?
  3. Do you like your coworkers?

That last question isn't a joke. I'm not kidding. Do you like the company of your teammates on a personal level? Do you respect your teammates professionally? If you were starting at another company, would you invite your coworkers along? Do you have spirited team discussions or knock-down, drag-out, last man standing filibuster team arguments? Are there any people on your team you'd "vote off the island" if you could?

It may sound trivial to focus on the people you work with over more tangible things like, say, the actual work, or the particular technology you're using to do that work. But it isn't. The people you choose to work with are the most accurate predictor of job satisfaction I've ever found. And job satisfaction, based on my work experience to date, correlates perfectly with success. I have never seen a happy, healthy, gelled, socially functional software development team fail. It's a shame such teams are so rare.

Happy, healthy, gelled, socially functional teams where the team members not just like working with each other but actually like each other as human beings and hugely respect for each other, are rare indeed. In my entire career till date, I've been a part of two teams that truly and fully, one-hundred-percent, fall in this category. While working with both these teams successful projects seemed like a destination towards which we were mostly cruising towards; on auto-pilot.

While working with, and being a part of both these teams, I personally delivered three projects with genuine value added and hugely happy clients who became allies in our success. What I also did during my work with these teams is a lot of soul-searching on why we were being successful.

Was every single individual in these teams a kick-ass programmer and a one man army?

Not really.

In fact, quite a few of us, me included, were pretty average programmers.

We were faced with the same perils of war that most software development teams face and we committed our share of stupidities. However the fact that team members liked each other and the 'mutual-trust-and-respect' factor made it that much more easier for people to become thick-skinned about their weaknesses and let someone else complement those with his strengths.

If you're responsible for hiring people in your organization, always remember, asking yourself if you would love to work with an individual is just as important as rating the individual on the technologies they are expected to work on.

If you are leading a team that you inherited or hired without this knowledge, besides your team members being amazing professionals,  look around. Ask yourself some fundamental questions about the team and the team members in particular:

  1. Is there a silent, subtle competition happening internally within your team? Are members of your team are indirectly competing with each other? 
  2. Do members of your team make you uncomfortable in social gatherings outside of office?
  3. If an individual was to resign and quit, would you feel secretly happy and relieved about the resignation?

If you answered yes, to any of the above problem, chances are your projects will fail one after the other; if you're really lucky, you will fumble your way to successful failures; but none the less you'll find software development very complicated and hard.  If you answered with a confident no however, chances are that you and your team will auto-pilot their way to successful projects.

While Jeff questions - "If you were starting at another company, would you invite your coworkers along?" - I leave you dear reader with an even deeper and profound litmus test of the team that you are working with: If you were to start your own little dream venture that you really believed in or pet open source project, would you invite your team to join in? Would they accept your invitation?

Two way relationships involving respect, liking and mutual trust are the secret sauce of successful teams and successful careers around the world. There is not much you can do to ensure respect, liking and trust from the other side, but working on these qualities for yourself is as important as learning the next version of the programming language or the platform you work on. May I suggest, dear reader, you give conscious effort in this direction; even if you think you are the most liked person around.

Are you 'working with' a team? Do you consider them a part of your life vision and your extended team or just this current job? If your relationship resolves around just this gig, you probably don't have a well-gelled team. On the other hand if you can think of them as your extended team and a part of your life vision, you might be building projects that cruise on auto-pilot towards success when you work with such teams. Yes, competency is important; but the mutual-liking-and-respect factor is equally important. It's the secret sauce of the delicious success that amazing software development teams often achieve.

posted on Thursday, November 20, 2008 10:23:38 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Monday, November 17, 2008 by Rajiv Popat

Resume Driven Development, The Hammer And The Nail.

Flash-backing multiple years to my days at Multiplitaxion Inc, I am reminded of my work with a senior technical manager who we shall call Fred. This particular individual had been vested with the responsibility of running multiple projects and getting them implemented successfully. When I talked first talked to Fred, while touring him around the office, something didn't quite click. It wasn't a lay-your-finger-on-and-objectively-criticize-what-is-wrong kind of a feeling. It was more of a feeling that did not involve a lot conscious thinking; just a nagging gut whispering gently in my ear, telling me very softly but clearly that something was wrong somewhere. Then, the feeling grew stronger and stronger as we engaged in a casual discussion on software development and how both of us felt about it.

Under normal circumstances if this would have been an interview, the vibe he was sending, would have been enough for me to let him go but this wasn't an interview. Mr. Fred had been already recruited, he wasn't my selection and he wasn't even in my team. Fred was going to run over three parallel projects on mainframes something I knew absolutely nothing about; and because I knew nothing about his area of expertise, or what he would be working on, it didn't made sense to judge Mr. Fred based on just one discussion. Besides, Pops told me to shut my big mouth up and play a nice guy, so I did.

Weeks went by and we slowly started involving Fred with multiple other projects. Over a period of time, I started hearing names of cutting edge technologies in pre-beta stages in design sessions. I started reading names of random technologies in design documents of multiple projects Fred was handling. When I looked at the weekly status reports that were being uploaded to our centralized lotus notes based document repository, the sky looked blue, the grass green and the universe looked just fine.

Our projects were using state-of-art-cutting-edge technologies and frameworks. Mr. Fred was starting to take us to next heights enabling us for what was then refereed to as the e-commerce era. There was one little problem however; our submit buttons, didn't work all that well.

Have you ever had an incident where you are about to present an application to a client or a potential client;  and you get this chill run down your spine when you're about to hit that button because you're not sure what'll happen when you press the submit button which is 'technically supposed to' save things to a database? Those cold chills are exactly what I would experience when I was vested with the task of giving a demo to a client or a potential client of any project or product Mr. Fred had been involved with.

The strange part however was that Mr. Fred was working with decently good teams who weren't exactly known for programming by co-incidence at Multiplitaxion Inc. All of them, had been involved with and had attributed to multiple successful projects in the past. They seemed pretty excited about the new technology stack being used and were spending late nights in office trying to meet deadlines as they picked up and learnt new technologies. There were too many of those cutting edge, state-of-the-art tools and technologies being used in our projects.

It wasn't until six months later that I realized what Mr. Fred was doing has a name in software development world. It is in fact, lovingly called Resume-Driven-Development. Justice Gray does a pretty good job at explaining Resume Driven Development in his post on - New development methodologies for the 21st century - he explains Resume Driven Development as:

You want to have an exciting career full of exciting accomplishments and nothing is more exciting than introducing exciting new technologies into a project!  But what do you do when the new technology has no business justification or simply isn't the best solution for the problem as opposed to something less sexy?  That's the beauty of Resume-Driven: in this methodology, you don't care!  If you think XSLT is cool, how about using them to completely deliver HTML pages with static JavaScript inside?  Sure it's a maintenance nightmare but with XSLT on *your* resume, what does it matter?  You'll have left this project by the time it gets maintained anyway!  Building a static web page for a capella band?  Why not use Microsoft Biztalk?  With RDD your career is only limited by your imagination!

I can do a long post to describe how Mr. Fred applied Resume Driven Development to all his projects but I won't. Generally, here is how it would work:

  1. Mr. Fred would look at a collection of technologies out there and pick the coolest one out.
  2. Mr. Fred would then look at the technology, and decide it was a perfect tool in his toolset. He would in-fact consider it synonymous to a golden hammer.
  3. From that point, because Mr. Fred had a hammer, Baruch's Law would kick in, and to his eyes, every single problem looked like a nail.
  4. Without much ado, Mr. Fred would strike the hammer really hard irrespective of what the problem was; he would build himself what he called a 'proof of concept' to prove that he had picked the right technology for the problem.
  5. Mr. Fred would announce the Proof of concept as successful, hand his cool technology to the team asking them to continue as he moved on to find something else to add to his resume.

I have a few acquaintances do the usual hi-how-are-you courtesy calls to catch up with me. They are often curious about technologies I am working on and often indulge in comparing the technologies I am working on with the technologies they are working on.

As developers, it is human nature to flaunt hot and sexy names of technologies out there and tell the world you're working on Windows Workflow Foundation and Silverlight but before you take a technology and apply it to your project, ask yourself if you are doing justice to your project by honoring Occam's Razor or are you just working at increasing the page-size of your resume at the risk of having a failed project on your organization's resume.

No-one cares what technologies you use or what your code looks like. Your job as a developer is to get successful implementations done; your job isn't even writing code. After all, the whole wide world runs on PHP. Go ahead, grab that book on Windows Presentation Foundation and read it well; but before you strike with your hammer, do validate that what you are striking, is in fact, a nail. Resume driven development is tempting, but in the long run, neither is it very effective, nor does it scale up as a philosophy to base a life on.

posted on Monday, November 17, 2008 3:40:25 PM UTC by Rajiv Popat  #    Comments [4]
Posted on: Thursday, November 13, 2008 by Rajiv Popat

Two Golden Rules For Software Development - Don't Police, Don't Panic.

If you're into dice-driven board games chances are that you'll love MAD. If nothing else it's hilariously funny, confusing and completely insane all rolled into one. The objective of the game? You have to be the first one to lose all your MAD funny-money before someone else looses all of theirs. The funny feel of the game reflects right on it's cover which has funny pictures and a remark, "What, me worry?".


The board game comes with a printed document which is supposed to be your 'proof of purchase' with a warning inscribed very prominently:

If you and your opponents find a board space or a Card card to be confusing, we wouldn't be the least bit surprised. But don't fight about it! Take a vote and play according to the majority rule. To most people, a majority is anything over 50%. However, because you're sufficiently intelligent and persistent to have read this far, you're clearly not most people. Therefore, determine in your own mind what constitutes a majority, take a vote and decide according to the majority rule.

The game is insanely funny; it is by far the funniest board games I've played till date. In-spite of the warning you will invariable see yourself get into really funny arguments with other players over interpretations of what the cards and board spaces mean.

The game has nothing to do with software development, but overall, the game is a very apt representation of the confusion and chaos that happens in game of software development.

  1. The customer thinks he knows what he wants.
  2. You think the customer knows what he wants.
  3. You have meetings with customers in attempt to try and understand what he thinks he wants.
  4. You think you know what the customer wants.
  5. The customer thinks you know what he wants.
  6. Neither you nor the customer knows what is it that he really wants and how you'll get there.
  7. You convince the customer that you know exactly what he wants.

Then added opponents of software development start attacking from multiple directions and before you know it, something creepy and weird happens: Everyone Panics.

MAD, the board game begins with the same practical, pragmatic advice that Douglas Adams had picked for his famous book, The Hitchhiker's Guide to the Galaxy:


As far as software development is concerned panic contributes as much to the failure of the projects as much as any other factor.

Chad Myer Provides added insight into why every project usually goes into panic mode:

There is a point in every project - well, every project I've ever been a part of in one shape or another - where panic starts. I'm not quite sure what starts it every time, but the ones that I do know of have all been about money and 'burn rate' and I'm willing to bet that all of them (even the ones that were not made known to me) are about that. The point of Agile, in my opinion, is to allow visibility and more frequent opportunity for decision points for the stakeholder for just these types of moments.  The appropriate response, when this moment of panic is about to ensue is for everyone, especially the stakeholder, to put on their big boy pants and start making the hard decisions about what to cut.

The inappropriate response - oh there are many, but they boil down to this - is to start mistrusting the developers and start assuming they're lazy SOBs who have been cleverly avoiding work throughout the whole project.  Looking back, nearly every single time the panic season started, this was the demeanor the stakeholders took.  Instantly the project went sour, all pace was destroyed, morale tanked, some people went into psycho 100hr/wk work mode to prove the stakeholders wrong, others proved them right by giving up and not doing anything. Ultimately, the project died a rather undignified and flaming death. Failure resulted (or perhaps success didn't happen to the degree to which it needed to happen), the team burned out and most left while the stakeholder was stuck with a failure product and all their critical brain trust gone or demoralized.

Ever been a part of a project where the panic button is pressed because the team is failing and someone realizes that it's failing because of lack of policing mechanisms? If you've been a part of any such projects in your life you're probably related to what Chad is saying here. If you, dear reader, have been through this experience, you probably know the feeling and can smell this panic button being pressed based on incidents that start happening. Office timings are made stringent, holidays and leaves are canceled, emails lose their touch of basic niceness, dead-lines for every single task are asked, micro management begins and everything starts failing apart.

I've seen quite a few Agile projects fail when the panic situation becomes public knowledge. After all, transparency is the biggest blessing and curse of Agile or simply an open culture in general. It brings the chaos and panic right on your face, forcing the weak hearted to either abandon it or press the panic button and replace the fundamental premise of trust on which Agile Projects are built are managed with policing measures and mechanisms.

I've often seen individuals accuse agile as being an excuse for being sloppy, but agile, by far, requires a huge deal of talent and discipline within, the development team and entire organization. In fact it requires more talent and discipline than any other process I've seen in my life. Chad in his post explains:

This is it, there's no turning back. Everyone on the team - stakeholder and producer alike - must trust each other to make the hard decisions and cut what they must to make the plan happen. You must resist the urge to bear down, roll up your sleeves and do everything wrong as fast as you can and ruin everything you've strived for. It's during the hard, trying times that discipline pays its debt. Soldiers don't go to boot camp to learn how to salute during peace time, they go there to learn how to be disciplined when the bullets are whizzing past your ears.

All of Agile is about forcing you to take the correct and sometimes hard decisions sooner than later. It won't give you a cozy feel of the 'green status report' when things are not fine. Software development is much harder than losing all your money in MAD. Before you start the software development game, the least you can do is remember the rules from MAD:

If you and your opponents find a board space or a Card card to be confusing, we wouldn't be the least bit surprised. But don't fight about it! Take a vote and play according to the majority rule. To most people, a majority is anything over 50%. However, because you're sufficiently intelligent and persistent to have read this far, you're clearly not most people. Therefore, determine in your own mind what constitutes a majority, take a vote and decide according to the majority rule.

If you are a young and budding manager, developer or whatever-it-is-that-you-are, I leave you with one humble thought, that you can put on your not-to-do list. Take the hard decisions if you must, cut down on features if you must, motivate and train your team to work independently if you must; whatever you do; don't police and don't panic; because that is what spreads like wild fire and causes everything to fall apart.

posted on Thursday, November 13, 2008 11:13:44 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Monday, November 10, 2008 by Rajiv Popat

Deadlines Driven Development Is For Dummies.

During his early days as a mentor to some of the junior programmers at Multiplitaxion Inc; one of them, who we shall call Fred, had an issue with me and my management style. His issue was that I wasn't pushing him to meet deadlines.

Mr. Fred believed that my not pressuring him really hard, like most other traditional managers had pushed him in the past, was bad management on my part.

He patiently explained to me that, instead of me making him estimate the duration for his tasks and then letting him have enough time to complete them with a quality implementation, he would really appreciate it if I could estimate how long his tasks should take and then give him a dead-line so that he would start working harder as the deadline approached.

For most other thick-skinned programmers who were getting projects rolled out successfully at Multiplitaxion Inc, deadlines weren't working out all that well. They seemed to like the idea of estimating their own tasks and working in a pragmatic non-panic environment.

I had discovered, early on in my career that the mounting pressure to ship based on a given artificial deadline encourages developers to program by co-incidence. As a developer, I had learnt the lesson the hard way, and had told myself that I would not push teams I work with to program by coincidence just to meet a deadline; specially artificial ones.

As I grew in my professional and personal life I started realizing that not imposing any deadline on people and empowering them with trust, makes them much more productive. Then I met Mr. Fred who had issues with the whole no-deadlines-we-trust-you-to-get-things-done way to running projects. Here was a guy telling him me that he desperately needed deadlines and he needed to be pressured so that he would do his work as I stood there and looked at him, completely confused.

Deadline Driven Development or DDD as some call it lovingly, isn't new in the world of software development and this wasn't the first time I was seeing it in action. During my early days as an young and budding developer, I had seen deadline-driven-development in the world of project managers where it was rampantly popular.  Having said that however, this was the first time in my life when I was seeing a team member crave for it. This was indeed my first experience of seeing young and budding engineers infected with an otherwise managerial disease. 

Tom DeMarco and Timothy Lister describe a real life story, of how managers and senior executives, like keeping their teams under constant pressure of deadlines, in their book Peopleware: Productive Projects and Teams:

During the past year, I did some consulting for a project that was proceeding so smoothly that the project manager knew she would deliver the product on schedule. She was summoned in front of the management committee and asked for a progress report. She said she could guarantee that her product would be ready by the deadline of March 1, exactly on time according to the original estimate. The upper managers chewed over that piece of unexpected good news and then called her in again the next day. Since she was on time for March 1, they explained, the deadline had been moved up to January 15.

The story might seem extreme to a few of you dear reader, and even though moving the deadline ahead might seem a little dramatic for most management teams to do, consider this: how frequently has your management seen you ship comfortably on time and have thrown in a couple of extra features in the mix asking you to build the new features in the same timeframe. Maybe the deadline wasn't randomly moved ahead, but adding random features, just to keep the team on their toes, equates to the same thing.

Deadline driven development is an approach to software development where the management constantly and rampantly disrespects the iron triangle. At multiple organizations that I've seen or visited, I've personally heard of or participated in more than one project and utilization meetings where people being able to head home comfortably at 6:30 is cited as a bad example of resource utilization.

Most veterans understand and have mastered the art of balancing between aiming for perfection and shipping and these kick ass developers will ship as fast as they humanly can. At times they'll estimate stupidly, stumble like babies and miss deadlines. Then they'll get up, get better and ship successfully. Peopleware does a pretty good job at describing the paradox of success when it comes to deadlines:

How many times have you heard that some new technique is going to be used because it is the only chance to make the hard-and-fast deadline, and that if the deadline is missed, there will be hell to pay?  The  setup of the change has already made its  outcome more than a little  dubious. The  kid-like  willingness to throw ourselves into a potentially  embarrassing endeavor is defeated by the potential for ridicule. Paradoxically, change only has a chance of succeeding  if failure, at least a little bit of failure, is also okay.

Every time there is a business push to ship faster I see countless managers, just take the email, forward it to their teams and push them harder; under the optimistic belief that if the team really pushed harder they might be able to pull of a magic trick.

If you're a manager, your job is not just to build a gantt-chart and then run behind your team collecting the status in terms of percentage complete. Business is expected to rush software development teams into it's own death-bed through continuous increase in velocity but and some point you need to take the crap upon yourself, cushion your team from it and let them function un-interrupted without the pressure of continuous and mostly artificial dead-lines. If you need to sit through a thousand meetings to convince the business, please do; if you must get into heated argument with marketing guys and your bosses please do; but if you pass of a stupid artificial deadline to your team all you do is demonstrate the lack of your management skills.

If you're a budding manager and the next time they tell you that there'll be hell to pay if a deadline is missed, try to investigate a little more into exactly how the business gets impacted and what is the actual loss involved if you were to miss a deadline for a few days. Chances are, there'll be none and there is invariable a high possibility that the so-called magical deadline which appeared out of nowhere would be the brainchild of a prick trying to push the team a little harder by pushing random deadlines.

I've been a part of multiple projects and have worked with a huge numbers of developers. I have hardly ever seen programmers cheat their organizations and have a fun time watching movies and playing video games when they had a clear sense of what they were expected to do and what the organization expected out of them. Working under the assumptions that your employees are out there to rob you and then pushing constant deadlines at them so that they don't miss-utilize their office time is outright stupidity which does nothing other than encourage the infinite loop of failure within the organization and the software development world in general. 

Deadlines Driven Development is for a team of Dummies. For everyone else who is decently smart, there is communication, collaboration and successful implementations.

posted on Monday, November 10, 2008 6:06:32 PM UTC by Rajiv Popat  #    Comments [0]