Scrum Workshop

My team spent the day today learning how to do Scrum. (Scrum is an agile project management methodology that's named after a Rugby term). Anyway, it was a great workshop, led by an excellent instructor, and we all learned a lot! I hope we can really apply what we learned and I hope we can get our customer to buy in 100% to their role as the product owner.

What amazes me most about Scrum is its simplicity...so easy even a caveman (like me) can do it.

The Code of No Code

Years ago, when I was a lowly mainframe programmer, I used to think that one day people would no longer be writing all these lines of code and would instead draw pictures of what they thought a system should do and the pictures would be used to generate the code. Today they call this "Model Driven Development" and I hear that some people actually use this technique to create programs. I can neither confirm nor deny this, however :)

I Blog Therefore I Am

Actually, I can't think of anything else to write for this entry, but I always wanted to say that.

Scrum

We're taking a serious look at Agile methods at work right now and in particular Scrum for managing our software releases. I think it's going to be great for the team. All those Pigs and Chickens and planning poker and everything! Awesome!

Agility or Discipline, That is the Question...

It seems that Agile methods have taken over as the status quo these days...but what about the old "Tried and True" methodologies? Are they dead? I don't think so. The best way to develop software surely lies squarely in the middle between agility and discipline.

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...