How to make big projects work?
In this article, Herbert Lovelace shares the 4 basics that he follows, in order to get big projects to work.
His 4 step system is:
- Detection: Making sure the problem is clearly identified.
- Preparation: Figuring out what to do and how to do it.
- Implementation: Keep it as simple as possible and have a rollback strategy.
- Reflection: Learn a lot after the project is over about what we might have done differently
He also gives us these quotable quotes :
- "
- "Project histories, like kitchens, tend to be cleaned up when shown to guests."
What’s your experience? How do you make big projects work?
Reference:
>> Secret CIO: Four Steps To Make Big Projects Work
I agree, pair programming can work only if the entire team buys into the concept. Many developers have a personality type which makes pair programming almost impossible. I do not think there is anything wrong with this. Certain people prefer working independently, and that is fine as long as they have the big picture of what the team is trying to achieve. Having said this, pair programming works wonderfully when we are trying to solve a particularly difficult problem. I am sure there is place for personal heroics here, but I have experienced that very often when two developers try to solve a problem collaboratively they come up with a better solution, than what they would have done independently. This does pre-suppose that both developers are inclined to collaboration. If they are not, then they might end up in a stalemate and argue endlessly about which is the better solution, without arriving at any conclusion.
Pair programming also works well when an experienced developer pairs with an inexperienced one. It is a very good learning experience and can help the new developer raise the bar of his work quickly.
Overall I do agree with you that the effectiveness of pair programming will depend a lot on the culture of the team and individual personality types. But something can still be gained by practicing it partially in situations and with people who can benefit from it.
keep it simple is the key. forget it and your project is dead. not just a big project but any project.
The author should give a strange and complex name to this software dev methodology and he might soon start to be regarded as a guru.
If he keeps his suggestions are simple as the 4 steps above, he will never become a guru. The more confusing and apparently complex, the better.
🙂