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.
No comments yet.