Language matters, just as saying the wrong word to the wrong person can leave you with one less front tooth, so too can the incorrect use of language in general create a cascade of confusion that pervades an entire industry.
One of my pet peeves about the use of language in the software arena is the use of the word "Project". This usage as far as I know goes back to IDEs grouping software artifacts as projects. The notion of a project as the top level organizing construct for software projects (see what I did there?) is now a de facto standard. One problem with this is that it is a complete misuse of the notion of a project. A project is not a thing, it is a process! A project has (or at least should have) a well defined start and end.
As a process, by its very nature, its essence is vague. So when something whose essence is precise (software) is called a project it leaves the reader wondering exactly what is being described. Whenever I come across a documentation describing a piece of technology and then goes on to describe some top-level construct of its configuration as a "Project", I am left wondering exactly what this entails. In other words giving the top level construct its proper name would allow a reader to know immediately what is being described, calling it a project means I need to unwrap its meaning somewhere else.
For instance in designing Hivemind I deliberately stayed away from creating any top level construct that could be considered a "Project". Instead there is an application (a thing), then there is a Task/Project management feature which can be used to actually manage a project. In this way the application is just a component of some project (it could belong to more than one project), the application (or applications) are mere artifacts of the project, they are not the project itself. Now you may well need to organize a group of artifacts into some higher order category or construct, but this still won't be a project :)
The words you use for things (especially complicated things like software) often becomes an anchor for how you think about those things, so while it may seem harmless to mislabel things, there can be real negative impact over time. At the very least the rampant misuse of the term project within software leads to what I call "low grade" confusion.
#TGIF
One of my pet peeves about the use of language in the software arena is the use of the word "Project". This usage as far as I know goes back to IDEs grouping software artifacts as projects. The notion of a project as the top level organizing construct for software projects (see what I did there?) is now a de facto standard. One problem with this is that it is a complete misuse of the notion of a project. A project is not a thing, it is a process! A project has (or at least should have) a well defined start and end.
As a process, by its very nature, its essence is vague. So when something whose essence is precise (software) is called a project it leaves the reader wondering exactly what is being described. Whenever I come across a documentation describing a piece of technology and then goes on to describe some top-level construct of its configuration as a "Project", I am left wondering exactly what this entails. In other words giving the top level construct its proper name would allow a reader to know immediately what is being described, calling it a project means I need to unwrap its meaning somewhere else.
For instance in designing Hivemind I deliberately stayed away from creating any top level construct that could be considered a "Project". Instead there is an application (a thing), then there is a Task/Project management feature which can be used to actually manage a project. In this way the application is just a component of some project (it could belong to more than one project), the application (or applications) are mere artifacts of the project, they are not the project itself. Now you may well need to organize a group of artifacts into some higher order category or construct, but this still won't be a project :)
The words you use for things (especially complicated things like software) often becomes an anchor for how you think about those things, so while it may seem harmless to mislabel things, there can be real negative impact over time. At the very least the rampant misuse of the term project within software leads to what I call "low grade" confusion.
#TGIF
Comments
Post a Comment