What appears in your mind if someone asks for a module for application?

Question

Non-technical people tend to say the word module instead of feature. But I always get annoyed if someone tells me to write a module when what they really want is a feature.

In my opinion a module is more than just a feature. A module has no strong dependencies to the application. The application works without the need for any modules. This is why I get angry if someone wants me to write a module because it is not easy to write modular applications. It requires architecting. A feature can be a module or not to be.

So I always prefer to understand module as a feature if a non-programmer asks it of me. What do you understand if someone wants a module? What is module in programming terms?

Answer 1

What appears in my mind is the next question I need to ask to get to a useful requirement. Non-technical people don't use technical words properly. It's our responsibility as technical people not to correct them, but to understand them.

A module in programming terms is irrelevant. What you need to find out is what a module means to that person and then translate that into whatever words you need to represent the concept to you and others.

Answer 2

A module in programming terms is a concept closely related to separation of concerns, and yes in jargon speak it main mean something a little more complex than a feature. But that's not always true when getting requirements from non technical people. You may call them features, modules, components, libraries, plugins, issues, whatever you want but the plain truth is that the true complexity and size of what you are being asked to do cannot be defined only by how it's labeled.

There are features that require hundreds of modules and modules that implement just one small feature. It's a matter of terminology and you shouldn't really care so much about it. You shouldn't get angry and you should always be prepared to do some architecting.

Answer 3

Who cares?

It makes absolutely no difference what the user decides to call things. Correcting them can even have a negative effect, since it will give them one more thing to think about when trying to explain what they want. As someone gathering requirements, it is your job to determine what they mean, not what they say. It can be difficult and frustrating, but that's why you make the big bucks. Let the user talk with whatever vocabulary is most comfortable to them.

Answer 4

Well, why not ask them (if you have doubts about the terminology) what they mean exactly?

In my mind, a module (a modular approach ... this is btw, terminology coming from another technical field) is a functioning self sustained piece in every way but one - it needs other to function, to form a complete product, but apart from that is self-sustained. It is not dependent on other modules, and can be developed independently (and usually is) from others.

In other words, a modular approach in application development would be such where you develop parts of application that have minimum or no effect on each other, and can easily be thrown out should the need arise.

But that is (educated it may be, but still) speculation. You need to exactly talk with a client what he means when he says "module" - expecially, if he, as you say, does not know the terminology.

It is like they say ... six months in a lab can frequently save half an hour in a library.

Answer 5

Don't get your knickers in a twist over the differences between the user's vocabulary and yours. Figuring out what they mean from what they say is part of your job.

This usage of module by users probably stems from the way a lot of line of business software used to be sold. For example a vendor would sell a basic accounting package, and then offer customers an "inventory module", a "scheduling module", a "fixed asset depreciation module" etc, at extra cost. Think plugins for a web browser or an editor.