On 9/12/07, Simo Leone <simo@archlinux.org> wrote:

What I'm trying to get across here is that some parts of this dev team have adopted a reactive development model. By this I mean that the majority of your devel is driven by whatever issues come up, as they come up. Do you realize why that's bad?

Typically projects will go through some solid research and plannning to avoid this situation. I've heard that when the developer has a solid understanding of the problem, they often develop more generic tools that have more unforseen uses in the future than when they develop reactively. This is why, for instance, pacman is so versatile in that it alone can be used to solve all these problems (like phil said). Gee, what a great tool.

Sorry for the slight OT, it's kind of related.

Wow. Simo said exactly what I've been feeling for some time now, much more concisely that I even had formulated the thoughts. This is also a very CRITICAL point, and the root of every problem we've had recently. See, ok. Rant-ish time now. I know a lot of you don't do this for a living. You don't work in software. Me? I've been doing this for over 7 years now professionally. Companies large and small, new companies with new technology, old companies with giant 100MHz mainframes, writing code in over 10 different languages. I've written bugs that made people laugh, and bugs that cost a company thousands of dollars. I've been there and done every stupid bad thing you can imagine (update without a where clause on a production DB anyone?) I've been forced to learn how to go about the process here. That's our problem. We have a disparity here between people who don't know common software development practices, and those who do. Those who know these processes expect everyone to implicitly follow them, and those who don't know them think they're silly. Here's the long-and-short of it. When you have cost a company $10000 due to one bad line of code, you learn to appreciate what a one hour code review can do. You learn to appreciate proper communication channels when two people make "hotfixes" to a live DB that break each other. This is what we're lacking. And sadly, it's a word everyone hates. We're missing "process". It is a _fact_ that as groups grow, they need more control. A group of 5 of us could easily coordinate things, but we're well over 25 (Phil said 30? wow!) and at this point we CAN'T keep doing things without proper process. It's just silly. Communication channels must be kept in check. If you do anything that affects the rest of us, then we should know about it before the users do. This includes important module changes (oh crap guys, I broke your X!), changes to initscripts (isatty is missing, btw), new ISO releases (I burned 3 copies of "Don't Panic" 2 days before the new release, for the record), and just... well... anything. Seriously, communication isn't hard. Hell. I know english may be a barrier, but why don't you write in german or something with "Please Translate:" at the top just so we know something is happening. That said, we have always held that the mailing lists are our proper channel of communication. This is important. Hell, it's critical. Saying "hey guess what!" on IRC doesn't cut it. The mailing list not only informs everyone (not all devs are on IRC) but also has archival history. We need to communicate. We need to follow processes. If you find a bug or a user report, and you're unclear about it - **say something**. The great word being flung around these days is "unilateral" - we're not a group of 30 independent people doing their own things, we're a group of 30 people working together. We need to stop reacting and doing our own thing. If something seems questionable, say something. Say "hey guys what do you think about N?". Just bring it up. Not everyone will respond. That's expected. Sometimes you have no opinion, but at least we KNOW what's happening. Guys, seriously. We're floundering. Something needs to be done, and it's not up to one or two of us. It's up to all of us.