Training and Coaching

I just found an old article that I co-wrote back in 1997 for Computing Canada. The article was really a reader's digest version of a report I wrote for an application audit (a really intensive code review after-the-fact). It was a PowerBuilder app and the article makes reference to some PB-specific technology but reading it again 8 years later I'm surprised to realize that so many of the same things apply to the way we build apps today.

Too often, I see relatively junior programmers unleashed on software development projects with little or no guidance or leadership. As a matter of fact, I've probably spent two thirds of the last year rewriting year-old software that was created by junior resources with no training and no concern for best practices. I can see why companies are lured into using resources like this. They're relatively cheap, they're pretty keen, they work long hours and they really crank it out. But if they don't know what they're doing you end up supporting the old adage "there's not enough time to fix it now, but there's always time to rewrite it later".

The biggest thing that junior software developers don't do, is separate concerns. UI, business logic and data access get all tangled into one big incoherent mess. I stress that there must be some cohesion in your domain model. Generally speaking the closer you get to the users the more your code is exposed to change. In other words, the UI is going to change. Count on it. As you go up through the layers things change less and less. By the time you get to your domain model and the relational model that allows it to be persisted, Things are very stable and any change you must make to them has serious repercussions on the rest of the app. Therefore get that stuff right. You can be forgiven for cheating a bit when you get to the UI but at least build the backend stuff as well as you can. And feel free to use some junior resources, but for crying out loud, lead them.