Software Development as an Emergent System
blinkingcaret.com
Software Development as an Emergent System
1–10 of 27 posts
Re: Software Development as an Emergent System
#2Cool and all, but having a way to measure the gnarliest parts of the code is not, in my experience, the problem. Having a management objective that is willing to devote any non-zero amount of time to paying down technical debt is more often the problem. Technical debt costs over time, and new features pay off much quicker. The management may not even intend to be around in the long term (if they're developing for a client or intend to sell to a larger company, for example).
Of course, having a measurement might help shine a spotlight on how things are getting worse, but I've never actually seen this happen. Perhaps others have a different experience?
Re: Software Development as an Emergent System
#3Cool and all, but having a way to measure the gnarliest parts of the code is not, in my experience, the problem. Having a management objective that is willing to devote any non-zero amount of time to paying down technical debt is more often the problem. Technical debt costs over time, and new features pay off much quicker. The management may not even intend to be around in the long term (if they're developing for a c…
I think it's a matter of attitude. Either you accept that there is value in keeping a code base reasonable or not. Maybe some metrics can help to make a point but any metric will be abused over time if used too religiously.
You are making a good point about people not being around long term. In my company there are departments with high turnover and they tend to go for quick victories that are often costly in the long term. At the time this becomes clear the manager who made the previous has already been promoted somewhere else and the next guy will make another quick decision to fix the previous problem. Then this guy gets promoted too and the cycle continues.
Technical debt is really only a problem if you think long term.
Re: Software Development as an Emergent System
#4Cool and all, but having a way to measure the gnarliest parts of the code is not, in my experience, the problem. Having a management objective that is willing to devote any non-zero amount of time to paying down technical debt is more often the problem. Technical debt costs over time, and new features pay off much quicker. The management may not even intend to be around in the long term (if they're developing for a c…
I think it's a matter of attitude. Either you accept that there is value in keeping a code base reasonable or not. Maybe some metrics can help to make a point but any metric will be abused over time if used too religiously. You are making a good point about people not being around long term. In my company there are departments with high turnover and they tend to go for quick victories that are often costly in the lon…
'just get a dot on the map' makes shit products. the locusts move elsewhere after the damage is done.
this is the state of tech.
Re: Software Development as an Emergent System
#5Cool and all, but having a way to measure the gnarliest parts of the code is not, in my experience, the problem. Having a management objective that is willing to devote any non-zero amount of time to paying down technical debt is more often the problem. Technical debt costs over time, and new features pay off much quicker. The management may not even intend to be around in the long term (if they're developing for a c…
I think it's a matter of attitude. Either you accept that there is value in keeping a code base reasonable or not. Maybe some metrics can help to make a point but any metric will be abused over time if used too religiously. You are making a good point about people not being around long term. In my company there are departments with high turnover and they tend to go for quick victories that are often costly in the lon…
Indeed, sort of like how not ever bathing is only a problem if you think long term.
Re: Software Development as an Emergent System
#6Cool and all, but having a way to measure the gnarliest parts of the code is not, in my experience, the problem. Having a management objective that is willing to devote any non-zero amount of time to paying down technical debt is more often the problem. Technical debt costs over time, and new features pay off much quicker. The management may not even intend to be around in the long term (if they're developing for a c…
I'm working on a couple code bases that are 10+ years old in a mature organization, but for internal customers only. In those cases there's definitely awareness that paying down technical debt is worthwhile since everyone can remember times where the debt ballooned and it was painful.
Other projects not so much, especially in this day and age where rapid delivery and throwaway is actually an accepted form of SW development.
The fact that Agile and its ilk sprung up and mostly failed to address these issues shows how hard a problem this is.
Re: Software Development as an Emergent System
#7Earlier quoted context omitted.
I think it's a matter of attitude. Either you accept that there is value in keeping a code base reasonable or not. Maybe some metrics can help to make a point but any metric will be abused over time if used too religiously. You are making a good point about people not being around long term. In my company there are departments with high turnover and they tend to go for quick victories that are often costly in the lon…
Indeed, sort of like how not ever bathing is only a problem if you think long term.
To paraphrase Quentin Crisp, after the first few years the smell doesn't get any worse.
Re: Software Development as an Emergent System
#8Re: Software Development as an Emergent System
#9Cool and all, but having a way to measure the gnarliest parts of the code is not, in my experience, the problem. Having a management objective that is willing to devote any non-zero amount of time to paying down technical debt is more often the problem. Technical debt costs over time, and new features pay off much quicker. The management may not even intend to be around in the long term (if they're developing for a c…
I think it's a matter of attitude. Either you accept that there is value in keeping a code base reasonable or not. Maybe some metrics can help to make a point but any metric will be abused over time if used too religiously. You are making a good point about people not being around long term. In my company there are departments with high turnover and they tend to go for quick victories that are often costly in the lon…
A good analogy for older management, which is disappearing as an extant object in the office, is that of the file room. Sometimes, you'll see a seeming "whiz kid" file clerk who seems to be far faster than normal, but it turns out that he's "faster" because he doesn't actually re-file and reorganize.
Refactoring is quite literally the same thing as re-filing and reorganizing physical files. Under the academic definition of refactoring, the "contents" (the functionality) is not changing. Only the organization is changing.
Re: Software Development as an Emergent System
#10I write down every issue - everything from user interface issues to bugs, and then delete them as they get fixed. I can then use that file to measure code debt. The file is saved in version control, so no fancy stuff, but I can run statistics and compare code growth and growth of issues.
In my experience you want to keep this file small. On a current project I've estimated that it will take five years to clear this file grin>. This file seem to grow exponentially with new features. And I think at some point there's a point of no return - where you can't possible fix all issues ...