Tag Archives: software

Is it methodology or people that make the biggest difference?

I seem to be thinking and reading a lot about tools, methods and effectiveness this month.

Earlier, I got enmeshed in a discussion on LinkedIn about whether email is still an effective tool.   In one post to that discussion, I wrote “As a third-generation woodworker, I have a (probably unhealthily) large collection of tools. Some of them I rarely use, some much more often. Why do I keep them all? Because that way, I don’t have to use a hammer for everything – I can generally use the right tool for the job.”

Elsewhere, I read a piece by Greg Jorgensen which asked  Why don’t software development methodologies work?   in which he concluded that software development methodologies ultimately fail to deliver predictable, repeatable successful results.  Like me, he has been through the waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD etc toolboxes. And like me, he has seen them sometimes succeed and sometimes fail to deliver projects on time, on budget.  Amongst other reasons, he ascribes this to blind adherence to the method:

“Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision.”

He then concludes that ultimately, it is the people using the method (or no method) that make the bigger difference – how they work together, whether they share a vision of where the project is going, how they communicate, how skilled they are.

Nik Silver, however, argues that although people are important, method is by far the greater determinate of success.   He says “Change the methodology and you change the culture.”  And “the same people working together much more effectively than ever before to deliver impressive results”.

I do believe in using the right tool for the job, and that it is easier to do a job right if you are skilled at using the tools you have.

At the risk of sounding like a consultant, I am given to thinking that Greg and Nik are both right and both wrong.  Because it takes both – skilled, communicative, intelligent and committed people to use (ideally) the most appropriate tools to do the best possible job.

Having lived through, and sometimes led, method and organisational change processes – does anyone else remember TQM? – I wonder whether it is not the novelty of the “new” method that makes the difference. By making people think in greater detail about what they are doing and how they do it, is it  not more likely that they will also give more attention to actually doing all the things they should have done anyway?

The big thing most software development methodologies have in common is that they define methods, processes and frameworks for communication between the various parties – the customers, the stakeholders, analysts, designers, developers and project governance apparatus.

Which made me review my own experience and observe that:

  •  A group of talented, determined developers that don’t communicate outside their circle will develop something, but that something may not be the right thing (ie what the customer wants) and if they don’t communicate with each other, it probably won’t work very well
  • A group of highly communicative developers without a driving force (vision? delivery plan? stakeholder involvement? methodology?) will spend a lot of time talking but will never finish developing anything
  • A group of communicative, talented, determined developers, who know what they are doing and why (because they know and share the vision)  are more likely to achieve success regardless of the method employed than a group of less-talented and/or less communicative developers applying any chosen development method.

Sifting through the myriad development languages, tools, environments and  methods that I have experienced over the years, I can’t escape the conclusion that new methods and languages and tools are invented, popularised, discredited and discarded not necessarily because they don’t work, but all too often because they don’t work any better than what they were meant to replace.  And all too often because they are just the wrong hammer to crack the particular nut in front of us.

Is that the fault of the tool or of the user of the tool? Probably at least a little of both.