Page 1 of 2

Methodologies versus Best Practices

Posted: Sun Oct 01, 2006 8:25 pm
by alex.barylski
I'm compiling a list of both and organizing them as I would personally define and categorize them, but I'd like to hear others opinions on the matter.

Arborint, that includes you, unless you have no genuine interest in commenting, in which case I understand. ;) However I would appreciate feedback of any kind and promise not to argue, but only question anything I disagree with. Ultimately, this is going on my web site so I'll have the final say anyways. :P

Code: Select all

# Best Practices

    * XP
    * TDD
    * Agile

# Methodologies

    * UML
          o Use Cases
          o Data Modeling
    * Design Patterns
          o MVC
          o Factory
          o Registry
          o Singleton
          o Front Controller
          o Page Controller
    * OOD/OOP
          o Classes
          o Interfaces
          o Abstractions
Opinions, etc???

Personally I think I will further sub-categorize OOD and OOP including OOD principles underneath OOD???

Posted: Mon Oct 02, 2006 2:27 am
by Chris Corbyn
I don't see RUP in your list ;)

Posted: Mon Oct 02, 2006 3:19 am
by Maugrim_The_Reaper
Best Practices:

Domain-Driven Design
Iteration Planning

There's more - depends on whether a group/individual project. One of the best-best practices I've encountered in a group is Pair Programming.

If this is specific to a project - why Page and Front Controllers in same mention? M & V have other patterns - but I assume you already knew that...;).

Posted: Mon Oct 02, 2006 3:38 am
by onion2k
Whether 'Extreme Programming' or 'Agile development' are best practises is highly debateable.

Posted: Mon Oct 02, 2006 5:12 am
by Maugrim_The_Reaper
I prefer to look at the individual practices under each of XP and Agile... The entire group of practices are not always applicable.

Posted: Mon Oct 02, 2006 6:22 am
by Chris Corbyn
I always considered XP to fit into the category of Agile development. TDD certainly does. RUP is a HUGE case covering many different things.

I'm not really sure what we should be looking at here. Are we even stretching as far as Business Process Analysis or purely looking at development?

Posted: Mon Oct 02, 2006 6:33 am
by Maugrim_The_Reaper
Most folk usually hit the development side of each - but you're completely correct, we really shouldn't neglect the bits and bobs that happen before you even open an editor.

Edit: Bits and bobs? It must be the hangover...

Posted: Mon Oct 02, 2006 9:57 am
by Buddha443556
To me, XP, TDD, and Agile each encompass a number of best practice. For example, each implement incremental and iterative development to some extent. It's those fundamental best practices that interest me the most.

Posted: Mon Oct 02, 2006 6:34 pm
by alex.barylski
I don't see RUP in your list
I'm weary about adding anything that specific to my list, as I'm using it to promotes myself and I've never followed any design process closely enough to make such a claim...I'm questioning whter to even include XP or Agile as there are some differences and things I don't agree with. Pair Programming for example, doesn't really apply to me as a single developer and any developers I work with will be remotely located (the direction I'm taking my business - as I feel it's advantages far outweigh disadvantages).

Instead of agile, I like to consider myself an Versatile developer :P

Thanks for that though, I had to Google RUP as i've never really paid attention, but atleast now I know what it is...I've always used a iterative approach to software development, not so much from experience but rather it's just how I've always done things...following something similar to XP...I've always developed the bare minimum nessecary, refactored as I found fit and consider it done. Yes I'm guilty of over engineering...but usually only in library/frameworks where time is not a factor. My background and heros of OOP have assisted in influecing my decision on writting atomic software classes/modules, etc...KISS to the max. :P
There's more - depends on whether a group/individual project. One of the best-best practices I've encountered in a group is Pair Programming.
Hmmm...I've always worked as an independant developer, so I've never applied it to my situations...I can see how it's useful but also see it being redundant...I realize proponents would say it works wonders and their experiences were nothing but positive...however (and perhaps I'm not right to argue - as I've never tried it) I would argue it's redundancy and cost of development out weigh it's benefits. And I see my business capitalizing on outsourcing, thus (considering current technologies anyways) making pair programming somewhat difficult.
If this is specific to a project - why Page and Front Controllers in same mention? M & V have other patterns - but I assume you already knew that....
signature:
It's specific to what I feel I can offer as a developer when hired as a contractor, etc...an over simplification...nothing "to" specific, for example I don't wish to include my experience in multiple langauges, etc as that will be assumed, but my focus is clearly mentioned being around PHP as a development language. I limited patterns to most common and ones I best understand, there is no point in mentioning all.
Whether 'Extreme Programming' or 'Agile development' are best practises is highly debateable.
Agreed, but...this is a general over-simplification, if anything to demonstrate familiararity with principles, practices, etc...

TDD as an actual tangible addition to software development process with clearly a defined purpose IMHO makes it a best practice, but is also a method or approach to writing better code. So by that definition is could fall under both don't you agree? To avoid redundancy I included it under best practices.

XP or Agile or any other process which isn't clearly defined is by definition difficult to group or categorize...IMO anyways...

Pair programming for example I would categorize as a best practice, but I think it's success is also highly subjective...something I personally can't see being implemented in my own business model.

I'm really mentioning them more for buzzword advertising...as I'm only moderately familiar with XP or Agile and currently stand somewhere between, yes there are some good points and others which I disgree with. I have to read up it more before I make a final decision, even then it's subject to change.
I prefer to look at the individual practices under each of XP and Agile... The entire group of practices are not always applicable.
Thats the reason I just generalized...as many don't apply to all situations...again I've got to read more about it before I can really disscuss this further...
I always considered XP to fit into the category of Agile development.
I'm of the same understanding ;)
TDD certainly does
Again, personally I agree it falls under a best practice, but also it's an actual method which is obvious it will yield better results...this makes it difficult to categorize with including multiple times...
I'm not really sure what we should be looking at here. Are we even stretching as far as Business Process Analysis or purely looking at development
Everything I suppose, but more for the business perspective...although I'm looking for both...
Most folk usually hit the development side of each - but you're completely correct, we really shouldn't neglect the bits and bobs that happen before you even open an editor.
As both a developer and business enthusiast...I'm interested in both perspectives..
To me, XP, TDD, and Agile each encompass a number of best practice. For example, each implement incremental and iterative development to some extent. It's those fundamental best practices that interest me the most.
Admittedly TDD encompasses more than my understanding extends...but I can agree with that so far...

Cheers :)

Posted: Tue Oct 03, 2006 12:54 am
by timvw
Hockey wrote:
I don't see RUP in your list
I'm weary about adding anything that specific to my list, as I'm using it to promotes myself and I've never followed any design process closely enough to make such a claim...I'm questioning whter to even include XP or Agile as there are some differences and things I don't agree with. Pair Programming for example, doesn't really apply to me as a single developer and any developers I work with will be remotely located (the direction I'm taking my business - as I feel it's advantages far outweigh disadvantages).
Basically, you're not interested in making a summarization of methodologies and best practices, you're interested in making a list that makes you look good ;)


(I find the methodology vs best practice discussion useless, since they're not orthogonal. Following a methodology can be considered as a best practice in some domains, where the application of best practices might be a requirement of certain methodologies.)

Posted: Tue Oct 03, 2006 1:26 am
by Christopher
timvw wrote:(I find the methodology vs best practice discussion useless, since they're not orthogonal. Following a methodology can be considered as a best practice in some domains, where the application of best practices might be a requirement of certain methodologies.)
I don't think it is useless -- in fact I think it cuts to the heart of the misunderstanding and resistance to Methodologies and Best Practices. The are not opposed to each other; they similar but distinct concepts. It is thinking of Methodologies as Best Practices that is the problem.

A Methodology is a documented process. A Best Practice is the right process to employ in a given circumstance. Many, but not all, Best Practices are documented Methodologies. Many, but not all, Methodologies are Best Practices in the proper circumstances.

Using the collected experience of the best and brightest in our profession to employ the right process in the proper circumstance is wisdom. But taking that same information and employing the wrong process in a given circumstance is ... a learning opportunity.

Posted: Tue Oct 03, 2006 8:40 am
by Buddha443556
timvw wrote:I find the methodology vs best practice discussion useless, since they're not orthogonal.
I don't agree. I think Hockey is just trying to figure out what his best practices are that he's using. That can be rather difficult for a solo developer. Most methodologies are geared towards teams and medium to large scale development. They don't scale every well to the needs of the solo developer.

Which is why I'm more interested in the fundamental practices. For instance, XP, Agile and RUP all try to manage requirements to some extent by understanding stakeholder needs. XP/Agile and RUP definitely differ in there focus on the stakeholder needs. However, the underling fundamental principle is the same - to manage requirements one must understand the stakeholders needs. Understanding these fundamental principles help me as a solo developer to make changes to my methodology for the better.

Hardly a useless discussion.

Posted: Tue Oct 03, 2006 9:21 am
by timvw
Buddha443556 wrote:Most methodologies are geared towards teams and medium to large scale development. They don't scale every well to the needs of the solo developer.
I'm not aware of methodologies that dictate how large a team should be. What most methodologies do seem to do is differentiate between 'roles' in a team. And yes, in a one-man-team that means you have to fullfill all those roles...

Posted: Tue Oct 03, 2006 9:45 am
by patrikG
SCRUM recommends a max of six people per team.

Posted: Tue Oct 03, 2006 9:55 am
by Buddha443556
What most methodologies do seem to do is differentiate between 'roles' in a team. And yes, in a one-man-team that means you have to fullfill all those roles...
I'm not quiet sure but I think you just made my point!? :D