The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
5 Things Grady Booch Has Learned About Complex Software

6 replies on 1 page. Most recent reply: Jun 14, 2008 8:49 AM by John Zabroski

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 6 replies on 1 page
esther schindler

Posts: 14
Nickname: eschindler
Registered: Jun, 2006

5 Things Grady Booch Has Learned About Complex Software Posted: Jun 5, 2008 2:37 PM
Reply to this message Reply
Advertisement

Few of the points Grady Booch makes in this CIO.com article will surprise most developers; if they did, they wouldn't be fundamentals. But it's nice to see that this message, as just one example, is being communicated to developers and management alike:

Don't underestimate the importance of keeping things simple, he warns—or the difficulty of getting there. "It requires energy to develop simple things," explains Booch. It's worth the investment to ensure that every software release includes a step in which developers give attention to simplifying, he says. But it is an investment. Management has to be willing to throw out features even if it cost money to develop them.

The five lessons learned?

  1. The fundamentals never go out of style.
  2. You need a regular rhythm of releases.
  3. Focus upon growing executable architectures.
  4. Create social structures that encourage innovation while still preserving predictability.
  5. Have fun.

Naturally, it's the explanations that are interesting and entertaining.

What do you think of Booch's comments in the article?


Antonio Cavallo

Posts: 10
Nickname: cavallo71
Registered: Mar, 2006

Re: 5 Things Grady Booch Has Learned About Complex Software Posted: Jun 7, 2008 2:09 AM
Reply to this message Reply
I (not strongly) disagree with the need to
"keep the member of the team out of the blasted meetings".

On one hand it certainly help to get the things done
but in the other hand it helps to better understand
the customers' needs.

I think the term "have fun" is not the best:
I'd suggest something along the line
"have a pride in what you do" would be better.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

a small addition maybe... Posted: Jun 7, 2008 2:26 PM
Reply to this message Reply
The fundamentals (section 1) lacks one thing perhaps --

Make a priority of import-reuse, that is: design concepts should be taken ready-made from elsewhere as much as possible.

Complementary to that, the remaining novel design should be thoroughly ad hoc -- with no effort to generalise it. (That, however, is more a corollary than a fundamental.)

In a sentence: Design should reuse (as in adopt) generality, but create the particular.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: a small addition maybe... Posted: Jun 9, 2008 7:58 AM
Reply to this message Reply
> In a sentence: Design should reuse (as in adopt)
> generality, but create the particular.

I agree completely and I like this sentence as a bullet point. You'd probably need more to really get the full meaning across but it's a good starting point.

To listen to some people, there's nothing that some one hasn't already done before. I can't mention an idea or something I built on my own without someone questioning whether I tried X or Y and why I would even do something like that. Often X or Y don't solve the problem or even address the same issues but there's 'always' something else out there that does whatever it is I wanted to do, even if it can't be named. Just keep looking, I'm told.

I've worked with a number of people that believe that you should never write your own API, even if it's a just thin layer over reuse. The theory is to just use the tools or libraries and not "write code". But in reality, you have to write code to use the tool or library and by not using the abstractions, you end up with a lot more code and a lot of repetition. You also end up tied to what you reused in a way that changing that (or upgrading) becomes cost prohibitive.

I digress a bit here but I think these issues are rooted in the misapplication of the reuse principle instead of the more correct understanding you demonstrate above.

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: 5 Things Grady Booch Has Learned About Complex Software Posted: Jun 9, 2008 3:20 PM
Reply to this message Reply
I think object-oriented design is better than procedural programming, because the scope of the variables is reduced from global to class-level.

If you take this further and reduce the scope of the variables to the function level, then you get functional programming, which is even better than object-oriented, in my opinion. And in functional programming you focus precisely on processes rather than things. Focusing on things leads to programming with side effects. Focusing on processes leads to programming without side effects.

I think functional style should be the default style for programming. Then a programmer should drop out of functional and into OO if it's more expedient for some reason to rely on side effects.

I agree with the rest of Grady's points. I especially agree with #5 and I wouldn't change any wording in it either. Programming should be both fun and a joy. If something is fun, it is natural to learn more about it and to excel in it. It's hard to excel in something rote or boring. When programming is fun there is no feeling of overcoming resistance. The code and ideas just magically and effortlessly appear. When programming is not fun, every line of code is coming up against an immense emotional resistance, and the process becomes slow torture.

Children, as well as adults, learn best while at play. And it is essential for programmers to be constantly learning. Naturally it makes sense to appreciate programming as a type of a play. Taking what you do less seriously allows you to have a broader perspective. If coding is serious business and is not a fun game anymore, then it's very easy to become political due to strong attachments to various pieces of code and/or design. Keeping programming fun allows just enough interest to be productive, but not so much interest that one becomes mentally and emotionally entrenched and inflexible.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: 5 Things Grady Booch Has Learned About Complex Software Posted: Jun 9, 2008 6:43 PM
Reply to this message Reply
> 5 Things Grady Booch Has Learned About Complex Software

He's only 4 ahead of most of us ..

Peace,

Cameron Purdy | Oracle
http://www.oracle.com/technology/products/coherence/index.html

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: a small addition maybe... Posted: Jun 14, 2008 8:49 AM
Reply to this message Reply
> In a sentence: Design should reuse (as in adopt)
> generality, but create the particular.

What you are saying here is that component-oriented programming leads to Foundation Class Libraries that are so rich that you will never be able to use every class. In other words, components suffer from having fine-grained design. Building systems out of grains of sand is like lifting and shaping the whole desert to build a pyramid. In doing so, we're routinely revising the Seven Wonders of the Software World: For the most recent wonder, look no further than the United States government's Future Combat Systems' 63 million lines of code (13 million more than Windows Vista!), and their recent proclamation that they will achieve "Information Dominance". I'm only 24, but quick wisdom has taught me that you cannot compete by offering globules of sand. Like components, the grains of sand have to be re-used as-is, and so they are only latently re-usable.

Where I work, we're open about what we call "stick-built" software: software that has been tested for quality but ultimately brittle when things like entire business models change. Such software is usable, in the sense that we can sell it to customers conforming to specific tasks and processes. We realize the distinction between having to fine tune a product and having to re-tune a product. We're latently re-using the code in the sense we're selling the same product and changing (fine-tuning) a few resource strings and logos. However, we cannot mass produce it and sell it to a global economy with disparate business models, and therefore it is not re-usable. It does not have coarse-grained design.

Realistically, we have few project failures when we can deliberately re-use software and the waterfall model works great because we're skipping the design phase. For these projects, we're on time and and on budget. Deliberate re-use is all about figuring out a way to skip or shorten pre-implementation phases in the software development lifecycle. Most organizations do not target this sort of re-use, and are still aiming for latent re-use through component programming.

> > I digress a bit here but I think these issues
> > are rooted in the misapplication of the reuse
> > principle instead of the more correct
> > understanding you demonstrate above.

Use and re-use are fundamentally different. Use sustains known degrees of freedom in thinking about a problem. Re-use introduces new degrees of freedom. In doing so, re-use reduces complexity on one axis (more generality) while increasing complexity on an orthogonal axis (less definiteness).

Use, in the "stick-built" software sense, isn't bad, though. Some people like working on stick-built software with an eye toward making it re-usable. However, as an ISV, it is much harder to score a business contract with a company if you need to develop an internal greenfield project just to fulfill the contract. Such a project is a start-up venture, and as with all start-ups there is a high probability of failure.

Flat View: This topic has 6 replies on 1 page
Topic: 5 Things Grady Booch Has Learned About Complex Software Previous Topic   Next Topic Topic: Introduction to Adobe's BlazeDS

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use