[arch-dev-public] Reactive development [was: Repository cleanup]

[Aaron Griffin]

On 9/12/07, Simo Leone <simo at 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.