Library columns
Pro Developer - Optimize Your View
Christopher Duncan is President of Show Programming of Atlanta, Inc. and author of both the monthly syndicated column Pro Developer and the recent book for Apress, The Career Programmer: Guerilla T...
- Introduction
- Setting Priorities
- The Usual Suspects
- It's Not My Job
- The Road Ahead
Setting Priorities
If we're not going to talk about functions and objects and squiggly little lines of incomprehensible text, then what on earth are we here for? What could possibly be more important to a developer than the details of writing code? The answer is both obvious and elusive in the same breath. The most important thing to programmers everywhere is not writing code, but rather delivering quality software.
Did you just stop, shake your head and read that last sentence again? You're not alone. Almost universally, good programmers reflexively equate writing code with delivering software, as if they were one and the same thing. They are not. In fact, it is this very view that is largely responsible for release disasters worldwide.
If you don't know what a release disaster is, you've led a charmed life. Take two donuts out of petty cash and go back to what you were doing. The rest of us are all too familiar with the details of good releases gone bad, including arbitrary deadlines, endless overtime, high stress levels, short tempers and monitors flying out of fifth floor windows, all for a product that gets shipped long before it's ready due to market pressures. When your software hits the streets with more bugs than a cheap motel and less stable than a maintenance programmer who hasn't slept in a week, are the technical details of coding really the guilty party? Not likely. I can assure you, some of the worst software releases I've seen were the product of absolutely brilliant technical minds. Let me present that thought once more, for emphasis. Poor quality software releases are almost never due to a lack of technical skills.
So, if the project you're working on is greeted by the user community with those two immortal words dreaded by programmers everywhere ("it sucks!"), then who's the culprit if not the code? The programmers, of course. Hey, you didn't think you were going to get off the hook that easily, did you?
And wheres the info??? i would like to see you expand on the methologies you use day to day and how you approach new apps in time managment.
After reading it, however, I think it would make a very, very good intro into a much longer essay (or book!) concerning this topic. If Christopher Duncan ever writes on this topic again (and I hope he does), I'll jump at the chance to read it.
Hey, guys.
Thanks so much for the kind words. I of course try to observe proper etiquette regarding blatant plugs, etc., but, er, since you asked...
I go into a lot of practical details about how to get the project out the door in the real world (where we aren't usually given the time we really need, etc.) in my previous book, The Career Programmer: Guerilla Tactics for an Imperfect World (Apress). This isn't a Code Complete / bits & bytes kind of book, but rather a collection of street tactics for dealing with management, marketing, arbitrary deadlines, etc. If you enjoy the Pro Developer columns, I think it's the sort of stuff you'd be interested in.
Additionally, my latest book,Unite the Tribes: Ending Turf Wars for Career and Business Success, just went to the printer Friday and should be on the streets mid-November. This is not a techie book, but one written as much for us as anyone else - the tactics apply to anyone working (or managing) for a living. Since I just got it done, there's not a lot of info up on the web site just yet, but I'll have more details up very soon. In short, the bottom line is that prosperous companies have more money to spend on their people than broke ones, so the path to a better career requires expanding the empire (i.e., your company, the people who write your paycheck). The cornerstone of it all is the fact that, at the end of the day, success is all about people, and knowing how to get them to support your goals and desires. Once again, it's written in practical terms with the real world in mind rather than discussing ivory tower concepts. Maybe I've just been on the streets too long...
Anyway, as far as my writing, that's what I've been up to lately. By the way, I'd love to hear success stories from any of you who take these tactics into battle and achieve your goals. That's half the fun of writing.
I have to agree- I was left with my mouth watering, waiting for the beef to arrive. I have absolutely no comments regarding the message of the essay (all quite true). After reading it, however, I think it would make a very, very good intro into a much longer essay (or book!) concerning this topic. If Christopher Duncan ever writes on this topic again (and I hope he does), I'll jump at the chance to read it.
Conceptually a good article to get programmers who have not already embraced the concept started thinking.
Lacking in the "meaty" details of just how this is done.
First, management has to buy in to the concept that they will get a better product, fewer bugs/complaints, ROI and agree to support the effort.
Next, Users have to become part of the development process all the way through, not just as beta-testers at the end of the development cycle.
Finally, there is no substitute for a really good, professional project manager who can work both sides of the street, leading programmers toward the water, getting the users to drink and the training company to create training materials that address user issues instead of just high-lighting the techno-features that may not make the program more useful to the end-user. You know the person who's paying for the software, whether directly or as a corporate user within your company.
This thread is for discussions of Pro Developer - Optimize Your View.