In my relatively short career in software
development (which is still like 50 years in Internet time), I've been
exposed to a wide range of development methodologies, project
management and general dev culture. The easy trap to fall into is
trying to apply what you learn to every new situation.
The worst
thing I've ever seen was at this, uh, accounting type company I worked
at, where they had this monstrous application (in FoxPro, puke!) that
was a dog. My boss would work like 60 hours a week, people were pissed
all of the time, and there was no significant testing, and zero
documentation. Changes would go to production instantly. Getting
laid-off from there was the best thing that could have ever happened to
me, and I didn't even have any work to do there.
On the other
hand, my five or so months as a contractor at Progressive was
remarkable. It changed the way I look at everything. You'd think such a
huge IT organization would be a mess and filled with failure. But in my
group at least, the requirements process was very precise, and the
agile methodologies being guided by consultants was having very rapid
pay-off. It was kind of boring to do work with no UI, but I guess
having a big line of green dots on NUnit was fun, sort of.
I'm struggling staying on target with the rewrite of POP Forums
because, I think, it just feels like I don't have anything tangible to
show for my work so far. It's so odd that despite being a published
author, able to make ridiculous salary or hourly demands and generally
being perceived as a clever Internet guy, this one stupid application
defines my total existence. I suppose it's because the app is core to
my "hobby" sites, and that's what I really like doing.
After reading the sample chapters from 37signal's Getting Real
book, I decided to plop down the $19 for the PDF. I'll first say that I
think these guys are a little on the pretentious side, and their
preface indicating they aren't doesn't get them off the hook. That
said, a recurring theme in the book is to just f'ing build something
and not get hopelessly caught up in the details. And build the UI first.
Even Microsoft is starting to get that Web apps can be built on the fly (see Windows Live),
and never be "done." I do agree that's true, but it's not that simple
when you depend on the income from a particular existing app you're
replacing. For example, my new forum app will be the core of a revamped
CoasterBuzz.
While they make the case that you should deploy half an app and not a
half-assed app, I can't exactly put even a half-site up when people
already expect certain things from it.
But there are other things
they talk about that I do catch myself doing. For example, I'm thinking
about some clever way to encapsulate permissions (can/can't read/post
in a forum), and even tie it to the UI. As the book says, I'm worrying
about a problem that I can't solve, and that wastes time. I don't even
have topics or UI yet.
And this gets to the iterative nature I'd
like to adhere to. I hate how I get wrapped up in details that aren't
relevant when I haven't even solved the basic problem. Getting
something that starts to look useful quickly, and building on top of
that is certainly a lot more rewarding.
Part of the issue is my
fascination with unit testing, which I don't do correctly most of the
time anyway. I test too much or too little. Pair that with the agile
mantra of doing short, four-hour tasks at a time, and I don't do things
the "right" way at all. So here I am building a class library based on
unit tests, and not getting closer to the place I want to be. At the
same time, the unit tests save my ass when I do iterate and change
something to, for example, add a new column to a database and
associated property in the object representation of the data.
But
for all of the angst I feel over not feeling accomplished, reading
about different ideas on how to develop software kind of gets me
energized. That's a good thing.