Date: Tue, 17 Jan 2012 02:43:21 +0000 From: Igor Mozolevsky <igor@hybrid-lab.co.uk> To: richo <richo@psych0tik.net> Cc: freebsd-hackers@freebsd.org, William Bentley <William@futurecis.com>, WBentley@futurecis.com Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <CADWvR2iNXJqD5%2BAeZFSW0U=K5qR_KG8XB4N_yXvvJER242=DKA@mail.gmail.com> In-Reply-To: <20120117022544.GB29529@richh-imac.office.boxdice.com.au> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <alpine.BSF.2.00.1201161606230.19710@kozubik.com> <20120117010239.GA29529@richh-imac.office.boxdice.com.au> <CADWvR2gT%2B5K2w_NWde%2BFWNjK=6NQ3rEKeZNDhvPSa7xLbgiJFg@mail.gmail.com> <20120117022544.GB29529@richh-imac.office.boxdice.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 January 2012 02:25, richo <richo@psych0tik.net> wrote: > On 17/01/12 02:21 +0000, Igor Mozolevsky wrote: >> >> On 17 January 2012 01:02, richo <richo@psych0tik.net> wrote: >> >>> This would be a different argument if all the devs were paid a salary. >> >> >> Isn't this a bit of a cyclical argument: developers don't work because >> they are not paid a salary, the end-user base shrinks, BigCo doesn't >> want to pay for someone to put extra work in getting fBSD to do >> something that it can get elsewhere (eg Linux), fewer still developers >> work on fBSD, end-user base shrinks, BigCo is even more reluctant, >> even fewer.... > > > Potentially, but it doesn't invalidate it, imo. > > I'm very aware that the code I produce for $WORK is very different to code I > write in my own time. Code for $WORK is wrapped in test cases, clean, neat > and well documented. > > code I write in my own time tends to be hackish, incomplete totally > undocumented and ludicrously easy to break because I'm intrigued by > implementing a single interesting figure that has my attention, or to see > whether or not a concept is technically feasible. > > This is a shortcoming of mine that I should work to overcome, but I feel > that > the same thing would likely extend to other developers, though in most cases > to a lesser degree. Without some other motivation most people naturally > gravitate towards newer "cool" features, rather than doing the relatively > boring maintenence and backporting. Are you not making a case for long and thin release cycle vs short and fat then? It's absolutely fine to have a branch (let's call that "development") that is cool-and-funky and breaks in 70% of the cases so long as there is another branch (let's call it "release") that is not-so-cool-and-funky, but only breaks in 1% of the cases, but is well documented, tested, &c and have the developer satisfaction of not only having implemented something cool, but knowing that once that cool is stable enough, that feature is used in environments where stability and dependability matters? A cool feature that nobody can rely on is, quite frankly, junk; is it not? To be realistic, I think any serious developer should expect to spend 70% of their development time on maintenance, for a simple reason that if the software is not maintained to the standard that end-users find usable, they will simply switch, and the user-base to test your latest cool-and-funky gets smaller and smaller... Of course, one way to avoid the 70% being spent on maintenance is to write flawless software, but good luck with that! ;-) This goes back to one of the points that John K. made: who is the system for, the developers or the end users? A system for the latter will quite happily give enough playground for the former, but a system for the former, will never work for the latter. Which, I suppose, is why your $WORK demands a certain quality of code---one way or another their livelihood depends on it!.. -- Igor M. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADWvR2iNXJqD5%2BAeZFSW0U=K5qR_KG8XB4N_yXvvJER242=DKA>