Architecture Analysis Design Bullshit

Architecture is the most overused word in software engineering today. Analysis and Design are close on its heels. Depending on whom you believe, it is

the same thing as design
the bare bones of design - what XP calls the SystemMetaphor
the tools and libraries used to build something - MS folk call DNA an architecture
a set of patterns from which design elements derive
a data model, sans behaviour
behavioural interfaces, sans data dependencies
a list of the application's processes and how they communicate
the packaging/layering/modularization of the main workproduct
the hardware, what processes run on what hardware, and how the hardware is connected
methodology, standards, process, and heaven help us a CMM
any combination of the above, and also the address of a good therapist

XP sets an excellent precedent by not talking about architecture, design or analysis, but talking about concrete activities with unique names appropriate only to themselves. If someone chooses to interpret an XP activity as architecture, or design, or analysis, or hog-calling, I think that person isn't doing XP - they're bullshitting. Is this activity like that activity? Frankly, so long as each activity is understood well enough for it to be conducted efficiently, it simply doesn't matter. It's just bullshit. -- PeterMerel

This is true and significant.

Abstraction is the (most) powerful tool programmers have. Language is the most powerful tool for understanding and communication. Both of these may be ignorable if you're building just another simplistic business application...

-- ThomasWhitmore

I like the idea, but setting a precedent? Bullshit ;-) People have been building programs without architectural design analysis forever, XP can't take credit for un-inventing silly things that other Methodologies came up with. -- LukeGorrie

I think the precedent isn't building software without architecture, but claiming that architecture is unnecessary or harmful to the process of building robust, extendable software.

The statement "I am a software architect", per ChiefProgrammerTeam, really means the same thing as the statement "I have a brain the size of a planet, and the only way my puny reality can absorb its prodigious output is to channel every scintilla of my awesome radiance into as many 'coders' as possible". -- PhlIp

(BTW, Pete, what was your former title at your day gig?)

My title is the same as it has ever been. Root Cause Of All Problems. Except to Phlip I'm Mister Root Cause Of All Problems. -- Pete

How does this chapter introduction from the new edition of Booch strike you:

: This chapter begins an in-depth case study of a simple weather monitoring system. Although this case study is fictitious, it has nevertheless been constructed with a high degree of realism. We will encounter the problems of time-pressure, legacy code, poor and mutating specifications, new untried technologies, etc. Our goal is to demonstrate how object oriented design and UML are used in the real world of software engineering.

The second sentence is my favourite :-). I downloaded this gem from the ObjectMentor website, it's "Walking through a UML design" by RobertCecilMartin and JimNewkirk, who're co-author with GradyBooch. SmalltalkLanguage veterans might like the "Language Selection" section, too.

To me, this reads like the worst kind of bullshit, and it comes from pretty close to the XP camp. -- LukeGorrie

Hrrrm, this struck me as pretty funny also :-) More an example of 'real world outcomes' than a quality design process.

http://www.objectmentor.com/resources/articles/Walking_through_A_UML_Design.pdf

My guess anyway is that this example was from the hand of RobertCecilMartin, rather than Booch; the link above is to RCM's site. Either way it's a poor example for anyone to learn from; not that other UML materials have been particularly illuminating as to real meaty areas.

Anyway, check the document out if you fancy a little quick critical analysis. The 'simulated' process & design does progress thru the course, so be sure to follow thru as the respectably-named but hard-coded task Scheduler turns into the frivolously-named and minimally-featured Alarm Clock Listener. Hey, I need one of those to help *me* wake up!

I guess my issues are with the so-called 'features' of their design. Many of the decisions as to abstraction or separation within the design seem just wrong. Incorrectly placed, unnecessary, or unlikely to help with reasonable evolving requirements for such a 'sensor & logging station' product.

However this is kind of interesting, as a concrete example of 'design style'.

... Another article at http://www.objectmentor.com/resources/articles/melprb.pdf summarizes a 'design challenge' from comp.object. This is also worth a look; his design for what is a simple table-based electricity rating system turns into individually coded subclasses(!) for different rate breaks and happily mixes up customer, rate selection and calculation concepts.

That's in fact discussed at page 15:

 > *IF* the [generalized algorithm] is a concept that the PUC will
 > *never* violate, then your abstraction [using tables] is quite nice. However, if
 > there is a chance that the PUC will come up with a rate that violates
 > that concept (i.e. charging based upon the previous 12 months usage,
 > etc) then your application breaks in a general way.

In other words, I was complaining that Steve’s solution depended strongly on the assumption that his generalized rate algorithm was valid; that the PUC would never intro-duce a new kind of rate that did not fit his generalized algorithm. I continue:

 > On the other hand, with my solution, any individual change to any of
 > the rate policies will cause a change to one small part of the
 > application. The rest remains unchanged and unaffected. i.e. the
 > rest can be linked in from object code, no recompilation is necessary.

Interestingly enough, the requirements blurb is in terms of 'Rates Schedule' and 'Rate'... these would have been indeed perfect abstractions for the problem.

-- ThomasWhitmore

Perhaps a refreshing change from the fictional case studies are some BooksAboutRealDesigns, which describe the design and implementation of significant real programs. -- LukeGorrie