Afbeelding van de auteur.

Voor andere auteurs genaamd Scott Rosenberg, zie de verduidelijkingspagina.

3 Werken 1,014 Leden 30 Besprekingen

Over de Auteur

Fotografie: JD Lasica

Werken van Scott Rosenberg

Tagged

Algemene kennis

Geslacht
male

Leden

Besprekingen

Jaron Lanier mentioned this book in his Dawn of the New Everything (and Rosenberg mentions Lanier in here a couple of times...crossover: "Computer scientist Jaron Lanier tells a story about an encounter between the young Engelbart and MIT’s Marvin Minsky, a founding father of the field of artificial intelligence. After Minsky waxed prophetic about the prodigious powers of reason that his research project would endow computers with, Engelbart responded, 'You’re gonna do all that for the computers. What are you going to do for the people?' "). Being an old programmer from the mainframe/teletype/punch card days, I was intrigued, so I read it in parallel while on vacation last week. I knew little of this effort to create Chandler; I was in Korea as it grew, and still there when it died. A mix of the history of the application, the people involved, and of the technology, this is a story of the modern application: lots of promise, and lots of problems. From the description of the vision(s), Chandler would have been great. But...it never came to be. Other apps establish dominance regardless of inferiority (MS Word still can't do the inline formatting that Word Perfect did.) Yes, I use Outlook, and the rest of the M$ Office Suite. I don't use their browser, but it's an inconvenience to buck the trend to interact with the world. Perhaps somebody will come along with an PIM as versatile as the Chandler dream. (No, web based stuff from Google, etc. are clumsy and well, inconvenient.)

One really good insight (of many) found near the end:
My view is that we should train developers the way we train creative people like poets and artists. People may say, ‘Well, that sounds really nuts.’ But what do people do when they’re being trained, for example, to get a master of fine arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don’t look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don’t look at their design. You don’t study the lives of great software designers. So you don’t study the literature of the thing you’re trying to build.”
Brilliant, right? So why do they study great code? (A snarky answer might be "because there isn't any?") Algorithms, yes, but so many languages and systems have those algorithms already embedded. On the insistence of my advisor, I took a grad school class on finite element analysis that turned out to be building the code ourselves, not using it for analysis. And no, all we had was the textbook and a professor who cut the semester short to go on a speaking tour in India. Anyway, this is an idea with merit.

Selected highlights and notes:

[on Frederick Brooks, who wrote the 1975 book The Mythical Man-Month, a jumping off point] Brooks was a veteran IBM programming manager who had seen firsthand the follies of the largest software project of its day, the creation of the operating system for the IBM System/360 [...] And so he formulated Brooks’s Law, which is both a principle and a paradox: “Adding manpower to a late software project makes it later.”
Find (Lanier also referenced it) And Brooks's Law also applies to construction. Too many painters in a room don’t make it finish sooner.

[Jumping off point] The work ["Framework for the Augmentation of Human Intellect"] culminated in a legendary public demonstration in 1968 at the San Francisco Convention Center. A video of that event is still available online, which means that today anyone can, by following some Web links and clicking a mouse, watch Engelbart introduce the world to the very idea of a link, and the mouse, and many other elements of personal computing we now take for granted.
Find

[on "brain muscle memory"] That’s a limitation of the world of physical objects. But there are advantages, too. Once you’ve lived with your arrangement a while, you discover you can locate things based on sense memory: Your fingers simply recall that the Elvis Costello section is over at the right of the top shelf because they’ve reached there so many times before.
I so know this. After we restored our house from a fire, in which we lost 5,800 books (along with almost everything else), I would walk into what was the library but never again, and instantly know Tolkien was there, Chalker there, my religion books over there… I still had the memories 8 years after the library was destroyed and none of those books existed,

[on software development] Because it so often takes ages before a new piece of software is ready for anyone to use, programmers often test their assumptions against “use cases”—hypothetical scenarios about how imaginary people might need or want to use a program
Modern application implementation teams do this as well to customize an existing app to a new user group

[jumping off point] Eric Raymond had written in The Cathedral and the Bazaar
In case I didn’t flag this already, find

[on] Object-oriented programming: More than any other of the arcane terms that have migrated beyond the closed world of the programmer, this one has resisted clarity and invited misunderstanding. Even after reading hundreds of pages on the subject, discussing it with experts, and attending a number of lengthy lectures on the topic, I cannot say with 100 percent confidence that my own explanation of the phrase will satisfy every reader.
I’m so old school, having cut my teeth on Fortran and Basic before assemblers, that I still have the “new” versions of “structured programming” to overcome.

[on existing code] The world is full of code that someone else has written. Shouldn’t it be easy to grab it and use it for your new project? Why then do so many programmers glance at existing code and declare authoritatively that they could do it themselves, faster, easier, and better?
Hubris. There can be some fun in deciphering, then recasting and then rewriting, only to determine that misunderstanding the initial coding led to cascading errors… or the rare, I actually did fix it.

[on Apple's silly metric of "lines of code written"] If counting lines of code is treacherous, other common metrics of software productivity are similarly unreliable.
I had to deal with meaningless measures in my last job... number of work orders, dollars spent… non normalized, non contextualized useless data

[on MBWA]
The informal approach to managing technical projects achieved its most famous incarnation at Hewlett-Packard with the concept of “management by wandering around,” which was later popularized by Tom Peters’s In Search of Excellence. This rigorous methodology requires managers to leave their offices, visit workers in their dens, and chat them up. “How’s it going?” may not sound like the most incisive or analytical line of inquiry, but management by wandering (or walking) around was revolutionary in its way: It suggested that it was less important for managers to pore over ledgers than for them to get out and observe what their employees were actually doing. It placed a premium on human observation and contact.
It is an excellent management method.

[jumping off point] Christopher Alexander’s book A Pattern Language
Find (found...it's a tome)

[on Mitch Kapor's Software Design Manifesto] A lot of Kapor’s manifesto may sound self-evident today, but his assertion that designers should take the lead in creating software remains controversial. Some programmers look down on the very idea of design and designers, and are quite certain they are the best arbiters of how their programs should look and behave
Tom Peters and others advocate incorporating designers in everything. I agree. And... I know that designers must be managed!

[on a Big Mistake (my opinion, not theirs)]
Getting Things Done suggests that modern life and work leave us mentally beset by a host of incomplete tasks: physical objects lying around us waiting to be dealt with, incoming emails that need to be answered or filed, documents and publications that we’re supposed to read, things we’ve promised other people we will do. This heap of “open loops” collectively constitutes what Allen calls our “stuff.” GTD proposes that we can stop feeling overwhelmed by our stuff and take charge of it by creating a “trusted system”—on paper or digitally, it doesn’t matter.
Oh, dear. Awful awful book and methodology. My review is here, but the short of it was “You have a choice: you can Get Things Done, or you can actually get things done.” Seems that Chandler opted for the former… and died.

[Michael Toy, speaking to the author after he left the Chandler team]
Mitch Kapor is spending millions of dollars a year and does not want to have responsibility for little details. He wants to find someone to make sure his money is being well spent. And that’s a level of detail that I could not provide. And a level of assurance that I could not provide. Mitch was really patient in just saying, ‘I will help you get better at these things.’ So I have no complaints about the position I was in. But in the end, I was just being asked to provide a service that I wasn’t very good at.
Get someone NOT in the business. This is the trap almost every organization falls into - they think you have to know everything about the business to succeed in managing it. My wife edited English versions of Samsung phone and copier/printer user manuals and made them better because she wasn’t an engineer … she asked why do you have this button? Or how it that a new feature? (True life example. The engineers’ answer? We moved that button to the right side from the left.) The key in that was that she was an end user and thought like one, not like the engineers.

[on the author's misunderstanding of Fortran and Basic] Like a film editor making a jump cut, GOTO simply dropped one story line that a program was developing and picked up another. It handed off control from one point in a program to another unconditionally, taking nothing else into account—neither the values of different variables nor the state of the program and its data.
Not really…GOTO was used inside the program and the values remained until control left the program. Now, function calls and subroutines were different.

[Watts Humphrey's summary of the Capability Maturity Model] An organization at Level 1 is basically not doing much of anything. At Level 2, they’re doing some planning, tracking, configuration management, they make some noises about quality assurance, that kind of stuff. A Level 3 organization begins to define processes—how they work, how they get things done, trainable things. At Level 4 they’re using measurements. They have a framework for actually tracking and managing what they do, something statistically trackable. Level 5 organizations have a continuously improving process.

[the author] Once, while interviewing a job candidate at Salon, I apologetically described the state of disarray of our technical operation at the time. “Ahhh,” said the interviewee with a diplomatic smile. “Then you’re using agile methodology!”
Yeah… yet another buzzword for less than useful methodology. I dealt with salespeople of the words; and I worked with a handful who actually made it work.

[on Joel Spolsky, former project manager for Microsoft]
In another essay he writes: “Beware of Methodologies. They are a great way to bring everyone up to a dismal but passable level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It’s pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald’s, precisely because of McDonald’s rules.”


[on object oriented programming] To Kay’s dismay, Smalltalk’s most radical innovations never made great headway in the software marketplace, and the kind of object-oriented programming that took over the computing mainstream in the nineties is, in his view, a bastardization. (“I made up the term object-oriented,” he says, “and I can tell you, I did not have C++ in mind.”

[on true open source software] Lanier’s “Gordian Software” article provoked a firestorm of criticism on the Edge.org Web site, John Brockman’s salon for future-minded scientists. Daniel Dennett accused Lanier of “getting starry-eyed about a toy model that might—might—scale up and might not.” But Lanier is unfazed. He says his critique of software is part of a lifelong research project aimed at harnessing computers to enable people to shape visions for one another, a kind of exchange he calls “post-symbolic communication” and likens to dreaming—a “conscious, waking-state, intentional, shared dream.”

[jumping off point] The Art of Computer Programming shows programmers how to design and test algorithms for efficiency.
Found. And it is huge! multiple volumes and subvolumes. It may not be something I'll ever have time to tackle.
… (meer)
 
Gemarkeerd
Razinha | 24 andere besprekingen | Apr 9, 2022 |
Mitch Kapor (of Lotus 1-2-3 fame) has the misfortune of funding an ambitious software project just as the World Wide Web was going through its Web 2.0 phase. It's a complicated story, related in a lot of detail, but without any heroes and without a happy ending.
 
Gemarkeerd
superpatron | 24 andere besprekingen | Feb 25, 2019 |
Rosenberg attempts to do for software what Tracy Kidder did for hardware in 'The Soul of a New Machine' back in the early 1980s. Rosenberg follows a team of software developers as they attempt to build an alternative personal information manager called Chandler to compete with Microsoft's Outlook and match/extend the capabilities of the Lotus Agenda product (Chandler was originated and initially funded by Mitch Kapor, the developer of Lotus 1-2-3). Well, we all know where that story ended - Chandler was eventually released in 2008 and after a few minor updates a final release was made available in 2009, since when the product has signally failed to fire much enthusiasm.

Rosenberg provides an interesting narrative of how the Chandler product development proceeded, but fails to put any real life into the story, leaving us unsatisfied and generally uninterested in what is going on and what the ultimate fate of the story is (the book was published before the final product was released and its subsequent fade-to-black). The problem here is that Rosenberg cannot decide if this is a book about software development or about project management. Software development is a devilish tricky thing to write about - how do you make the story of a guy (usually, a guy) staring into space for a while and then typing esoteric technical stuff into a computer something that people want to read about? At least project management involves human interaction and has some historical backstory (Rosenberg leverages Fred Brooks' 'The Mythical Man-Month' throughout).

As an insider (I have worked in the computer industry for 40+ years) I found this an interesting and relevant book. For non-geeks who want peek inside the kimono I don't think this gives them any more insight and understanding of what software development is than they had before.
… (meer)
 
Gemarkeerd
pierthinker | 24 andere besprekingen | Dec 7, 2015 |

Misschien vindt je deze ook leuk

Gerelateerde auteurs

John Cusack Actor, Screenwriter
Jeff Pinkner Screenwriter
D. V. DeVincentis Screenwriter
Steve Pink Screenwriter
Kelly Marcel Screenwriter
André Nemec Creator
Tim Bevan Producer
Rudd Simmons Producer
Seamus McGarvey Cinematographer
Riz Ahmed Actor
Tom Hardy Actor

Statistieken

Werken
3
Leden
1,014
Populariteit
#25,405
Waardering
½ 3.6
Besprekingen
30
ISBNs
43
Talen
2

Tabellen & Grafieken