A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I was given this link in the 'Holy Grail' thread. I found it amazing.
Several amazing things.
1. It was written by Grady Booch -- one of the prime architects of UML.
2. It seemed fitting to him to route his doorbell press THROUGH his PBX, THROUGH an application server, INTO his audio system, where a tone was generated.
3. He built in a memory leak (not on purpose, of course).
I think this illustrates either a great danger of software, or a great opportunity. The danger is, now a simple doorbell can be complexity-coupled to everything else in the house.
The opportunity is the same, actually. Once the doorbell IS successfully coupled into the house control system, the programmer has a choice of what to do with it.
And note the doorbell event DID help him troubleshoot his application server. So many lessons, so little time.
Friday, December 10, 2004
I think this illustrates a trap I still find myself falling into, despite the fact that I really should know better by now.
This is a common modeling trap. Grady abstracted events to the point where they were all routed through the same place. Bells rining are like phones ringing are like email arriving are like snmp traps from the cable router, right? They're all events, so let's abstract "event" and handle them all the same (we can subclass as needed to handle special events, of course). I'd bet he was a heartbeat away from hooking right into the electron bus (240V, anyone?).
Way too much complexity. Complexity decreases reliability. I give him a lot of credit for being able to poke fun at himself, though. Great article.
Friday, December 10, 2004
I've been to a couple of training sessions taught by Booch. He's a great BS'r, sells himself and his company constantly (as in this blog entry).
Friday, December 10, 2004
What a tosser Booch is. No wonder Rational's products are so crap.
Regular Poster Made Anonymous
Tuesday, December 14, 2004
I'm gonna be nit-picky about this:
Mother nature sets the amount of complexity in a problem (so to speak), and not programmers.
What we do in programming is *manage* that complexity.
If you will permit me a stereotype for a second: The above point is often overlooked by C programmers who refuse to learn other languages, claiming "I can do everything I need in C." Well, maybe you can. The important point is whether C manages the complexity well.
I have often suspected that Booch may be the other end of this scale...
Well said Jonathan! The inherent complexity of a solution is based on what it takes to solve the problem -- which is set by Mother Nature, I agree.
As developers, a major part of our job is to compartmentalize the complexity -- divide and conquer strategy. Thus, through assigning and defining a hierarchy of calling and called modules and data structures, we partition the complexity into something that can be coded (and verified) a simpler piece at a time.
However, Booch's method of rolling everything through a 'server' seems to me to maintain the 'ball-of-wax' model -- and in fact couple it even more than Mother Nature did.
Wednesday, December 15, 2004
> The inherent complexity of a solution is based
> on what it takes to solve the problem
The problem is figuring out the problem. And then dealing with all the problems that grow from all the problems.
Give the same problem to 10 people they will come up with 20 different answers. Propagate that through time and code and that's a problem.
I was an early believer in inherent complexity, but not anymore. At a certain point that comes quick, the degrees of freedom are just to great to maintain the illusion of inherentcy.
A plug for my favorite paper of all time:
Big Ball of Mud at http://www.laputan.org/mud/mud.html
son of parnas
Thursday, December 16, 2004
"I was an early believer in inherent complexity, but not anymore."
You are basically referring to the difficulties of fluctuating requirements, which I believe is tangential to the original discussion.
Requirement changes will affect anyone using any programming language. This isn't the fault of the language! Those languages that are more expressive will still manage the complexity better.
No Jonathan, a central tenet of Brook's Mythical Man-Month is that there is Complexity in software development.
He divided it into Inherent Complexity (that which exists because the problem is complicated, and the software solution is complicated) and Accidental Complexity (that which exists because a computer is not Real Life, and we must map our Real Life solution to the ways a computer and computer languages can express it.)
His point in the 'No Silver Bullet' essay is that even if we eliminate Accidental Complexity (with better languages, better platforms) there is enough Inherent Complexity to make building software systems difficult. You can't abstract it away.
Monday, December 20, 2004
Agreed, but it's definitely the case (IMHO) that we still, as programmers, overengineer the living hell of almost everything we touch in many, many cases.
My question to Grady is: what in God's name were you doing routing your doorbell through a $#@% application server?!? If it's just a toy, that's great, that's totally fun. But if it's just a toy, what's your article about, other than to tout Purify for the Nth time...and how does this relate to those of us who do real things, other than to say "gee, memory leaks are bad"?
This isn't intended as an assault on him personally -- just as invective against all those software systems that are implemented with three times as much code and a hundred times as much conceptual complexity as necessary. For example, it's hard to imagine a requirement for that doorbell that remotely necessitates all that complexity. Want it to email you? Want it to play a custom-selectable MP3 depending on time of day? Want it to page you? I can imagine solutions for all of those that involve about a tenth as much software. And those solutions will be vastly more reliable, easy to debug, and IMHO flexible, than the ones that are complex.
Tuesday, December 21, 2004
Why have it simple when one can make things infintely complicated?
Wednesday, December 22, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz