Complexity theory

July 5, 2007 19:30 by dgood

I'm working on an essay, more of a research paper, really. 

I was listening to an interview with Grady Booch during which he mentioned that much software architecture is grown, or evolved, rather than planned.

That got me thinking about architecture in general, and brought to mind a quote from Linus Torvalds:

Nobody should start to undertake a large project. You start with a small _trivial_ project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed.
http://en.wikiquote.org/wiki/Linus_Torvalds

I left off the last couple of sentences from Linus' quote which could provide more relevant context, I don't know, that's for you dear reader to decide.  Personally I find that it doesn't provide any mitigation to the first couple of sentences, so it's irrelevant.

Then I began to think about software engineering in general,  and particularly the essay that Steve McConnell wrote the other day about Software Engineering: Rumors of Software Engineering's Death are Greatly Exaggerated (aka Software Engineering Ignorance, Part II)

I think if you ask 10 seasoned software engineers to define software architecture, or software engineering, that you will likely get 10 different yet conceptually similar answers.  So it sounds fairly simple.  Then why are there so many contradictory philosophies? 

  • Problem:  Too much architecture is not planned
    • Solution:  Need more planned architecture
  • Problem:  Too many people plan big fancy architectures
    • Solution:  Think small
  • Problem:  Too many people don't engineer software
    • Solution:  Need more emphasis on the engineering aspects of software

So, I solicit your input on the following:

  • When is it ok, or not ok to have Big Design Up Front (BDUF)?
  • Can BDUF and Agile methods coexist?
  • What separates Software Engineers from Software Architects?
  • How big, or how complex should the architecture really be?  (No lame answers of "only as big as it needs to be")
    • In other words, If I'm sitting down today to begin creating the next generation of a complex system, how complex can the architecture be if I "start with a small _trivial_" architecture?
What gives?

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:
Categories: Software Engineering | Project Management
Actions: E-mail | Permalink | Comments (1) | Comment RSSRSS comment feed |

Related posts

Comments

July 7. 2007 15:36

Paul Preiss

Let me start by affirming your belief in architects opinions. I have asked many hundreds of architects what they think the definition of architecture is and it is always different yet similar. The reason is that it is to big a question. It's like saying what is the definition of medicine. The answer if given briefly cannot hope to cover the sheer complexity and scale of an entire profession and it's sub-components. The other reason is that architecture is a living body of knowledge. It is like language, it changes a little each day. The reason is of course that it is a profession in practice and we make new fundamental discoveries each day. What has been missing is the ability to capture these differences and discoveries and make them actionable in peoples careers.

Anyway, there are many many answers to the questions that you ask. Fundamentally architecture is about context, scope, constraints, creativity and yes complexity. For example your first question about up front design. NASA does up front design because their constraints are enormous. If you are handed a project, say a health-care perscription management system that your company is rolling out as a primary product. Well these problems can only be broken down so far. In fact by breaking them down into smaller pieces (thinking small) you can in the end increase complexity. For example, many of the architects I meet are dealing with systems that have grown organically using localized constraints and now they have huge amounts of duplication in foundation components (security, persistence, web/ui, etc). While the systems were built project by project they never thought about the future. Instead of think small, you should switch to "think big, start small, move fast". Its the thinking big where architects come in. Remeber though that thinking big doesnt translate to think cosmically. You must base your design complexity on a deliverable approach, as represented by the start small, move fast piece of the saying.

Cheers
Paul Preiss
IASAhome.org

Paul Preiss

Comments are closed