The biggest determinant of success that I've seen is the skill of the programmers on the team.
No McMethodology can make crappy programmers write good code. Period.
(However, really bad management can make good programmers write crappy code too...)
No McMethodology can make crappy programmers write good code. Period.
(However, really bad management can make good programmers write crappy code too...)
Factors contributing to the success of a development project, in decreasing order of importance:
1. the skill of the team
2. the determination of the team to succeed
3. appropriate choice of technologies
4. process
In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Everybody pays lip service to Fred Brooks but people somehow seem to keep forgetting his message.
Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers.
This is immensely frustrating to the bean counters. Anything that comes along and promises to allow programmers to become commodities is going to catch on like wildfire. The desire is too strong from a management perspective. It doesn't matter how many times such efforts have failed in the past. What's old will become new again.
The point of Agile (and Scrum) is to give responsibility back to the clients/managers: pick one -> time or money, you can't have both; we'll show you why from our user-stories, cards, task-boards, poker-game, scrum planning, etc.
Agile theory does make some nods to not commodifying the programmers labor and giving programmers autonomy. But when it's sold the bean counters, they filter for the parts that get them what they want.
I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.
Can't a McMethodology help crappy programmers become less crappy (and eventually write better code)?
Are there any methodologies that can help with this?
Ideally, poor developers get replaced by better developers, but realistically this (for all sorts of reasons) doesn't always happen. So, if you're a project or team leader, what can you do to elevated the level of code from sub-optimum developers?
Anything? Or maybe it's better to give them "fake" code to write so they stay busy and out of the way.
I do think that poor developers can be taught to be better in a work environment, but it's a painful, slow process, and has to be started with an a keen devotion to the process on the part of the trainee, which if it were going to happen at all, would probably have already happened during college.
What exactly do these high-ceremony agile projects practice?