undefined | Better HN

0 pointsmarcosdumay10y ago0 comments

Your metrics don't touch software plasticity (capacity to receive changes) at all, yet it is one of the most important components of software quality.

0 comments

2 comments · 1 top-level

jrs23510y ago· 1 in thread

Correct. The ones I randomly picked don't cover plasticity. How does one measure (and convey) software plasticity to other [non-technical] shareholders?

Tech: "It's going to take x amount of time to refactor so that the software can easily change in the future" BusDev: "What if we don't need it to change [like that] in the future?"

How does Tech and BusDev objectively measure the software plasticity if it can't be measured until change must occur? "Our software is X plastic" means what? "This change will take 1 day instead of a 1 week because we made our software plastic." What if you pre-optimzied plasticity and YAGNI'ed wasting precious time and resources. This is where things get real dicey... trying to objectively measure the importance and value of clean code. WE, techs, understand it and can feel it while trying to implement new features and changes but those that don't touch or understand code can't.

ADD: How do we determine the code is clean (and refactored) enough (but not too much)? "Everything should be made as simple as possible, but not simpler." "Do as much is needed but nothing more"?

marcosdumayOP10y ago

I have no idea how to convey plasticity to shareholders. I think it's the hardest quality to measure, and that's why I pointed it.

The GP and, for a lesser extent (but it's cumulative) you are talking about easy to measure, and yes, important metrics. But those are not the only ones. There are also hard to measure components of quality that do make it more subjective.

j / k navigate · click thread line to collapse