I was pairing with the new guy today at work, trying to blast through what you'd think was an easy set of use cases to do some integration with another system. It went horribly. Meanwhile, one of the other guys on our team was getting owned by some raunchy code we inherited. So overall, it was just one of those demoralizing kind of days around the team. We're working to get to a place where that's no longer the case, and we will get there.
I've seen this enough times that it doesn't surprise me, and honestly I've seen much, much worse. That perspective makes me less concerned. My problem is that I tend to get more wrapped up in how you prevent such things in the first place than how to undo them. There are a number of situations that create a universe of suck in the software development world. These are a few...
The original developers were inexperienced. The reasons for this are many. In the consulting world it's almost always because no one wants to pay for good people. Other times, there's just a process problem where the shape of the software is formed in a vacuum. The truth is that someone can get by and make something that "works" if it's not huge, but folks like that will make a mess of anything more involved.
At my last gig, there was an app that two guys (later canned) wrote that was all kinds of ugly, impossible to test and otherwise a spaghetti-style mess. I believe that they were doing their best, but they were in over their heads, and in an attempt to please someone, agreed that they could do the job and get it done early. The guy I had working on it wanted to poke his eyes out.
The other scenario is that there are people out there with no interest in the craft and take no pride in their work. Mediocrity is good enough, and that's where they meet their paycheck. I've seen that a hundred times as well. I think most of us get into this line of work because we're thrilled by the continuous learning and the feeling of "look what I did." Some people seem to just lose that entirely, more so in the consulting business.
So being a solutions kind of guy, what do you do about this? Well the first thing, if you're ultimately responsible for whatever the product is to be developed, hire someone who has a clue. Seriously, with all of the bullshit religion about whether or not you should use "free" open source software or commercial product, the idea seems to get lost that your true expense is people (the purchased software is a rounding error by comparison). You can hire someone for $100k, which might be high or low depending on where you live, and leverage their expertise to make something of high quality. Or you can hire someone for half of that who is not a ninja and then later either hire another person like that to try and maintain the app, or bring in the more expensive guy after the fact. Either way, your long-term cost ends up being hire.
Don't develop in a box. This is why agile/scrum/XP/team/whatever scenarios tend to yield better stuff. Open and spontaneous discussion about design matters. Code review and/or pair programming matters. The stuff where you spend months figuring something out and then disappear behind a door for more months results in shit. No one wants to use shit.
Learn. Never stop. Seriously, would it kill you pick up a book now and then? You don't have to go to college to learn about software development (you do to learn about sex, your alcohol tolerance, religion and other fine points about yourself), but you do need to make time to keep up. Cutting and pasting shit off of StackOverflow.com is not learning. Find someone who can mentor you and get everything you can from them. Learn the design patterns, not as encyclopedic knowledge, but as practical, applied knowledge (MVC on any platform is great for this, by the way). At the very least, understand what "loose coupling" means. It's not a dating exercise.
Above all, take pride in your code. But not too much. Always know that someone else, eventually will have to deal with what you wrote, so ask yourself if that code is going to make someone else miserable. Get feedback. I'm not suggesting that you need to have hour long discussions about what to name a method (though I've unfortunately witnessed that as well), but don't require guess work. That next person to see that code might be you, and you're not going to remember it. And no, comments don't help, they only indicate how bad your code sucks in the first place.
Some day this summer our team expects to bask in each others awesomeness for the job we did, but at some point, maybe a year from now, maybe five, I'll be in some other code. Please don't leave crap for me.
No comments yet.