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 

Oh, I'm sure you've all asked that question to yourselves - "What do I want to be when I grow up?"

Well, quite frankly, I have no idea. I went to college to be an architect, but that fizzled out after a year when I realized that I'm good at the engineering "stuff" but not so much at being an artist. The first year of the five year Kent State architecture program turned out to be really artsy-fartsy. Way beyond anything I expected. So, I picked the next best thing - computers!

So, (eventually) I end up with this B.S. (that's Bachelor of Science, not the other B.S.) in computer science, and a good career so far. But the thing is, see, is that I feel stagnant. I've been at it for 10 years more or less and I just feel.... I dunno.... stuck in a rut. Maybe it's a mid-life crisis, who knows? One thing is for sure though, I've got to get moving in some direction.

I've been working a bit on my M.S. in computer science, and I've recently transferred back to Kent State with the thought that maybe... I dunno, that maybe I'll get my Ph.D. I'm just not sure. I could teach. I could research. I could become a museum curator. I'm a little bummed out because I work really hard to be a good geek, but there are all these other really successful geeks who have degrees in things like Psychology yet have really cool geeky geek jobs. Not that writing management and administration software for IP-PBXs and VoIP systems, and compilers for proprietary languages, and messing around with Jitter Buffers (<-- that's definitely geeky) isn't cool, but it's just not Cool with the capital C. It's cool with the lowercase c, as in "Oh, you like math? That's cool." kind of way.

So, the mission for January is to really figure out what I want to be when I grow up. <sarcasm>I'm allotting myself a whole month to figure this out, so it shouldn't be too tough. I've been toying with the idea for couple of years (decades) so it shouldn't be too tough to nail it down with a concerted effort. </sarcasm>.

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?

Ever look at some code and see anything similar to this:

//
// make sure we're not null
//
  if (m_settings[item] != null)
     return m_settings[item].ToString();

Every Day? Me too.

Ever wonder why so many programmers assume the double identity of the variable they're currently working with when they write the comment?  "make sure we're not null" As though, at runtime, the developer suddenly becomes null too.

Interesting.

I've discovered that grad school is a lot like drinking from a firehose.

The amount of information that is presented is remarkable. Which isn't to say that it isn't interesting or fun, quite the contrary. However, discerning the really important information from the noise is quite challenging.

I'm certain that I won't actually realize all that I've learned until the semester is over and the dust settles.