Implicit Dependencies Are also Dependencies
A fairy tale. The not-so-fictituous project was developed in two countries. It was a large product, sufficiently large to justify multiple processors / computers / servers should do different portions of the job. For reasons of convenience, the project was split along the computer boudaries. Each development site became responsible for the software running on one computer. It had to fulfill their share of requirements, and to do their share of testing. As an interface between the computers, the communication protocol was specified according to the desired functionality. A few months later, each site declared victory: the software was finished. The integration team took over and plugged the components, errrh, computer together. They started working. A bit. Not much though: as soon as the most common scenarios were left and the more interesting scenarios were tested, the interaction between the computers became unreliable. Confronted with this finding, both teams held up the interface specification and claimed their software would conform to it. Actually, this was found to be true. Both sides declared victory, again. No code was changed, and they developed happily ever after.
Who cares for dependency management?
Ten years ago, few people in industry projects did. Since then it became a commodity, a commonplace that is familiar even to product owners. Yes, software components have dependencies, particularly in large projects, particularly when you strive to increase your code reuse.
So now you have your dependencies - but you do not like them.
Dependencies make it hard to change code. Whenever you would like to change some code that others depend upon, you will experience lots of work, and possibly strong forces of inertia when other developers would have to invest their time. This force grows very strong when you happen to dwell in environments with a long development micro cycle, like in C++ projects or in embedded systems.
Good development practices increases your dependencies, right?
One of the paradigms of extreme programming [Beck99] is to do things once, and only once. This is nowadays rephrased as "don't repeat yourself" (DRY) [ref]. If you do not repeat yourself, you code or define things only at one place in the code, and all users depend on that one location.
So maybe you should avoid referring to that code?
So maybe you should avoid referring to code, and rather find some way around such a dependency?
So maybe you want to obscure your existing dependency by using different tools and locations for all your information?
(from other article, needs to be fed into this)
Do not make your code depend on some file that is intended to change as the project progresses.
It is very convenient to have a global file that lists all error codes in the system. When starting the new component, you proudly add a handful: look, I am a part of this! Only to find your colleagues moan about the extra build time. How dare you change this file?
Couldn't you just do what everybody does:
- reuse some error codes that are already in there.
- when existing codes don't match the intended meaning, document their specific meaning in your component documentation.
error.h file was intended to provide a great place to look for the meaning of codes. At the same time, it is a central component that is intended to change as the project proceeds. So it is your base, but it is quicksand.
How to get out? Consider this:
- real generic error messages (in the style of STL exceptions)
- a distinct
error.hfile per component