Requirements

Gathering and documenting software requirements is a discipline that has been approached in many different ways over the years. Detailed analysis and design documentation, feature lists, use cases, user stories, prototypes are all approaches I've seen and/or used.

I'm not sure that any of these is the "best" approach.

What I believe is more important than any requirements technique are 3 things:

• Requirements need to be simple, clear and concise
  
• It's important to get requirements from the right people
• Requirements will change
  

Linked Lists

I remember one of my projects in college was to create our own database management system using linked lists. Do they still teach these kinds of things?

I also remember that my decision to change my major from a focus on architecture (real architecture, not the software kind) to computers was based on thinking that nothing else really sounded very interesting at the time (besides hanging out in the student union and playing ping pong and they didn't have a major for that)

So here I am a bunch of years later and I still play ping pong and I ended up as a software architect. Fate is strange, eh?

Methodologies

I have always been a fan of process. I've enjoyed watching software development processes evolve over the years. The one thing I've noticed is that there is no "Perfect Process". They all have their strengths and weaknesses and most need to be tailored to add value. I've followed SDLC's, written and implemented SDLC's, used RUP, and worked to incorporate elements of waterfall, spiral, agile, etc. as appropriate. In my experience, none of these approaches seems to be the "end all be all" of software development processes.

What seems to work best, though, is to approach usage of any SDLC from a common sense perspective. Tailor the process to meet the specific needs of the project.

Programming on Punch Cards, the Jurassic Period...

I was telling someone just yesterday about how I had to program on punch cards in college...writing code for fortran, cobol and rpgII. Dinosaur days! I still remember the day they installed the new really cool Cande terminals for our Burroughs and we got to use those instead of cards. I also remember the day (previous to the Cande terminals) that I dropped my 350 card cobol program on the day it was due and the card sorter was broke--had to put them back in order by hand...glad we've progressed since then!

First Post

I hope to capture my thoughts about where I have seen software development over the last 20 or so years and where I think it's heading. Maybe this will just be a lot of rambling...