Is there a place in software development for Niters?

Question

For those who don't know, Niters are people Not Interested in Technology.

If when working on software projects someone brings up the subject of XML or database design or C# delegates, the Niter looks the speaker straight in the eye and says "I'm not interested."

So my question is: Do Niters belong in software development teams?

1. No, because you can't talk to them.
2. Yes, they can explain to the IT gurus what is required and the computer men write the software.
3. Yes, projects can be structured so that Niters work with tools which directly affect the software delivered to the end user.

Answer 1

I believe they should be available and a part of the design phase, but definately not part of the team itself. While 'they' are very valuable, they also tend to quash the creative thought proces :p

Answer 2

If the person can make a positive contribution to the team, then I see no reason they shouldn't be involved. I think there involvement should probably be limited to requirements gathering in most cases, but there is defiantly a place for them.

Answer 3

No, I don't believe they should be part of the development team.

They could/should be used for usability testing, though they should not have any direct relation to the development team in order to provide as much of an unbiased report as possible.

Answer 4

No they should not be part of the team.

"Not being interested" is a cardinal sin in our world. But you do want people that will continually parrot not relevant, not relevant to some of the wacky ideas out there.

Jeff has tried to make this point on Coding Horror before (judging by the comments he lost). For instance :- XML as mentioned in the question is great, but doesn't solve all problems.

The relevancy parrots can help the team make decisions that match their ability and the project needs... and yup, some of those decisions would upset both the parrots and the Niters (heck, the Niters might need to actually learn something)

Answer 5

Thank you for your answers, I won't mark any as correct because it was a question fishing for opinions and there is no right answer.

There seem to be a range of responses from "Niters don't belong in software development" to "Niters can participate by asking for features and afterwards checking to see whether they got them".

No-one seemed interested in allowing Niters to actively participate in actually building the product.

It may come as a surprise to some that there are well known software identities spending lots of money building tools to allow the active participation of Niters. Seems to me like they should have checked with you guys first.

Answer 6

No-one seemed interested in allowing Niters to actively participate in actually building the product.

Having worked with such people and seen what they produced, I'm not surprised.

People who do not take an interest in the tools of their trade and do not reflect on the quality of their work (so that they might learn techniques to improve it) do not develop good software.

Answer 7

I have dealt with nitters being on my team before. They are ok, at usability and testing, but if they don't have any passion for doing their job better by way of innovation, then they are a net negative to morale.

In my experience, nitters are derived from demoralized analysts whose job is to just interview people all day. They used to love the coding and fun of all this stuff, but as their job got more and more boring, they got less and less interested. This type of nitter is a black hole for productivity, since they usually spend a large part of Monday rehashing the nfl score board.

It comes down to passion, if you have passion for at least the business process the team is working on, great, if not, get out of the way, our ship can't benefit from even one mutineer.

Answer 8

I'm going to vote "No" with a suggested alternative instead.

I base this "no" particularly on the recollection of a team-building exercise where I was the only tech in my group trying to solve a problem about some hypothetical beetle doing something only hypothetical beetles do (like walking exactly 6cm right) and constantly having to argue with quite serious sales people that the colour of the beetle did not matter.

Non-technical people can derail any technical project with their own flawed analysis, but more often and more damagingly by failing to convey something critical because they were not able to recognise it as such.

In my perfect world you have a class of professional whose job it is to interface between technical and non-technical, who has the training to draw out what the Niter doesn't know they know and interpret and assuage their preferences for beetle colouring. A lot of the time these people are called Project Managers, and imho a good one who can do what I've described is priceless.

Answer 9

Yes, if the person is a customer (or an effective surrogate customer). Having a customer onsite is a requirement in XP, and maybe there are something you can use from it even if you don't follow XP.

At the end of the day, software solutions exist to solve business problems. Thus, from the customer's perspective, technology really is irrelevant as long as the problems are solved effectively.

If the person is generally not interested in the problem or the solution itself, he or she needs to be removed quickly from the project before everyone turns into a viral zombie.