I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
I devoured both your O'Reilly books and the papers you co-authored and mentioned in the appendix of Building Maintainable Software. This is really fantastic work, Joost. My team and I have been struggling with the questions at the heart of your work.
Your suggestions about how to achieve better maintainability make intuitive sense. But I'm a little fuzzy on your evidence.
In Building Maintainable Software Chapter 1, page 8 of the Java version you wrote:
The star ratings serve as a predictor for actual system maintainability. SIG has collected empirical evidence that issue resolution and enhancements are twice as fast in systems with 4 stars than in systems with 2 stars.
What's the empirical evidence? Are you talking about your paper "Faster issue resolution with higher technical quality of software" or something else? Do you have additional evidence you could share? One data point isn't much to go on. I don't want to blindly follow anybody's advice and the paper is--no disrespect--a little shaky because of the quality of the source data.
I think you'd agree that refactoring an existing 2 star 50 KLOC project into 4 star project would be a significant undertaking. So how do you convince clients that following your recommendations is the right thing to do?
Let's look at the short units of code recommendation. In Code Complete Steve McConnell cites several research studies and comes to the conclusion that:
The evidence in favor of short routines, however, is very thin, and the evidence in favor of longer routines is compelling.
How do you know I'm not better off limiting my units of code to 100, 150, or 200 lines like he suggests? Why is 15 the right limit?
I could ask the same things for the other measures. Why not have a McCabe complexity cutoff at 6 or 7 or 10?
I guess my questions boil down to: how do you know your suggestions are anywhere near the economic optimum for a non-trivial software project? No doubt, following all your suggestions will improve the maintainability of my project but getting there will be expensive. I'm not saying you're wrong, I just don't know how you know your suggestions are economically sound from reading your books and papers. What have I missed?
Cheers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I devoured both your O'Reilly books and the papers you co-authored and mentioned in the appendix of Building Maintainable Software. This is really fantastic work, Joost. My team and I have been struggling with the questions at the heart of your work.
Your suggestions about how to achieve better maintainability make intuitive sense. But I'm a little fuzzy on your evidence.
In Building Maintainable Software Chapter 1, page 8 of the Java version you wrote:
What's the empirical evidence? Are you talking about your paper "Faster issue resolution with higher technical quality of software" or something else? Do you have additional evidence you could share? One data point isn't much to go on. I don't want to blindly follow anybody's advice and the paper is--no disrespect--a little shaky because of the quality of the source data.
I think you'd agree that refactoring an existing 2 star 50 KLOC project into 4 star project would be a significant undertaking. So how do you convince clients that following your recommendations is the right thing to do?
Let's look at the short units of code recommendation. In Code Complete Steve McConnell cites several research studies and comes to the conclusion that:
How do you know I'm not better off limiting my units of code to 100, 150, or 200 lines like he suggests? Why is 15 the right limit?
I could ask the same things for the other measures. Why not have a McCabe complexity cutoff at 6 or 7 or 10?
I guess my questions boil down to: how do you know your suggestions are anywhere near the economic optimum for a non-trivial software project? No doubt, following all your suggestions will improve the maintainability of my project but getting there will be expensive. I'm not saying you're wrong, I just don't know how you know your suggestions are economically sound from reading your books and papers. What have I missed?
Cheers.