“Exemplars provide safe models for new designs”

 It was interesting reading “The Design of Design: Essays from a Computer Scientist” by Frederick Brooks after having recently read “The Last Place on Earth” by Roland Huntford.  Captain Robert Falcon Scott tried to design new contraptions and use technology to help him get to the South Pole first.  However, his designs failed time after time.  The reason his designs failed was the same reason Mr. Brook’s highlights in his book; Captain Scott did not thoroughly understand the Exemplars of his day.

“Exemplars provide safe models for new designs, implicit checklists of design task, warnings of potential mistakes, and launching pads for radical new designs. Hence great designers have invested great efforts in studying their precedents… Jefferson carefully studied not only Palladio‘s books, but the buildings around him in Paris… Bach took a six-month unpaid leave from his job and walked 250 miles to study the work and ideas of Buxtehude… Bach proved to be a much greater composer than Buxtehude, but his surpassing excellence came from comprehending and using the techniques of his predecessors,not ignoring them.”

Whether it was hubris or something else, who knows?  But if Captain Scott had intensely studied the exemplars of his day and the tools of previous Antarctic expeditions like Amundsen did, rather than recklessly designing useless contraptions, he would have likely arrived at the South Pole first and made it back to England alive.

So what does this have to do with information technology?  Well, before trying to design new, wild, innovative technology solutions, first study and understand the advantages and disadvantages of existing works.  That is one of the advantages of today’s open source movement, it allows us to thoroughly research exemplars and frequently use what we learn to build solid frameworks for future innovation.

Related Posts

What if Antarctic explorers were system administrators

Thoughts on “The Design of Design: Essays from a Computer Scientist”, by Frederick Brooks

I recently finished reading “The Design of Design: Essays from a Computer Scientist”,  by Frederick Brooks

Yes, it is the same Frederick Brooks who wrote “The Mythical Man-Month: Essays on Software Engineering” and same Frederick Brooks who was the design architect behind the IBM System/360, reference I.B.M.’s $5,000,000,000 Gamble.

It begins by analyzing various design theories:

• Decision Tree
• Herbert Simon – Decision Making and Problem Solving
• Verein Deutscher Ingenieure – Rational Planning Model
• Winston W. Royce – Waterfall Model
• Pahl & Beitz Method
• Barry Boehm – Spiral Model
• Co-Evolutionary Methods in System Design and Analysis

One interesting observation that Mr. Brooks points out over and over throughout the entire book is that most great inventions have had only one or two chief architects, they were not designed by a committee.

Thinking back through the many projects I have been involved in or witnessed, this observation certainly rings true. Those projects that were compartmentalized with various specialities glued together by a business manager rather than a chief designer/architect had a higher rate of failure. I have observed brilliant ideas ignored because business managers lacking technical expertise weighed the merit of ideas on individual reputations rather than the value of the ideas themselves. A good chief designer/architect can see through this and has the vision and technical expertise to capitalize on new ideas that might otherwise be discarded or dismissed by traditional business/project managers.

I have read some material outside the book where Mr. Brook’s observation is challenged, claims have been made that design teams are often successful on a regular basis. After reading the entire book, I don’t honestly believe Mr. Brooks is suggesting that design teams can’t be successful. He is merely stating that without a chief technical designer/architect free from company procedures, corporate meetings, politics and tampering by business & process managers, the chance of project failure is higher. A chief designer/architect needs to be equally respected and set aside as a separate position from the business/project manager.  One position without the other doesn’t usually work well, one position with more power than the other usually doesn’t work well, nor does it usually work well when both duties are combined into one position. He also states that design by committee creates unnecessary delays & encourages compromises resulting in sacrifices to overall design integrity and project ingenuity. I think these are all very fair observations and there are many more great observations throughout the book, I highly recommend reading it.

I.T. Department Management Tools

The following is a list of essential tools for running efficent, highly effective I.T. departments.  Most of these tools apply to both medium and large business:

http://bit.ly/9jXSTs

How do you ensure your IT departments have all of these tools available without breaking the bank or eating your project resources alive?  In an upcoming series of posts I will cover possible avenues, drill-down, and share first-hand experiences.

Do you have ideas for other useful IT department management tools?   I’d be interested in hearing ideas and experiences in providing highly effective IT department tools without heavily impacting project schedules.