Monday, March 23, 2009

Getting Stuff Done

Today I was reminiscing about college and doing a bit of compare and contrast between how I got stuff done then and how I get stuff done now. I was surprised to find that this was actually somewhat interesting, so I'm writing about it.

In college, each class gives you one assignment at a time, and each comes with a due date. You may have many things going on concurrently, but each is clearly prioritized based on how hard you know the assignment will be, and when that assignment is due.

This situation is quite manageable. You may have to pull some late nights to get your stuff done on time when you find yourself in the unfortunate position of having many assignments due all at once. You may also shoot yourself in the foot by procrastinating. But when that happens, you know it was your own fault. So, at least in my experience, college assignments were really quite doable. I had some periods of stress, and I certainly had times when I felt very busy, but overall, it wasn't so bad.

The real world is not like that. But, why not? What makes it so different?

Here's some of the characteristics of college that don't show up so frequently in the real world:
  1. Well defined work
  2. Fixed schedules
  3. Clear priorities
  4. No re-work
  5. No support calls
  6. No releases
This is pretty self explanatory I think, but I like to hear myself type, so, lets talk about it!

Well defined work is easy. In college, you get a detailed assignment. It tells you what your inputs are, what your outputs are, exactly how the programs should behave in every way. You write it, test it, and you're done! Well defined work. In the real world you try to get your customers to define the work. But your customers don't even know the work themselves, so its really hard for them to define it for you. This means you can spend lots of time working on things that you either don't need, or that don't work quite the way they really should. And you don't get to find this out until you're all done.

Fixed schedules is also easy. In college, you get two weeks to do your assignment, from start to finish and turn it in. The professor never tells you to stop a week in and do another project. Or worse, and more realistically, to add another project on top of the first. This seems to happen all the time with real work, and it makes it difficult to plan ahead and stay on track. You start to feel like a never ending stack trace...

Clear Priorities dove tails nicely with fixed schedules. Your school assignments are easy to prioritize because you know up front how much of your grade its worth, how difficult its going to be, and how long you have to do it. These factors allow you to easily decide which assignment should be given priority. Once again, real life is not so clear cut. Things pile up and they're all ASAP highest priority do or die holy crap! Good luck prioritizing that!

Ah yes, re-work... Here's a factor that you never ever ever ever ever encounter in college. If you suck it up on an assignment you get an F, you move on. Not so in life beyond the academic gates. If you screw it up it doesn't end there. It snow balls and things get worse and worse. And only if you're lucky do you actually get the opportunity to go back and fix what you screwed up. And now you've spent twice as long on that assignment, which has certainly pushed back some other absolutely top highest priority assignment.

And now we come to support calls. My favorite! I never had a professor call me weeks after I'd finished an assignment and ask me how to use it. Or ask me why it doesn't do something no one ever heard about before. But the best part about support calls is how much time they can eat up. Simple calls will take you about twice as long to answer as you feel like it actually took. And complex ones will eat your entire day.

Finally, with a college assignment you have a single release: the first one. And none after that. In the real world, you'll have lots of releases. How many depends on your specific situation. But, one of the tenets of Agile is release often, so I think lots of people are probably doing lots of releases these days. Releases take time. You have to migrate the database, release the client, push the update, test. And the bigger the system, or the more components it has, the harder this process will be. In fact, this can get ridiculously hard. And this is yet another thing you never had to deal with in school.

So, is it possible to get stuff done in an environment where you're being pulled in so many directions at once? Or is the only answer to bring some of that collegiate structure back?

Interestingly, if you read many of the Agile practices in this light, you see a lot of it is geared towards restoring some of these characteristics. For example, iterations. This practice manages to restore some of your well defined work, fixed schedules, and clear priorities. Also, the customer representative and release often practices are there to try to cut down on the amount of re-work.

So maybe the best you can do is try to bring back as much collegiate structure as you can, because its awfully hard to get anything done without it.

1 comment:

  1. Having a first hand knowledge of your college experience, I have to disagree with one example: Prof. Lang's Systems Programming class where we wrote the assembler.

    That assignment was the only example I can think of which did involve multiple releases, re-work, and to some degree support calls. Since he had us building on last week's assignment for each new one, it involved a fair bit of re-work and release like issues ... plus if you wanted any help from him he would invariably ask you why/how something worked a few weeks ago but your having trouble now.

    That assignment taught me more about software design, patterns, and refactoring (even though the terms weren't used) than 99% of all other programming assignments.

    That one assignment aside, I completely agree.


Note: Only a member of this blog may post a comment.