Ive been thinking quite a bit about the development process lately. There have been a couple projects I've been following at work that haven't gone exactly as I'd like them to; the developers were left to their own devices, and little guidance was given to their work.
One method I'd like to put in place for a couple of these developers is to strengthen the project scaffolding around their work. The projects they were working on had little or no rrquirements; those that were defined were weak and ill-defined, and weren't given great importance by the developers. We've been trying to put a more effective project documentation process in place, especially in departments outside of our own that have been running a bit loose. It's funny though - if you had told me three years ago that I'd be enforcing a project management process of m own free will, I'd have definitely looked at you funny. The benefit of it has definitely come clear to me though, and I can't imagine running a project without it now.
A big part of the problem is that these are junior developers placed in senior positions - they really should be paired with a senior developer. Of course, resources being what they are, that's not always feasible.
So how do I ensure these developers are successful in their work? The solution that occurs to me is to have their work go through a peer review process. This means that before their work can go to testing or production, it needs to be read and critiqued by developer.
Overall I think the code review process is a valuable one, and not just for junior developers. Senior developers can benefit as well. Indeed one of the most important activities for a developer of any experience level is to keep working. Having someone comment on your code and suggest more efficient / standard / new ways of doing things can be extremely beneficial.
What do you think? Is a code review a valuable exercise? Can you think of other peer activities developers should be engaging in?
Have you considered using a more Agile Programming paradigm, and focus on a measurable iterative process with something like SCRUM? You might find in a world lack of design specification that SCRUM might align better with what you are wanting to accomplish.
Code review is a point-in-time component that works, but does not always lead to the confidence you want if there isn't a more formal process that is also being followed.
Of course YMMV.
We have a fairly entrenched project process here that I need to try and work within, since that's the direction the larger part of our organization is going. We do our best to run at an enterprise level of project management, and often have a large group of stakeholders involved with a project.
SCRUM and Agile look interesting, but it also looks like they're geared towards smaller groups that don't have the same organizational requirements we do and can make adjustments relatively swiftly. Most of our projects are committee-based, which means we really need to get requirements and design nailed down at an early state and avoid making changes to those requirements during the development process. If changes are necessary, it means an exception review, which goes back to committee. We like to avoid those, since it impacts the project schedule pretty heavily.
I guess I should have been a little more clear as well with this entry, and state that my thoughts are around a couple of outlying departments that have hired their own developers and aren't necessarily adhering to our development practices (we generally follow a three-part deployment process: first to an internal development server, then to an internal testing/acceptance server, then to a production server once testing is complete). The only deficit I see in our current process is that we don't have any sort of code review within our process, so we're missing an opportunity where developers can learn from one another and work to create a shared codebase for common tasks.
I think the problem here is not about choosing a methodology Agile (or Scrum), but it's about applying bad Project Management. Little or No Requirements (what can you possibly do with no requirements?) In fact, the way you described it, your project(s) meet all the requirements for failed projects. Looking at this article, why IT projects fail, your project(s) probably match most of points in the bulleted list.
Now an organizational, traditional environment, especially one with distributed and/or large teams is not the best place where Agile can flourish. The ideal Agile environment is one where face-to-face communication is possible.
In the case of the one or two projects I mention that didn't have clear requirements, your comments are perfectly valid. Of course there are challenges in introducing project management methodologies to people who have never used them before, and a gradual approach might see far better success than a wholesale adoption.
But talking about project methodology starts getting away from my initial question, which was about the value of code review as a practice.