Pragmatic OOP

In my last blog post I talked about people pushing a process as the magic bullet when it is the people that matter. Having the wrong people on a team can cause havoc and kill a project. Sometimes these wrong people are cargo cult programmers.

According to Wikipedia: ‘Object-oriented programming (OOP) is a programming paradigm using “objects” – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.’

OOP is supposed to be a practical way to organize a program into hierarchies of objects where similar objects can inherit behavior from each other and override that behavior when necessary. Objects can also contain other objects and that is a technique called composition. Certain programmers pick up OOP and fall in love with the rule-set without fully understanding it, or they over-apply the principles. These people are cargo cult programmers. Continue reading “Pragmatic OOP”

F*ck the process, embrace the team!

Agile seems to be losing some of its shiny newness at last. This is great! It means we can start talking about agile without fanboys eagerly interrupting to spurt out some repeat-hyperbole from an Agile Evangelist meeting of some sort.

It also means that I can  tell you this dirty little secret without too many people choking on their agile-conference-coffee:

TDD, XP, Scrum, Kanban (and the rest) are all processes and tools. All their proponents claim you *have* to follow the process, no matter what. If Agile fails for you, then it is because you are not following the process!

The Manifesto for Agile Software Development tells us that we should value “Individuals and interactions over processes and tools”.  How is it that the Agile community has accepted the rigorous following of strict processes? I think it is because there is a market for selling processes. And those in the game of selling processes won’t tell you that sometimes the process just doesn’t work. The same way Toyota won’t tell you that sometimes their cars unintentionally accelerate and can kill you.

The real secret is that it’s the people that matter, not the process! Process is good. Formalizing development methods is good. But if you have the wrong people you will fail, no matter what process you use. Conversely, if you have the right people it doesn’t really matter what process you follow. You will most likely succeed.

It is time we stopped selling processes as the magic bullet. Agile is great, and methodologies like Scrum, TDD and XP can be good facilitators for getting from concept to release. But they do not solve the fundamental problem that   a bad team fails no matter what process it uses.

Programming is a human activity, as described in the classic book ‘The Psychology of Computer Programming” by Gerald Weinberg. Therefore the human and psychological aspect needs to be considered when forming a team.

The fact is: Some people don’t work well together no matter how well their skill sets match. Some people are useless within certain processes. And there are also people in the programming field that could be of more use doing something completely different.

We should strive to create the perfect team, not the perfect process.