Inbox Zero talk

Dreaming in Code

>
Similarly, there was nothing especially scary about bug number 44. It was a routine sort of problem that programmers had accepted responsibility for ever since computer software had migrated from a text-only, one-line-at-a-time universe to today's graphic windows-and-mouse landscape. What scared Toy was not so much the nature of Bug 44 but the impossibility of knowing how long it would take to fix. Take one such unknown, place it next to all the other similar unknowns in Chandler, multiply them by one another, and you have the development manager's nightmare: a "black hole" in the schedule, a time chasm of indeterminate and perhaps unknowable dimensions.

Two months before, the entire Chandler team of a dozen programmers had met for a week of back-to-back meetings to try to solve a set of problems that they had dubbed "snakes"--another word Toy had salvaged from Netscape's ruins. A snake wasn't simply a difficult problem; it was an "important problem that we don't have consensus on how to attack." Snake superseded a looser usage at OSAF of the word dragon to describe the same phenomenon.
<

>
I believed that the most important software needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time. Linus Torvalds's style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet, reverent cathedral-building here—rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who'd take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles. The fact that this bazaar style seemed to work, and work well, came as a distinct shock.
<

>
A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams, too.
With nine months of work under their belt and a product that remained more vision than code , the Chandler programmers still hadn't found their hustle.
<

>
The 1955 report argued that the problem with software wasn't just a matter of too many midstream course corrections and late design changes that would never be tolerated by the builders of bridges; it was also a problem of failing to learn from mistakes: "When a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry where failures are covered up , ignored, and/or rationalized. As a result we keep making the same mistakes over and over again."
<

>
Software is abstract and therefore seems as if it should be infinitely malleable. And yet, for all its ethereal flexibility, it can be stubbornly, maddeningly intractable, and is constantly surprising us with its rigidity.

That paradox kicks in at the earliest stages of a programming project, when a team is picking the angle of attack and choosing what languages and technologies to use. These decisions about the foundations of a piece of software, which might appear at first to be lightweight and reversible, turn out to have all the gravity and consequence of poured concrete.
<

>
Nobody should start to undertake a large project Torvalds snapped. You start with a small trivial project and you should never expect it to get large. If you do you'll just overdesign and generally think it is more important than it likely is at that stage. Or, worse, you might be scared away by the sheer size of the work you envision. So start small and think about the details. Don' think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly overdesigned.
<

>
Most elements of software are incorporeal and invisible. There is nothing to point to. So talking about them is unexpectedly difficult. This is one reason why the whiteboard is such an iconic presence in any space where software is labored over; it provides a canvas for laying out the abstract processes of a complex program in ways that allow people to point to what they're talking about.
<

>
They still dreamed about building the bigger platform - the open-ended, world-changing tool that, with the right additions of code, could organize and connect all sorts of disparate data.
<

Java Bean Feedback

This is from a user that is embedding the Java Bean.

"By the way, whoever designed and created Anywhere is quite a creative genius. It is a fantastic accomplishment!"

The Creative Process

The creative process generally resists being put into words. As Louis Armstrong said, "Man if you have to ask 'What is it?' you ain't never goin' to know."

The Ultimate Compliment

This is from an email Mike got yesterday. It's from a user with a leadership position in a top institution (I will not put any names in case anybody roams in here). I think this is the ultimate compliment that we can get from our customers. It is a reflection on the effort that we all put it to do things right and go beyond "good".

>

This is out of the blue but I'm very impressed with your company and was wondering if you are looking for someone with my background to work for Progeny

<