On Sun, Nov 7, 2010 at 12:40 AM, Rob Landley <[email protected]> wrote: > The failure mode is "managing what you can measure". Focus on what you can > measure and consider it more important than what you can't. > > BusyBox doesn't have a metric for simplicity, but it does have a metric for > size (and to a lesser extent functionality: you can enumerate new features and > even add regression tests for them). Thus size/features are what you think > about, what you constantly check, it becomes more important over time, and > comes to eclipse simplicity. > > This gets you in big trouble when the metric you've got is only a proxy for > the thing you really want, because people game the system. When IBM focused > on KLOCS (thousands of lines of code) as a programmer productivity metric, > their employees cut and pasted their way to productivity bonuses and the > actual code quality suffered tremendously until they stopped incentivizing > that > metric. > > This isn't just a programming thing, it's the same failure mode which leads > corporations to take away the free towels in the gym, because the cost of > providing the service can be easily measured but the morale boost it gives the > employees can't, therefore one is "real" and the other isn't. > > Even when the metric is real and important, it tends to lead to the things you > can't as easily measure getting ignored, because they're harder to think > about. You have to make an effort to see them. It's an easy trap to fall > into > and a hard problem to solve, especially when the things you can measure are > good things and important to get right, so spending time on them isn't > necessarily _bad_... They're just not the whole story.
I actually started looking at a lot of things which were not watched and were allowed to rot. Approximately in the order I started looking at them: * stack size * bss size * fix most of bugs filed in database (most of them were easy) * warning-free build * randomconfig error- and warning-free build * code readability * expanding testsuite, especially shell testsuite (did not even exist) * assuring testsuite does not show regressions with new releases * running testsuite over randomconfig build does not throw false positives Basically you complain that I also had to watch for and not allow complexity to increase too much, and I did not do that. This doesn't seem to be entirely fair. I can't do everything. > I'm not saying more features is bad. I'm saying the loss of simplicity is > bad. So what's your proposal? > All three things trade off for each other, but one of them has taken it > on the chin in favor of the other two. It makes the project uncomfortable for > me to work on, and I don't believe the amount of time/energy I have available > to put in won't even keep up with the ongoing degradation of the quality. I guess someone else needs to do that, if you don't have the time. Sad but true: there is always more things to do than time available. For example, one of _my_ longstanding TODOs: uclibc testsuite needs reviving. It has bit rotted. > I'm already running a red queen's race over on the kernel and qemu side, and > LLVM will be another, and when I start caring about the unreleased uClibc code > that will be another, and when I get distros natively bootstrapped the > bootstrapping logic will bit rot too. Sometimes I just not let myself to start hacking on something new. Because I know there will not be enough time to continue. Maybe you can do the same. If you feel overloaded, just resist the temptation of working on less important things. For example, why do you want to bootstrap distros? Is its value worth the time you expect it to take? Do you remember that you do need to sleep sometimes? ;) Good news if that if your project is successful, you might eventually find that other people taking parts of work on themselves. You might eventually acquire a "lieutenant" who will maintain "building distros on Aboriginal Linux" chunk. *Thats* how projects scale beyound what can one person do in 24 hours per day. But this requires social skills, yes. Linus, not Theo de Raadt. > I'm glad busybox does more things for more people, but I'd already implemented > most of the feature set I personally needed to do this back in 1.2.2, and the > remaining bits I've added since (oneit, patch, nbd-client, ccwrap, etc.) could > live as individual files in sources/toys/*.c if necessary. (You'll note I > haven't pushed oneit into busybox, even though an init program designed to > launch a single executable with a proper controlling TTY and signal handling, > reap zombies until that executable exits, and then shut the system down... > once upon a time that simplicity would have been in busybox's purview. But it > would have been a unique facility of busybox, not a copy of an existing > program somebody else already wrote and maintains externally, and thus not > part of busybox's _current_ mandate. Active contributors have privileges like adding their personal toys :D Mine is nmeter. I think adding yours is ok too. > I'm happy that busybox is well maintained, and I'm happy that if I post a bug > report here it tends to get addressed promptly. But my goals and busybox's > goals have drifted apart over the years, and I'd rather spend the majority of > my time elsewhere now. I don't have a problem with that. Work on things you enjoy most. If you don't really enjoy hacking on busybox, don't torture yourself. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
