4 ms·
" if you have one person who "owns" a part of the code, you are inviting disaster and bad design. " I think we have different definitions of ownership. To me,
by fsloth 12y ago
" if you have one person who "owns" a part of the code, you are inviting disaster and bad design. "
I think we have different definitions of ownership. To me, ownership signifies that a certain person is aware of the history of a particular area of code, is responsible for keeping it in good shape and is usually the go-to person for all modification, or at least code reviews all work done to the code.
This does not mean that they should be the only one who understands it and has the ability to modify it.
I think we both agree that the understanding of the code should be dispersed, so that any other employee can get up to speed with the code just in case the prior owner exits the organization.
I'm working at an organization that some parts of which do development in the "share all" mentality and some of which try to maintain code ownership in the way I described. The code ownership strategy seems to work much better, but, YMMV as always.
When the code ownership is not made explicit, actually there can develop pockets of "accidental ownership" even in the "share all" codebase. Something that only one person has ever touched, and who does all the modifications because all the organization needs is a tiny, quick tweak, and the codebase is already a hot mess after endless amount of these "quick tweaks".
"I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed"
Those all are large scale systems, so I cannot speak for them.
However, in the scale of day to day coding, I've usually attempted applying good design to all of my prodcution code and usually the only feedback I've got from my way of working has been positive. I've shipped on time and the bugcount (for all I know) has been low.
So, based on my experience, I really cannot concur with you.
Perhaps our experience from software development is from a completely different business area. Professionally I specialize in performance critical C and C++, 8 years and counting so perhaps I've not been long enough in the field just yet to witness the fail of good design.
- angersock 12y agoI suspect our experience is indeed different. :) I've had the good fortune of working with good programmers doing performance critical C and C++ for a hobby project--the time spent in design has paid off, and the codebase is a joy to work with. Sadly, the code has yet to see the light of day, because reasons. For the purpose of "get game project finished", more bad code faster probably would've been better, though we would've had to rewrite it anyways. As for the rest, I've been in a few shops now where people who should've known better (or who didn't!) have written klocs and klocs of unmaintainable poorly-performing garbage and who subscribe to the "code owner" philosophy. The result is, of course, that you can't fix or even organize their messy fiefdoms, and so there is no peace-of-mind to be had that the code works. And yet, the businesses still trundle along to this day despite what is probably stage 4 cancer of the IP. Maybe it's just Stockholm syndrome. I kind of feel like an abused puppy every time I have to look at that code and fight, for hours and weeks, to do something as basic as "Hey, maybe we should try both debug and release targets!"