Posted: Tue Oct 03, 2006 10:14 am
Pair programming definitely doesn't.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.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
Pair programming definitely doesn't.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.
That's because the dialy quarter of chatting with the other victims of evil management could lead to riots if there are too many participantspatrikG wrote:SCRUM recommends a max of six people per team.
http://www.martinfowler.com/articles/ne ... ology.htmltimvw wrote:<something on-topic :p>
(If i'm not mistaken, there's a nice article about 'new methodologies' on martin fowlers bliki...)
</something on-topic :p>
Yea, actually, never occured to me in such clarity until you said that...thanks...that will help a lot now in organizing my list.Buddha443556 wrote:I think Hockey is just trying to figure out what his best practices are that he's using.
Although I am solo, I have worked remotely on very short/small projects with another 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.
I actually just started reading XP Explained by Kent Beck and that is exactly the impression I have been left with...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.
I'm reading the XP book by Kent himself and I'm sure I just read it's applied best to small teams (2 to 20 developers) but instead of large, strictly managed inexperienced developers, XP prefers small, tight knit, more experienced developers. It's also a cultural change from what I can tell or from what I've read in that, the setup is almost analogous to a token network. Whereas yester-years SDLC used waterfall type approaches, has a more genealogical or structured hierarchy, which makes it difficult for team members to learn from other team members or communicate with those working on different area or levels of the project.timvw wrote:'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...
Basically, you're not blindfully following but you're combining your own experiences with the so called 'wisdom/knowledge' others have gathered...Hockey wrote: When I made the realization, thats it's likely best to learn from others mistakes and improve, rather than re-invent, it was a real change in mindset for me.
That is so true. Remember also that Fowler and others do note you should note attempt to force Agile on developers. You need willing subjects. Over here we generally communicate in terms of the discrete practices - TDD, PP, ID, etc and leave the other cruft to those higher up the food chain. As the need arises, we introduce folk to the other elements when it makes sense.Those interest in project management aspects however, would be wise to read up on Agile, etc...but those just wanting to code, should be informed of best practices (TDD, pair programming, etc) but without any mention of Agile or XP as they appear to have one of 2 effects on the developer community.
Well no, nothing earth shattering...neither are design patterns for the most part...many I've used without even realizing I've used them, but the fact they are formalized and I now know someone other than me sees software development this way (someone recognized as an industyr leader) is a boost of confidence in my own ego.timvw wrote: From that POV it's pretty hard to choose one of the 'love it/hate it' sides you mention. Personally i recognize some useful techniques in Agile (XP and scrum) for better project management. On the other hand, most of those techniques were already being used.. So it's nice someone has taken the time to formalize them, but they're not something radically new (at least not to me).
Nope, but you can change a single developer...so being a sole developer does have it's advantagesYou can't change a company's culture overnight...
I imagine from this that you've never worked in a code shop as a permanent employee before. Here's a word of advice for when you do:Hockey wrote:I guess unlike most of those company developers, I don't need or want a play station...I want a library (of books)...I want a challenging environment...I want to have come and go freedoms (I like working out or bike riding - but I need to feel it before I can do it) and most of all...I want to work on awesome projects with the best available developers and codebases, tools, etc...
I definitely didn't get involved in an AJAX based web game project by sitting in my cubicle reading a client specification report...Awesome projects happen in your spare time.
I didn't explain my self properly I guess...onion2k wrote:Another thing you need to realise: there are very few awesome projects. Unless you get into a company like 37 Signals who write their own applications to sell you'll end up writing what the clients want, and that's usually pretty dull. Awesome projects happen in your spare time.
"Methodologies versus Best Practices". Time to get back on topic.Hockey wrote:Anyways, the point...what was the point?
A methodology can be considered a best practice so they are not really competing.patrikG wrote:"Methodologies versus Best Practices". Time to get back on topic.Hockey wrote:Anyways, the point...what was the point?