sourcefrog : software/management

Open Source Under the Microscope

What are some of the differences you've found, apart from the obvious ones? For example, in software engineering, there's a widespread view that it's necessary to elicit and capture the requirement specifications of the system to be developed so that once implemented, it's possible to pose questions as to what was implemented, compared with what was specified.
We do not see or observe or find in open-source projects any online documents that software engineers would identify as a software requirements specification. That poses the question: What problem are they solving, if they haven't written down the problem? While it's true that there's no requirements specification, what there is instead is what we've identified as a variety of software informalisms.
What do you mean by "informalism"?
That word is chosen to help compare to the practice advocated in software engineering, in which one creates a formal systems specification or design that might be delivered to the customer. Informalisms are such things as information posted on a Web page, a threaded e-mail discussion or a set of comments in source code in a project repository. It may be a set of how-tos or FAQs on how to get things accomplished. Each is a carrier of fragments of what the requirements for the system are going to be.
If they're put together in such a haphazard way, can they really be considered requirements? Yes and no. Clearly, they're distributed, but in order for people to contribute to the project, those people need to understand where those requirements are and how they relate to each other and how to pull them together. Part of how the community works is that each of the participants discusses what the system should do in whatever informalism they feel is the most appropriate to them.

posted Wed 7 Jan 2004 in /software/management | link

Myths Open Source Developers Tell Ourselves

“chromatic” writes about Myths Open Source Developers Tell Ourselves. A pretty good little essay.

Many of the items apply to non-open projects too, and in fact some of them are even more relevant to internal development. Open source projects need to make their code at least a little bit approachable to new developers, which is not true for in-house trees...

posted Fri 19 Dec 2003 in /software/management | link

The orb of discomfort

jwz says that every program expands until it can read mail. I'd like to propose another: projects eventually reach a point where all the intelligent questions have been asked. Here is my theory.

There are no more bugs, because they've all been removed. (OK, this never quite goes to zero, if only because of change in the underlying platform.)

The program either has all the features that make sense, or it has all the features that can fit into the current architecture. Suggestions of any others are a FAQ.

Therefore, the majority of mailing list questions either reflect user error, or failure to read the documentation.

Preponderance of annoying questions discourages developers and other people, and makes the project move even more slowly.

posted Tue 16 Dec 2003 in /software/management | link

Reading Code

From Salon:

"It's funny," says Dave Thomas, a Dallas software consultant and co-author, with Andrew Hunt, of "The Pragmatic Programmer," a 1999 book on software design methods. "Colleges spend a lot of time teaching people how to write code, but very few teach them how to read code. When you think about it, we programmers spend most of our time reading code, not writing code."

That's very true. Here I am with six multi-hundred page PDFs open, trying to work out what EFI, BMC, MP, etc mean...

I hear Tridge used to teach operating systems by (amongst other things) paging through files of the Linux kernel with emacs and etags, describing how different things worked. I think that would work a lot better (at least for the good students) than hearing vagueness about how things work in theory or writing toy programs. Writing toys and studying theory is important too, but I think many students miss the illumination of seeing actual large programs.

Ward Cunningham's Signature Survey program[,] a "method for browsing unfamiliar code," Signature Survey scans through source code and compresses lines of text into a single punctuation symbol. Operating on the assumption that a file's size is proportional to the number of punctuation marks separating individual elements (packages and files in Java, for example), Signature Survey offers a quick guide to programming thickets and areas of quick repetition.
"It's a satellite system for looking over large bodies of work," Cunningham says. "It lets you use your own human pattern recognition to see variation over the whole program. It also leads you to interesting parts of the program to read."
Thomas says his own preferred technique is to import a program's contents into Microsoft Word and reduce the zoom factor as far as it will go. The resulting 50-page image leaves little for the eye to make out other than jagged patterns of text and blank page. Still, even these patterns can reveal peculiar anomalies in developer mood or style. "Sometimes the structure is easier to see at that level than if you're digging around line-by-line," he says.

posted Fri 1 Aug 2003 in /software/management | link

Ouch...

Doktor Memory writes:

Please notice that despite the nonstop handwaving from the Mozilla team about how maintaining seperate native interfaces for the assorted Gecko frontends was supposed to be some sort of impossible herculean task that no reasonable person could be expected to tackle, in the time that it took to produce ONE semi-functional version of Mozilla, Opera Software, a company with not even a tenth of AOLNSCP's resources, produced multiple versions of a fully functional web browser, for all of Mozilla's major target platforms. Not only did they produce, maintain and upgrade native Windows, MacOS and Linux versions of Opera, but they increased their market share, and made money doing it.
"We had no choice but to implement XUL/XPFE" is the Big Lie of the entire Netscape saga. The fact that mozilla team members are still stating it with cultish earnestness suggests not that you all came to a reasoned engineering decision, but that your project management was not merely incompetant, but downright pathological. If 1% market share and the firing of your entire development team isn't enough to convince you that somewhere, somehow, you made the wrong decision, you are simply delusional.
Hopefully, some of the core Mozilla developers and managers will use some of their newly acquired free time to read Fred Brooks' "The Mythical Man-Month." When Brooks talks about the Second-System Effect, he's talking about you.

I don't know if this is really fair for Mozilla but it's certainly true in general.

Those who do not study history are condemned to repeat it.

posted Thu 17 Jul 2003 in /software/management | link

Computer Programming - What's it Like?

David Every has a little rant about software engineering as a career:

Many can't get over the stupidity, and go job to job looking for utopia; or at least the fictitious job where complete incompetence is not the norm. Those looking for where the grass is greener are usually continually amazed that things can, and do, get worse from their previous jobs. I have people from many different companies whine about how their management sucks worse than anyone else's; then someone tells them stories about places they've worked or decisions that are made, and there's silence while they process that. Four programmers around a table can quickly devolve into a game of, "my management is more stupid than yours". The sad thing about human nature is that you cannot over-estimate how low it can go. Sadder still is this is in America, one of the most effective and productive nations in the world; many foreign countries have even more bureaucracy, hierarchy and stupidity.

posted Tue 15 Jul 2003 in /software/management | link