Everything on this list seems reasonable, but I see teams doing many of these things and still having problems. You can say “on they aren’t doing it right”, which is probably true. For myself, I think the biggest tool I have for writing high quality software that I don’t see other people use is that I have like 5 or 6 things, and I just use those in different combinations. I really really really hate adding a new technique to my repertoire. I separate stuff with processes a lot. I use state machines + simple interpreters like crazy. I care a lot about pinning dependencies. I also spend a lot of time describing the semantics of my APIs (and I’m in a position where I can demand that of my team). And I do a few other things. I don’t really care that much about testing, I do it generally but it’s not a big priority for me. I don’t know what my secret sauce is but I consistently see my teams ship things with fewer bugs and less severe bugs. Not all, but many of the bugs we hit take about 5 minutes to diagnose and maybe an hour or two more to get deployed through to production (assuming it’s high enough priority to execute on now).
Everything on this list seems reasonable, but I see teams doing many of these things and still having problems. You can say “on they aren’t doing it right”, which is probably true.
Gosh, no. That’s not a thing I’m ever likely to say, and if I do I hope someone calls me on it. I hate it when people use that as an explanation.
It’s not intended as either a necessary or sufficient list of things to do to write good software. It’s literally what it says on the tin: A list of things that might help.
You can certainly ship great software without most of the things on this list, and very few of them are things I’d consider mandatory (only two really). I wouldn’t be very surprised by someone doing all these things and still shipping bad software, though I’d be really interested to talk to the team and see if I could figure out why. Instead they’re things where I feel like if you’re not doing them, adding them is likely to be an improvement.
All of the things you list sound sensible (except not caring about testing ;-) ).
very few of them are things I’d consider mandatory (only two really)
I wonder what your two are? I’d go with attitude and manual testing. If you have infinite money and patience, you can just go slow and manually wall-bang the hell out of everything you try to ship; all of the other factors merely reduce the cost of shipping not-garbage down to realistic numbers rather “the yearly GDP of an entire neighbourhood per LoC”.
I wonder what your two are? I’d go with attitude and manual testing.
Hmm. Maybe more than two then. :-)
I was going with “have CI” and “use version control”. Manual testing is probably a third though (and I guess “regression testing” is pretty close to mandatory in my book too).
Attitude should be mandatory, but it’s not worth making things mandatory that you can’t actually enforce. Changing peoples' attitudes is a hard problem.
“You can certainly ship great software without most of the things on this list, and very few of them are things I’d consider mandatory (only two really)”
From Apollo to Cleanroom, the minimal things that got lowest-defect software were (a) attitude, (b) code review, © design/code done for easy verification, and (d) thorough testing w/ focus on usage-based. CI wasn’t even invented yet with Cleanroom developers not even allowed to compile their code. Even by Orange Book, the build system caught basically nothing in high-assurance systems since the key errors were knocked out with above plus formal specs. So, I’d say above is mandatory minimum. It worked for everything from security kernels to huge monoliths like OpenVMS.
Then the other stuff on your list starts coming in. It’s all valuable in that it would potentially catch problems. CI itself is so easy to do today one might as well do it since one needs a build system anyway. The thing you didn’t really put in your article was ©. You came close with the library part but not enough. The safety-critical, security-critical, and hard-real-time systems all use simple, easy-to-analyze, easy-to-compose structuring and language subsets so very little will surprise them. This aids both static analysis and whole-program optimization as well. The program is just easier to analyze.
So, worth putting something like that in there.
For code review, ReviewBoard is a great piece of OSS.