Archive for the 'engineering' category

Reading Diary: On the Grid by Scott Huler

In his incredibly wonderful new book, On the Grid: A Plot of Land, An Average Neighborhood, and the Systems that Make Our World Work, Scott Huler gives us three essential take-aways:

  • Thank God for engineers
  • Get out your wallet
  • Let's learn to love our infrastructure. (p. 217-225)

In fact, not much more need really be said about the book. In essence it's a kind of tribute and salute to the women and men who keep our highly technoligized society functioning. The people we often forget about, whose glamour pales in comparison to movie stars, singers, politicians, even police and fire departments who have a much higher profile. Huler is really talking about the engineers and technicians and workers who drive buses, build roads, survey new neighbourhoods, keep our lights on and make sure the waste from all of this activity gets carried away somewhere safe.

Of course, the perils of infrastructure are in the news these days, but I think the current troubles in Japan are only more indicative of the need to pay attention to the threads that keep our society running. Huler visits a local nuclear power plant in one of the chapters and I'd be curious about his thoughts on the long term place of nuclear power in a sustainable world energy mix. He does have some thoughts on the infrastructure workers involved in Japan right now.

Anyways, in the book Huler takes us all on tour with him as he explores the various types of infrastructure in his own city and neighbourhood: water, garbage, electricity, telecommunication, transportation, boundaries and surveys. He visits with the people who work on those systems and witnesses the daily work. He struggles with the short- and long-term challenges of keeping the lights on, literally.

And makes sure we start to understand how important it is to keep track of what's going on under the street as much as we keep track of what going on in all the buildings.

And he really makes sure we understand that all of this costs money to do right and that we should be willing to pay for it. And he doesn't shy away from some of the environmental issues either -- the impact our infrastructure choices make beyond our daily lives and on society and the planet as a whole.

I thought it would be interesting to take a sentence or two from each chapter to give a sense of the themes that run through the book -- and the countless little revelations about our infrastructure.

  • Chapter 1: land surveys: [about an old axle used as a place marker on his land] "It's a big, solid piece of iron sticking our of the ground, and it's been there for almost a century." (p. 27)
  • Chapter 2: the hydrological cycle: "So as I looked at the roots of Raleigh's infrastructure, I tried to think like water." (p. 32)
  • Chapter 3: water treatment & distribution: "'The only time customers see us...is when they're gonna be late for work because we've got a backhoe sitting in the middle of the road. The unfortunate thing about our job is that as long as we're doing a good job, nobody notices.'" (p. 69)
  • Chapter 4: waste water: "Until around World War I ... it was understood that watercourses were to some degree self-cleaning, that 'the solution to pollution is dilution.'" (p.92)
  • Chapter 5: roads: "'I'm using physical engineering methods to solve social engineering problems.'" (p. 108)
  • Chapter 6: electricity: "I counted no fewer than 15 electrical wires running up and down my street, not counting telephone and cable TV wires or the guy wires holding up the poles themselves."
  • Chapter 7: garbage: "Landfill entombment raises the prospect of perplexed future archaeologists, who will wonder why we took such enormous care to make sure our trash lasted for, basically, geologic time." (p. 161)
  • Chapter 8: telecommunications: "The complete contents of the Library of Congress would take just under 2 minutes to transmit on a 100 G fiber." (p. 184)
  • Chapter 9: transportation: "With its meandering, car-centered development, Raleigh offers an object lesson for how to discourage transit use." (p. 196)

You get the idea.

This is an important book, one that I would recommend very broadly. It's certainly a great acquisition for any academic library as well as any public library in any sized community. As far as school libraries go, this would be a fine purchase for any high school or even middle school library.

As well:

  • This would be a great "What is engineering really all about?" book for an Engineering 1000 course or any kind of capstone design course. It gives a sense of what engineers really do and the interconnectedness of that work.
  • I'd also recommend this as a book to send to any short-sighted, tax-cutting, worker-bashing politician you happen to know. You might also have a family member or friend who's in that camp as well -- this would make a great gift idea.
  • The book would also make a great "One campus, one book," again since it shows the interconnectedness of so much that we take for granted.

Huler, Scott. On the Grid: A Plot of Land, An Average Neighborhood, and the Systems that Make Our World Work. New York: Rodale, 2011. 248pp. ISBN-13: 978-1605296470

(Book provided by the publisher via Science Online 2011.)

No responses yet

Issues in Science & Technology Librarianship, Winter 2011

As usual, a bunch of great new articles from the most recent ISTL!

No responses yet

Interview with the gang at EngineerBlogs.org

Welcome to the long-awaited latest instalment in my occasional series of interviews with people in the library, publishing and scitech worlds. This time around the subjects of my first group interview are the gang at EngineerBlogs.org.

From my welcome-to-the-blogosphere post, here's a condensed bit about them:

  • Cherish The Scientist (EB)

    I am an electrical engineer with an interest in various areas of electromagnetics, including antennas and numerical simulation techniques, as well as IC packaging. I have completed a master's degree in electrical engineering and am currently pursuing a doctorate in geophysics.

  • Chris Gammell's Analog Life

    My name is Chris Gammell and I am an analog electrical engineer from Cleveland, OH. Though I grew up in Buffalo, NY, I first came to Cleveland in late 2001; I earned my bachelor's degree in electrical engineering from Case Western Reserve...This site is dedicated to teaching those who are new to the industry and continuing the conversation with those who work alongside me industry.

  • Flying Flux (EB)

    Who is Fluxor? I'm a worker bee located in the nation's capital, the nation in question being Canada, and employed at FluxCorp for the purposes of building a Flying Flux. And what is a Flying Flux? It's a mixture of analog and digital integrated circuitry designed for mass consumption, although I focus mainly on the analog side.

    So that's what I am -- an analog IC circuit designer ...

  • Design. Build. Play. (EB)

    Just another engineer, formerly of the humanities discipline, writing about cars, aerospace, economics, coffee, design, school and exciting workplace adventures at MegaCorp.

Enjoy!

===============

Q0. First of all, tell me a little about yourself/yourselves -- who you are and how you ended up where you all are, career & blogging-wise.

Cherish. I did my undergrad in physics and masters in electrical engineering, both at NDSU. Currently, I am a PhD candidate in geophysics at University of Minnesota. However, after I finished my coursework, I chose to go back to NDSU and work part-time as a research engineer while working on my dissertation. I started blogging while doing my MS, primarily as a means to keep in touch with friends and family. A couple years later, I found the science blogging community (primarily Science Blogs) and realized there was a lot more to it. I like to write up posts about science, technology, and education, but it's still primarily a place to talk about whatever is on my mind.

FrauTech. This is a second career for me. I went into Mechanical Design because CAD is something I really enjoy and my experience in industry led me to believe this was a discipline I wanted to pursue. So I went back to school for Mechanical Engineering and that was that. I started blogging because I had all these grand plans of things I wanted to build and showcase on a blog. I ended up being too busy between work and school to dig into these as much as I wanted and the blogging instead became a really great outlet for my frustrations, other school related projects, and a way for me to have a conversation about research and industry developments in my field.

Chris Gammell. I still feel like a student on many days of the week. I've only been in industry for 5 years, 3 of those in my current field (which was completely different from the previous field). But once I got into the field and began realizing the potential for analog (and EEs in general) in the blogging space, I jumped in to try and educate people.

Fluxor.. I'm Fluxor, the builder of the Flying Flux at FluxCorp. Someday, I'll get myself some superhero tights to match my superhero monicker. Until then, I'm just an EE that's been working close to a decade and half in analog chip design, having specialized in that area in my master's. My first blog post on flyingflux.com tells why I started blogging.

The impetus was a fairly major layoff at FluxCorp in Jan 2009 which made me go through a quick period of introspection, during which I started blogging and haven't stopped since.

Q1. How did you decide to start up EngineerBlogs.org? Were you inspired by the turmoils in the science blogging world over the last year or so, starting with Pepsigate and continuing with the mushroom-like sprouting of a whole bunch of new independent and commercial networks?

Cherish. I suggested the idea to Chris, who had tried starting an EE blogging community a couple years ago. The four of us who started EB were already actively reading and discussing each other's blogs, so I thought it would be fun to do something as a group. I was particularly hoping that it would make it easier to find blogs related to engineering.

I think that while many of us knew about Pepsi-gate, that didn't really play into our decision to start the group. Aside from the fact that it's hard to find engineering bloggers, it's also easy to get lost as a blogger with the millions of blogs that are already out there. As a
reader, it's difficult to avoid information overload. People may not find or visit our individual blogs, but I think we're making an effort to do some of our best, most relevant writing for EB, which is providing us with a good reader base. I think we all would like for our writing to be useful and interesting to people, and EB seems to be helping make some of our writing on engineering and engineering culture more visible.

Chris Gammell. I have absolutely no idea what Pepsigate is...so no, I wasn't inspired by it. I jumped at the chance as Cherish says because I HATE when people sit around talking about starting a website. It's so easy these days and it's better to start a site first and ask questions later. I like ScienceBlogs but I prefer reading about engineering type issues. And most of all, I have had a hard time finding other engineering blogs...so when I found a group, I latched on!

Fluxor. What Cherish said. Plus, I love being elitist. And I love Americans. So when they asked me to become part of this exclusive club, how can I refuse?

Q2. You have kind of a unique model, both aggregating existing blogs and getting
your bloggers to add content directly to the site. Could you explain what that's all about and what the rationale was for doing it that way?

Cherish. We talked this over a bit. All of us are pretty happy with our individual blogs and feel we've invested a lot of time and effort into them. Most of us write very regularly (and Chris has his radio show, The Amp Hour, along with other projects), so we were reluctant to try to fit all of our writing into some sort of formal engineering group context. We considered making EB a blog aggregator but felt it would be of more interest to offer some original content instead. The decision was that each of us would commit to providing a certain amount of content or support to EB. This allows us to contribute without a bunch of pressure to produce content and allows us to use our own blogs for whatever we want. Personally, I don't think I'd enjoy writing about engineering all the time. If I were to move my blog to EB, I would feel a lot of pressure to do that, and I think that would take a lot of the fun out of blogging.

FrauTech. I agree with Cherish, I enjoy blogging about engineering but I like having a blog where I can talk about my cat or whatever else. So I think our personal blogs are pictures of us as whole people and engineer blogs just filters that down to who we are as engineers for readers who are looking for that key ingredient.

Chris Gammell. I listened to the others.

Fluxor. We don't really aggregate posts in real time. We do repost our favourite posts from the past once-in-a-while. But there's a limited supply of those posts.

Q3. Blogging has really taken off in the science world but somehow not so much among engineers. What do you think the reason is for that?

Cherish
. Personally, I think scientists want to talk about their interests, and for many of them, their chosen outlet is blogging. It allows them to discuss their interests in depth, sometimes getting into the subtleties and nuances of their field, talking about what they've learned. Engineers who are really interested in their field tend to do things like participate in HAM radio or similar groups. There are a lot of very active discussion boards where people are swapping ideas, but I think engineers would rather be building things rather than talking about building them.

FrauTech. I think also most science bloggers work in academia or in science journalism and so have free reign to discuss their work specifically and either a secure academic or government funded job to where they don't have to worry about what they say online putting them out of a job. If an engineer is working in private industry he or she doesn't have the same flexibility and might be able to talk about hobbies but anything remotely like what they work on at the job could be seen as harmful or violating proprietary regulations. I think this kind of business atmosphere extends even to engineers working in academia with just a general tendency to be more secretive, careful and private.

Chris Gammell. I think the academic environment that most scientists work in really has a beneficial effect on the blogging community. Engineers obviously battle stigma and stereotypical lack of writing skills. More recently the spectrum of engineering disciplines has popped out a few engineers who enjoy writing and we're hoping to meet them all!

Fluxor. *shrug*

Q4. Related to that I guess, why do you blog?

Cherish. Personally, I blog to talk about things that I find interesting and to meet other people who share those interests. It's both an outlet and way of socializing.

FrauTech. I enjoy reading STEM related blogs and feel like having my own blog is like being a part of a larger community of like minded people who care about a lot of the same things I care about. It's also a way for me to keep working on my writing as well as force myself to keep learning new things. A blog writer to be effective I think has to be able to change and grow with time and writing about engineering helps me realize what topics I'd like to learn more about or where I can grow and improve as an engineer in a way my job is too narrow to make obvious. I think in the end it will make me a better engineer.

Chris Gammell. I blog for personal development, not monetary. Pushing myself into situations such as writing, especially about topics that I'm not completely familiar with, really forces me to learn about subjects enough to not sound like an idiot. I like the connection, especially given my former statement about feeling like a student...whereas
engineering in school is very social, engineering in the workplace is less so. I think writing and interacting with others online really helps keep connected and meet new people.

Fluxor. It's an outlet. And getting to know other bloggers online has made it more rewarding. Plus, I once entered a writing contest on a whim and won. Even got to read it on CBC radio 1. That was a surprise because I really hated English in high school and barely passed the English proficiency essay requirement in undergrad. My perception of my own writing abilities took a turn for the better after that event.

Q5. Is there a difference between science and engineering blogs?

Cherish. There can be. I think that those of us blogging at EB tend to be more like science blogs: we have a lot of interests and cover different ground. A lot of other engineering blogs I've come across, however, tend to be sponsored by magazines and focus on things like tech trends and offering information on specific technologies or advice for certain fields.

Fluxor. Don't read enough science blogs to know.

Q6. You have a good balance of bloggers so far, men vs. women, Canadians vs. Americans, different career stages. Was that planned or did it just happen?

Cherish. We're even somewhat diverse racially. The diversity just happened, but probably this is due to the fact that we started reading each others blogs because we like getting perspectives that are different than our own. We've discussed how we'd like to preserve this aspect of the group, although we've acknowledged that it's already hard to find engineering bloggers, so we're not sure how feasible that will be.

Fluxor. Serendipity. And I would drop the plural on "Canadians".

Q7. What are your plans for the future?

Cherish. We would really like to add a few more bloggers. Primarily, we feel like we're too heavy on electrical engineering and would like to find established bloggers who might be in other fields like mechanical, chemical, civil, or industrial engineering. We're playing around with ideas like themes and wondering what we can do as a community that we might not be able to do as individual bloggers.

Fluxor. Cherish said it all.

No responses yet

CEEA 2011 Conference: The Evolution of Engineering Education

Feb 05 2011 Published by under culture of science, engineering, faculty liaison

I got an email the other day announcing the 2011 Canadian Engineering Education Association Annual Conference. It'll be held from June 6 to 8, 2011, at Memorial University in St. John's, Newfoundland & Labrador.

The conference page is here and the call for papers is here.

The call for papers:

The Canadian Engineering Education Association (CEEA) is an organization whose mission is to "enhance the competence and relevance of graduates from Canadian engineering schools through continuous improvement in engineering education and design education." This second annual CEEA conference continues to build on the previous efforts of the Canadian Design Engineering Network (CDEN) and the Canadian Congress on Engineering Education (C2E2). We strongly encourage the broad community of engineering educators to join us - from faculties of engineering and applied science, arts, science, education to libraries, teaching and learning centres and industry. Relevant student papers are also welcomed.

Authors are invited to submit ~300-word abstracts on a broad range of topics relevant to the theme, "The Evolution of Engineering Education." Topics may include:

  • Design for Innovation
  • Curriculum Creation or Enhancement
  • Innovative Teaching Methods
  • Information Research and Management
  • Professional Development for Instructors
  • Accreditation/Outcomes Assessment
  • Engineering and Society
  • Global Engineering
  • Engineering Education Research
  • Capstone and Multidisciplinary Design
  • Academic/Industry Partnerships
  • Service Learning
  • Professional Skills Development
  • K-12 Outreach
  • Integrating Design in the Curriculum
  • Bringing Research to the Classroom
  • Lifelong Learning
  • Design and Innovation Methodology
  • Engineering and the Environment

Upon peer review and acceptance of abstract, authors may choose to submit a full conference paper (six pages) or a one-page condensed paper. Condensed papers will be published in the proceedings as conference presentations.

Schedule of Submissions:

March 4, 2011:300-word abstracts submitted for review
April 1, 2011: Authors notified regarding acceptance
May 6, 2010: Final papers/condensed papers due

For further information, please e-mail ceea2011@mun.ca.

I was at the 2010 conference in Kingston and it was a terrific conference with my presentation on blogging here and conference recap here.

One response so far

Welcome to EngineerBlogs.org!!!!

YASBC. But this time an engineering blog community. This is a fantastic new development if you ask me, especially in a blogging environment domininated by science blogs. Time to let the engineers into the clubhouse, even if that means that we'll have to start serving massive quantities of various beverages to keep them all happy.

Let them explain:

This is a collection of some of the top engineering bloggers on the internet. Surprisingly, scientists seem to outnumber engineers, though we don't think that will happen for long. Some posts link directly back to the author's web page and some stay right here on EngineerBlogs.org. Either way, we promise you some of the best engineering related content on the web. Tune in to our feed to get the newest information from all authors.

As they say, they have a collection of bloggers that both write on the their own personal blog sites as well as on the Engineer Blogs site. There also seems to be some re-posting going on too. An interesting model, to say the least.

There are only four blogs to start. I'll link first to the blogger's individual site then to their Engineer Blogs page, where available:

  • Cherish The Scientist (EB)

    I am an electrical engineer with an interest in various areas of electromagnetics, including antennas and numerical simulation techniques, as well as IC packaging. I have completed a master's degree in electrical engineering and am currently pursuing a doctorate in geophysics.

  • Chris Gammell's Analog Life

    My name is Chris Gammell and I am an analog electrical engineer from Cleveland, OH. Though I grew up in Buffalo, NY, I first came to Cleveland in late 2001; I earned my bachelor's degree in electrical engineering from Case Western Reserve. Since I started working I have contributed to many different industries and picked up knowledge along the way. I'm very thankful for the fact that I am able to work on advanced electronics every day. I want this site to help others understand electronics and the electronics industry better. This site is dedicated to teaching those who are new to the industry and continuing the conversation with those who work alongside me industry.

  • Flying Flux (EB)

    Who is Fluxor? I'm a worker bee located in the nation's capital, the nation in question being Canada, and employed at FluxCorp for the purposes of building a Flying Flux. And what is a Flying Flux? It's a mixture of analog and digital integrated circuitry designed for mass consumption, although I focus mainly on the analog side.

    So that's what I am -- an analog IC circuit designer . That's what I've been doing since grad school. I've done designs ranging from DC (regulators, bandgaps), to multi-GHz RF (mixers, VCOs, LNAs), to multi-GHZ high speed analog (CDRs, PLLs), to behavioural modeling of components and systems. I've also managed projects where team members were spread across four countries and five time zones.

    Some day, I hope to be seconded to a land far, far away, with all the trappings of an ex-pat living lavishly in a foreign land. And in that land, preferably China, I hope to lead a local design office doing, what else, analog IC design.

  • Design. Build. Play. (EB)

    Just another engineer, formerly of the humanities discipline, writing about cars, aerospace, economics, coffee, design, school and exciting workplace adventures at MegaCorp.

(via)

One response so far

From the Archives: Dreaming in Code by Scott Rosenberg

I have a whole pile of science-y book reviews on two of my older blogs, here and here. Both of those blogs have now been largely superseded by or merged into this one. So I'm going to be slowly moving the relevant reviews over here. I'll mostly be doing the posts one or two per weekend and I'll occasionally be merging two or more shorter reviews into one post here.

This one, of Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software, is from August 9, 2007.

=======

Every organization relies on software these days. Big custom systems, shrink wrapped commercial software, all the various protocols and programs keeping the Net running. Big organizations, small organizations, tech companies of course, libraries in particular are relying on the fruits of software developers mental labours more and more. And with the rise of Web 2.0 in libraries and educational institutions, our reliance on our programmers will only get more pronounced. But how much do we really understand about the art of software development and the strange and wonderful habits of programmers, systems analysts and all the rest of the software bestiary?

Not much, it seems. And that's where this fascinating insider account a a high-profile open source software project comes in. Salon.com co-founder and author Scott Rosenberg spent three years as a fly on the way on Mitch Kapor's project to create the ultimate Personal Information Manager (PIM), Chandler. Kapor's project was highly idealistic from the very beginning; the idea was that he would use some of his software-boom fortune to finance a project to make every one's lives easier: a PIM that is flexible, sharable and open, able to handle calendaring, email, note taking and events. Unfortunately, the project was also cursed with design difficulties and numerous delays, with a schedule that stretched out from one year to two and three years and beyond (and not even implemented today). The book includes a colourful cast of both obscure and well-known software luminaries (like Andy Hertzfeld), and goes beyond merely recounting the ups and downs of Chandler but also offers a kind of history of attempts to organize and systematize software development. Name-checking such great software engineering writers as Frederick Brooks, Rosenberg talks about the whys and wherefores of structured programming, object orientation and others. Many chapters mix details of the vagaries of the Chandler project with relevant discussions of theoretical topics in software engineering (such as trying to create truly reusable software modules) with more philosophical musings on the art of software development. Most of all, Rosenberg places us firmly inside the workings of a programming project from hell, complete with gory details, tales from the historical trenches and a bit of that fantastic theoretical discussion on why software is so hard. (So, what's it really like being stuck in the programming project from hell? Trust me, I've been there and this is a pretty good example of the real thing.)

There are a couple of really good bits that really stood out for me in this book, bits that resonated with my own experiences managing and developing software. On page 54 he has a discussion of death march projects and the optimism/pessimism dichotomy that all programmers live with and obsess with every day. Having done a couple of death marches characterized by such extremes, it really resonated with me. On page 75, he begins a discussion various programming languages and the almost religious zeal most programmers have for their favourite ones - I was a big fan of Fortran as a young programmer. On page 274, Rosenberg has a telling comment about programmers' historical blindness, their inability to learn from their mistakes, to use the literature to learn from other's mistakes. I like the way he puts it: "It's tempting to recommend these [pioneering software engineering] NATO reports be required reading for all programmers and their managers. But, as Joel Spolsky says, most programmers don't read much about their own discipline. That leaves them trapped in infinite loops of self-ignorance." I like to think that as a librarian collecting the literature of software engineering, I can help in a small way to make programmers more aware of their past.

On a lighter note, I also like the joke that Rosenberg puts on page 275-276:

A Software Engineer, a Hardware Engineer, and a Departmental Manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers until it miraculously ground to a halt scraping along the mountainside. The car's occupants, shaken but unhurt, now had a problem: They were stuck halfway down a mountain in a car with no brakes. What were they to do?

"I know," said the Departmental Manager. "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals, and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

"No, no," said the Hardware Engineer. "that will take far too long, and, besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it, and we can be on our way."

"Well," said the Software Engineer, "before we do anything, I think we should push the car back up the road and see if it happens again."

I'm going to use this joke when I do IL sessions for CS and Engineering grad and undergrad students, and maybe even to break the ice at a departmental meeting.

A great book, an insider view of software development, a real insight into how programmers think and work and how software projects grow and evolve, sometimes how they careen out of control. So, who would I recommend this book for? A number of different constituencies would find this book useful and entertaining.

  • IT Managers would find this book very useful for its insights into the personalities of programmers as well as for its history of failed attempts to make a purely predictable engineering discipline out of programming.
  • Programmers would find this book terrific, seeing a lot of their own eccentricities in the many stories. As well, programmers would get a lot of insights into their pointy-haired bosses attempts to turn them into engineers rather than the free-spirited hacker-artists they see themselves as.
  • Families of the either of the two above groups will get valuable insight into the slightly deranged members of their families, their joys, obsessions and frustrations.
  • People that support or employ software developers or managers, such as scitech librarians, HR people in tech firms, venture capitalists in software firms. They will hopefully come to understand how and why software projects are created and sometimes crash and burn. Not to mention how to mentor and encourage developers to take advantage of what is known to improve productivity. The other books and articles listed in the notes are also a treasure trove of further exploration and information. I hate it when books like this don't have a proper bibliography - it makes it a lot more trouble to sift through the notes later on for further reading.
  • And really, anybody that uses software of any kind. And since basically everyone uses some sort of software these days, just about anyone would really appreciate this book. Understanding how the knowledge economy and the Internet boom is built from the ground up is certainly enlightening and important. You'll never see a bank machine, interact with a big company's insane internal systems procedures or even use a simple web application the same way. Understanding the challenges involved in getting these systems even close to right and the inevitability of their imperfections is an important revelation in the modern world.

Rosenberg, Scott. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. New York: Crown, 2007. 400pp. ISBN-13: 978-1400082476

4 responses so far

Friday Fun: Top 50 Programming Quotes of All Time

Ok, this is just plain hysterical. And insightful. And both insightfully hysterical and hysterically insightful.

Enjoy.

Here's a taste, read the whole thing for yourself.

50. "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning."
- Rick Cook

38. "The use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal offense."
- E.W. Dijkstra

17. "If McDonalds were run like a software company, one out of every hundred Big Macs would give you food poisoning, and the response would be, 'We're sorry, here's a coupon for two more.' "
- Mark Minasi

6. "The trouble with programmers is that you can never tell what a programmer is doing until it's too late."
- Seymour Cray

3 responses so far

From the Archives: Countdown: A history of space flight by T.A. Heppenheimer

Dec 18 2010 Published by under book review, engineering, history, science books

I have a whole pile of science-y book reviews on two of my older blogs, here and here. Both of those blogs have now been largely superseded by or merged into this one. So I'm going to be slowly moving the relevant reviews over here. I'll mostly be doing the posts one or two per weekend and I'll occasionally be merging two or more shorter reviews into one post here.

This one, of Countdown: A History of Space Flight, is from November 14, 2006.

=======

The decision to read this book was certainly not rocket science, even if it is a book about rocket science. An engaging and fascinating read, you don't have to be a brain surgeon to understand it either, as it concerns itself as much with the human challenges in the history of space flight as with the purely engineering ones.

Since this book was published in 1997, it obviously doesn't cover any of the more recent missions from the last ten years or so, but I didn't really find that to be much of a problem, as what I was really looking for was information about the early years of rocketry, and this book covers those quite well, including the programs in Germany, Russia and the USA.

I really appreciated the focus on the early careers of Wernher von Braun in Germany and, in particular, Sergei Korolev of Russia, whose name was unfamiliar to me before. The hardships of the Russian engineers and other workers who were forced to work in incredibly bad conditions for Stalin were something that was also a revelation. Von Braun's story was also fascinating, perhaps the only flaw in the book's coverage is that I would liked to have learned more about the program under Nazi Germany. Von Braun was very likely an unacknowledged war criminal, and this was underplayed.

The great strides of the Soviet program in the 1950s is also well covered, including the determination by the Americans to ultimately overtake the Soviet program, which they did by the 1960s. The stories of the machinations of the US Army, Air Force and Navy and their jockeying for position and influence was very well presented. The seamless integration of the military and industry is also quite apparent, leading the Eisenhower's famous comment about watching out for the military industrial complex. Well, it's all here, laid out in the history of the space program. The main developments in ICBMs, spy planes, spy satellites, high altitude bombers are all covered.

In some ways, the most exciting part of the book is the chapters leading up to the dramatic Apollo moon landing, contrasting with the Soviet program's declining success at that time. The chapters following the moon landing could have been anti-climactic. However, I found the history of the various unmanned, exploratory missions very interesting; Heppenheimer is definitely a proponent of unmanned exploration versus the political showmanship of dangerous and expensive manned missions. This part of the book, leading up to the Challenger disaster, was very critical of the American decision to put all it's eggs in the shuttle basket and showed how the Europeans were able to capitalize on that and how even the Soviet/Russian program was able to make many positive strides.

The book ends on a positive note, hoping for a renewed international space program based on international co-operation. We're not quite there yet, but this book certainly gives the background necessary to understand where we are and how we got here.

Heppenheimer, T. A. Countdown: A History of Space Flight New York: Wiley, 1997. 398pp.

No responses yet

From the Grace Hopper Celebration of Women in Computing

This year's Grace Hopper Celebration of Women in Computing took place this past week in Atlanta, GA.

I thought I'd gather together some small part of the blog posts I've been seeing floating around the Internets on this wonderful event.

Most of the blogs I link to have made multiple posts about the GHC -- poke around and check those out too.

The conference is on Twitter here and this year's hashtag is #ghc10 and the conference blog aggregation page is here.

It's definitely a conference I'd love to get to one of these days!

If I've missed any good posts, please leave the links in the comments.

No responses yet

Friday Fun: Epic failures: 11 infamous software bugs

Sep 17 2010 Published by under engineering, friday fun

Having started my working life as a software developer, I know a bit about epic bugs. Let's just say I've had my share and leave it at that. At very least, I can say I never caused any vehicles to crash or any companies to fail.

So, from ComputerWorld, Epic failures: 11 infamous software bugs.

Instead, this story is about outright programming errors that caused key failures in their own right.

Have I missed anything important? Consider this a call for nominations for the biggest bugs of all time. These are my suggestions; if you have any honorable mentions, bring 'em on. The worst anyone can do is swat them.

The list includes:

  • The Mars Climate Orbiter doesn't orbit
  • Mariner 1's five-minute flight
  • Forty seconds of Ariane-5
  • Pentium chips fail math
  • Call waiting ... and waiting ... and waiting
  • Windows Genuine Disadvantage
  • Patriot missile mistiming
  • Therac-25 Medical Accelerator disaster
  • Multidata Systems/Cobalt-60 overdoses
  • Osprey aircraft crash
  • End-of-the-world bugs

Here's one with details:

Pentium chips fail math

In 1994, an entire line of CPUs by market leader Intel simply couldn't do their math. The Pentium floating-point flaw ensured that no matter what software you used, your results stood a chance of being inaccurate past the eighth decimal point. The problem lay in a faulty math coprocessor, also known as a floating-point unit. The result was a small possibility of tiny errors in hardcore calculations, but it was a costly PR debacle for Intel.

How did the first generation of Pentiums go wrong? Intel's laudable idea was to triple the execution speed of floating-point calculations by ditching the previous-generation 486 processor's clunky shift-and-subtract algorithm and substituting a lookup-table approach in the Pentium. So far, so smart. The lookup table consisted of 1,066 table entries, downloaded into the programmable logic array of the chip. But only 1,061 entries made it onto the first-generation Pentiums; five got lost on the way.

When the floating-point unit accessed any of the empty cells, it would get a zero response instead of the real answer. A zero response from one cell didn't actually return an answer of zero: A few obscure calculations returned slight errors typically around the tenth decimal digit, so the error passed by quality control and into production.

What did that mean for the lay user? Not much. With this kind of bug, there's a 1-in-360 billion chance that miscalculations could reach as high as the fourth decimal place. More likely, with odds of 1-to-9 billion against, was that any errors would happen in the 9th or 10th decimal digit.

5 responses so far

« Newer posts Older posts »