> Whether bad code is a cost depends on its situation and > status regarding evolvability: a simple metric might be: > how likely the code is to be modified, and what kind of > modifications will be done. If code is never touched > again, or is deleted and replaced wholesale, no cost is > incurred. The rest of the range is probabalistic.
You are ignoring that much of the cost of messy code is in the reading. If a shop does code reviews, the cost of messy code is always greater than zero. There may also be perfectly functional messy code than never needs to be changed but incurs great cost of because the time it takes for people to understand what it is doing in both support and development roles. Often messy code is never changed not because it works properly but because feels they understand what it's doing enough to change it or the cost of changing it is too high.
Messy or sloppy code is one of the worst burdens for a development shop to bear. Combine that with poorly defined requirements and it's devastating. This is something that I've found that many career contractors do not understand. They write some code and leave and never see the impact of their sloppiness.
The same model can cover that just as well. The point is to find a clarified, objective way to understand and so handle the matter -- or verify whether it is worth worrying about at all.
I am not aware there is quite such a model, so it seems there is a potential worth considering.
> > the cost of messy code is in the reading > > The same model can cover that just as well. The point is > to find a clarified, objective way to understand and so > handle the matter -- or verify whether it is worth > worrying about at all. > > I am not aware there is quite such a model, so it seems > there is a potential worth considering.
I'd love to have an objective way to measure code quality. But I think we also have to be ready to accept that there may be no way to do that for the foreseeable future. The inability to measure something objectively doesn't mean it doesn't exist or isn't important.
> A more sophisticated model is needed to evaluate these > questions in any useful way. > > Whether bad code is a cost depends on its situation and > status regarding evolvability: a simple metric might be: > how likely the code is to be modified, and what kind of > modifications will be done. If code is never touched > again, or is deleted and replaced wholesale, no cost is > incurred. The rest of the range is probabalistic.
Wrong. Bad code that creates an Abstraction Inversion will create inherent pressure on any interfaces that are built on top of that "code never touched again".
Flat View: This topic has 18 replies
on 2 pages
[
«
|
12
]
Previous Topic
