Fear Of Modeling

Does the idea that there is a general fear of modeling software sound like a real problem? Or, is it simply a matter of practicality? In most circumstances, modeling software, either during implementation or before, isn't beneficial to the project. Practicality aside, there are many large software projects in existence today haven't had requirement of any formal modeling in order to succeed. This doesn't mean that these development teams responsible for these projects have a fear of modeling. It means that they were able to approach the problem at hand tackle in a timely, and predictable manor.

So what does cause a fear of modeling? There are far too many reasons that organizations as well as individual developers don't model the software they are building to give here. There are, however, some very generic reasons that most software goes without a model. The chief reason being a generalized fear of modeling. Not just the act of modeling itself, which is often a very enjoyable experience. This fear of modeling arises due to a number of inter-connected factors.

The technology exists today to model just about anything, including software. Impossibility has nothing to with the problem. Further, there are many professional developers who have at least a fundamental grasp of modeling standards. These models, using standardized notation or not, can be illustrated using old, legacy technology, pen and paper. Shocking.

If the project is slightly more important than something you might contribute to on the side, such as an open source project, it is probably a better idea to construct any software models with software. It is easier to communicate with others using these models. Particularly, it is very helpful to provide a repository that stores all models for a given project. Nothing is lost, neither good nor bad. We can still learn from bad models.

Getting back to the fear that is involved whenever modeling software in various development cultures. Is the fear of modeling restricted to those team members intricately entwined with the code? Absolutely not. Any activities that are executed by a team affect every team member. In other words, modeling software that is about to be implemented requires both time and effort. And and here is the mythical part, the produced models aren't usable by paying customers and aren't worth doing. In some cases, the argument that software models aren't worth doing do to timing and resource constraints holds some merit. Consider an getting a patch out to an already deployed system. In this scenario, getting the design right is hardly more important than keeping the customer.

Is it possible to convince managers that modeling the software you, as a team are building has value? Of course it is. What really helps here is being able to produce high-level, non-technical, big-picture models of the system in question. If managers feel that they can better understand what is being built, they can better relate to why other modeling activities help developers better understand the system. And that means your boss is more likely to view software models as a valid product artifact.

Developers are obviously the main beneficiary of software models. The purpose of a software model is to better understand a software system. That is it. There are endless ways in which a developer can better understand a system but when they do, it results in a better product. Developer's fear of modeling often stems from an emphasis on producing a large, complete, and correct model before implementation has begun. It is true that you should start modeling before you start coding but don't get carried away. You'll often get a sense of when it is time to test out an idea, in code, while modeling. Don't resist the urge to code while modeling and don't abandon the model once coding has started.

What should software development teams be using to model software with? The UML offers a coherent set of standardized software modeling constructs. The UML in and of itself can be a source for fear of software modeling. A common misconception of the UML is that the entire set of modeling elements should be used for any given project. This couldn't be further from the truth. Use only what you need. The other elements are there if, and only if, you need them. I would recommend that each development team member have a basic understanding of commonly used UML elements. Everyone can jot down ideas, pass them around, using a standardized notation. More advanced users can then merge ideas into more formal models if, and only if, they are needed.

Modeling is not importing a set of classes that have already been written as specific programming language instructions into some modeling software in order to produce a class diagram. While this can provide some useful insight into older systems that have already been implemented, doing this with newer systems misses the mechanical act of constructing a conceptual illustration. Modeling can have some hidden, subtle benefits.

Software modeling can be be hugely beneficial more many reasons. Although there is the illusion of lost productivity due to building models, these fears can be put to rest by putting software models to work. They aren't going to jump up and prove their own worth.