Saturday, September 01, 2007

** Dreaming in Code by Scott Rosenberg

A book for all software programmers to read since we've all been there and done that. Also, it is a book for all non-programmers to read who depend on or work in software companies to understand how in the hell software is 'engineered' if you can even call it that. My personal opinion is that software is a still cottage industry and has not entered an industrial revolution. When will that happen? I think when Moore's law finally slams into physical limits of quantum, and devices no longer become twice as fast and twice as small every 18 months, that all of the efforts and research will go into designing and building efficient software. Ultimately, the authors of this generation of software will be our own machines. Just like the machines took over for the laborers in the industrial revolution. Software developers will become line workers in software factories of the future. For the time being enjoy your job security and artistry.

Software programmers’ work is 1% inspiration, the rest sweat-drenched detective work; their products are never finished or perfect, just varying degrees of less broken. P10

Brooks’ Law: Adding manpower to a late software project makes it later. P17
Frederick Brooks is the author of the “Mythical Man Month”, and was the manager for the development of the OS for the system360 mainframe in the 1960s.

A 1995 survey of 365 IT managers found that only 16% of their projects were successful (on time and on budget). 31% were impaired or canceled – total failures. 53% were project challenged, a euphemistic way of saying that they were over budget, late, and/or failed to deliver all that was promised. 10 years later, the numbers for success have increased to 29% from 16%, failures have decreased to only 18% from 31%. But challenged is holding steady at 53%. P50

If you want to change the world you need pessimism of the intellect, and optimism of the will. – Antonio Gramsci p54

The memory banks of the earliest computers were build out of wound wire coils known as ferrite cores. Ever since programmers have referred to the computer’s memory as ‘core’. P65

The Python programming language is named in honor, not of the snake, but of the famous Flying Circus of Monty Python. Spam for unwanted mail is from another Flying Circus skit featuring a luncheonette menu featuring nothing but variations of eggs, sausage, spam, spam, spam and spam. P70

Yahoo= Yet Another Hierarchical Officious Oracle p100

There’s an old project manager saying: I can make it for you fast, cheap or good. Pick any 2. p119

With manufacturing, armies and hardware development, the managers can walk through and see what everyone is doing. If someone is doing something wrong or unproductive, the manager can tell just by watching for a few minutes. However, with a team of software developers you can’t tell what they are doing by merely watching. You must ask them or carefully examine what they have produced… Most developers would be glad to tell their managers where they stood on the job. The problem is that with current software practices, the developers don’t know where they stand any more than the managers do. P129

IT staff vs. the general population
77% of IT staff prefer a Thinking decision making profile vs. Feeling. This split is 50/50 in the general population. 41% of IT staff are introverted, which is twice the frequency in the general population… This group is the least likely to engage and connect interpersonally with others, and may avoid creating personal bridges of trust and openness with colleagues. P133

FUBAR= Fucked Up Beyond All Recognition p196 This has become FooBar over time.

Why we all have to plan by Watts Humphrey (he took over the System360 project for Brooks). P245
We all work for organizations
These orgs require plans
Unless you are independently wealthy, you must work to a schedule
If you don’t make your own schedules, somebody else will
Then that person will control your work

Agile Software Development Manifesto p252
Value individuals and interactions over processes and tools
Value working software over comprehensive documentation
Value customer collaboration over contract negotiation
Value responding to change over following a plan

Joel Spolsky’s engineering test. Joel authored Excel at Microsoft. P257
Do you use source control
Can you make a build in 1 step
Do you make daily builds
Do you have a bug DB
Do you fix bugs before writing new code
Do you have an up to date schedule
Do you have a spec
Do programmers have quiet working condition
Do you use the best tools money can buy
Do you have testers
Do new candidates write code during interviews
Do you do hallway usability testing (Rather than using an in-house, trained group of testers, just five to six random people, indicative of a cross-section of end users, are brought in to test the software)
http://www.joelonsoftware.com/articles/fog0000000043.html

Rosenberg’s Law: Software is easy to make except when you want it do something new. Collary: The only software that’s worth making is software that does something new. P268

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization. – Gerald Weinberg p284

Ultimately we need to stop writing software and learn how to grow it instead. We think our computing systems are unmanageably complex, but to a biologist – who regularly deals with systems that have many orders of magnitude more moving parts – something like a computer could not possibly be regarded as being particularly complex or large or fast. Slow, small, stupid – that’s what computers are. – Alan Kay, creator of SmallTalk. P286

Of all the things you can spend a lot of money on, the only things you expect to fail frequently are software and medicine. That’s not a coincidence, since they are the 2 most complex technologies we try to make as a society. Still the case for software seems less forgivable, because intuitively it seems that as complicated as it’s gotten lately, it still exists at a much lower order of tangledness than biology. Since we make it ourselves, we ought to be able to know how to engineer it so it doesn’t get quite so confusing. P292

With protocols you tend to be drawn into all or nothing high wire acts of perfect adherence in at least some aspects of your design. Pattern recognition in contrast assumes the constant minor presence of errors and doesn’t mind them. P293

The fundamental challenge for humanity is understanding complexity. This is the challenge of biology and medicine. It’s the challenge in society, economics. It’s also the challenge of software…Whatever path you go down, you come again and again into a complexity barrier of one sort or another. P295

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s law. P331

Ward Cunningham created the wiki because he wanted his collaborators to fix their own documentation mistakes. The young developers who started collaborative project mgmt tool also built a small program to write a web journal and communicate with their users. That little project became Blogger. Ludicorp was an online role playing game that ended pretty quickly, but its creators revamped some of its parts and built Flickr. For that matter, who in 1991 could see that a little effort at a particle physics lab would evolve in the World Wide Web? P340

Why can’t we build software like we build bridges? Well maybe we already do. The project of replacing the 4.5 mile SF Bay Bridge was born in the 1990s after the 1989 earthquake. The original design called for a low slung unadorned causeway, but political rivalries and local pride led to the adoption of a more ambitious design… There was only one problem.: Nothing like it had been built before. And nobody wanted to tackle it. Only 1 contractor submitted a bid… Now the new bridge is scheduled for completion in 2012 – 23 years after the quake. And the cost will be astronomical. P347

No comments: