I started working on a post a couple of weeks ago, but like many things, I don't know when to quit.  So, here I am with an incomplete essay / research paper hybrid that I'm _still_ adding to yet trying to keep interesting enough to qualify as a blog post.  Most blog posts that cross the 500 word mark are deemed large, and over 1000 are considered epic.  I think what I'm going to do is finish the paper then post it here as a PDF with some meta information about it.

It's an ambitious endeavor to be sure.  I don't want to give too much away since it hasn't been edited at all, but I will give the opening paragraph. 

Working title:

Why software sucks: How the software industry mislead its customers through its missteps and its inability to adapt quickly to a changing technological landscape

This will be an examination of the current state of the art in computer software applications, their construction, and the people and companies that create them.  I concede that that is an ambitious title and opening statement.  I will attempt to analyze the state of software today by shedding light on the industry itself; the processes that contribute to the end product; a historical perspective on computing; and examining the business of software.

Perhaps sounds more like a Dateline NBC investigation, I don't know.  We'll see where it goes.  Yes, the title is meant to be slightly ironic.

Cheers,

Goody 

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?