Methodologies versus Best Practices

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post by onion2k »

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.
Pair programming definitely doesn't. :wink:
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

patrikG wrote:SCRUM recommends a max of six people per team.
That's because the dialy quarter of chatting with the other victims of evil management could lead to riots if there are too many participants ;)

Overhere it's pretty hard to organize, since half of the team members are early-birds and start around 7.30 while the other half only starts around 10.00.. Anyway, what is does give us is that we have a better tool to measure the influence of changing business requirements on the development of the product....


<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>
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

timvw 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>
http://www.martinfowler.com/articles/ne ... ology.html
(#10850)
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Google Video has a nice presentation about SCRUM by Ken Schwaber at the Googleplex

http://video.google.com/videoplay?docid ... 6191025011
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Buddha443556 wrote:I think Hockey is just trying to figure out what his best practices are that he's using.
Yea, actually, never occured to me in such clarity until you said that...thanks...that will help a lot now in organizing my list.
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.
Although I am solo, I have worked remotely on very short/small projects with another developer...

I am trying to absorb as much as I can about team development (just bought several books in a value bin) and apply those principles to my solo career, in hopes that I can eventually turn a remotely managed team into a single entity. The hardest part is finding other talented people who share your vision :P
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 actually just started reading XP Explained by Kent Beck and that is exactly the impression I have been left with...

Basically there are three types of programmers:
1) Self-taught developers who usually start quite young, learning basic programming principles early on and then either plateau or move into other areas such as lower level languages, systems development, graphics, games, etc. These are what some might call "Cowboy" developers as they are more hackish in development, as opposed to very structured, formal and disciplined developers (Hardpressed to use TDD, etc)

2) Academia professional. Typically gets into software development sometime around senior high school level and decides to enter computer science, etc. They don't have years of experience under their belts, so everything they learn, they appreciate and take to heart as their instructor tells them too. Much of what they learn is theory and some best practice (code reuse which is kind of a universal truth, but still) the curriculum typically covers topics such as Advanced data structures, alogirthms, etc. You learn what a binary tree is and study existing libraries like STL. You learn about finite state machines, sometimes systems internals (depending on the teacher) and learn usually archaic languages and technologies. PASCAL was still taught when I was in high school. They learn very little real world experiences (again likley depends on instructor, etc) outside of that which they learn on their own during free time developing software.

The can typically be picked out of a crowd, by claiming such things as knowledge of language X, Y and Z to boot and having examples of code modeling Singletons or demonstrating the pricniples of OCP or perhaps code which generates a calendar or calculates the time it takes for light to travel from the sun to earth :P

3) Industry experienced veterans. They have some acadamia background, but what they learned 20 or 30 years ago is no longer really relevant. They have learned from experience and are likely very skilled developers. They are somewhat of a conglomeration of types one and two with actual 'industry' experience behind them. They have plateaued long ago and so started looking at the bigger picture of software development (abstractions, etc). Because of their lengthly expeirnce, they have knowledge of yester-years best practices and have take those into consideration when theorizing about newer, cutting edge practices.

I've personally gone through each one (excluding the latter as I only have a few years industry experience) and have seen and witnessed first hand how the cultures, outlook, etc are quite different from the next...

It's funny how self taught developers are usually quite sure of their ways and perhaps rightfully so, but resist anything academia, typically re-inventing (attempting to) the algorithms already invented to solve problems (I'm guilt of this myself, I basically learned everythin I know about compression by trial and error and some thought only later reading about Huffman and others and seeing how close I was to existing solutions).

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.

Agile, XP, TDD, etc...I can really see the years of industry experience talking as they also really promote the client side of things into the whole software development life cycle or equation, which I think is what is so foreign and boring to pure developers. Most developers don't care what clients have to say, they just want to write cool code, understandablly so. Because of this, many of the best practices also slip them by, and is likely why TDD is such a misunderstood concept.

I think Agile, XP etc...are over hyped that way. Many of the principles don't apply to lone developers or people only interested in programming. I think what is needed is someone to write a book of best practices, but completely exclude the boring points about business (personally I'm fascinated by that, but haven't always been so I can understand the oppressive mindset) and focus strictly on the developer specific needs and best practices...

One thing for sure, going on what i've read in various forums, asked from Agile enthusiasts and those wh oppose the idea...I think both parties are really mis-understanding each other. Business oriented developers have to understand that not every developer is going to want to write successful software, at least no by the definition given in the Agile books. How many programmers really interact with clients? I would say few and I would think most prefer it that way. Most developers I've known are not exactly people "people" if you know what I mean. 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.

1) You love it
2) You hate it

Again, because not every developer wants to interact with clients, they just want to do what their best at and that's write code. Agile principles can and should apply to them, but without their knowledge, which IMHO a good project manager could influence without anyone being the wiser their being subjectied to such "questionable" practices.

Anyways, I must get back to reading and replying.
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...
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.

I don't think they are advocating XP would apply to *every* situation, but rather typical situations. It wouldn't work under situations where your writting mission crictical applications (missle navigation, brain scan, operating system, etc) for those, time is typically not of the essence and exacting standards cannot be left to chance.

They are too complex for Agile, but those definetaly aren't the norm, so Agile/XP, etc apply well in "typical" situations.

Hope what I've said has made sense, I look forward to reading the 5 books I got today...A book a day...keeps me happy in everyway :P

Cheers,
Hockey (aka; newest XP/Agile enthusiast)
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

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.
Basically, you're not blindfully following but you're combining your own experiences with the so called 'wisdom/knowledge' others have gathered...

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).

What disturbs me is the fact that when someone like Fowler or Spolsky only farts people are already hyping about it... but this seems to be a general trend in IT :(
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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.
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.

You can't change a company's culture overnight...
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

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).
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.

XP is how I've always developed software, having hated wasting so much time on a design only later to discover a fault in architectural, etc design and have to scrap most of it...

When I reached the point of say a moderate developer while programming Windows 3.1 applications using VB...I was of the mindset that changing code during development was dangerous and obviously foolish in approach...it wasn't until I contacted a fellow Flight Simmer who had already developed tons of cool software tools (Enno Borgestead???) and I asked him if changing code was a common practice. He explained it's very common and basically introduced me to the world of refactoring. Since that fateful day i've practiced continous refactoring...and it's improved my ability as a developer ten fold.

I don't mind learning from others, I've just unfortunately learned most everything on my own because of lack of resources, contacts, etc....I dropped out of high school early, because I was interested in learning to fly (should have heard the kids laugh at me when I used that as an excuse for my teacher :P ). Most of what I know has been hard lessons learned over the last decade and a half. When I read books like XP and the author is basically formalizing what I've always personally thought was true...

It's a breathe of fresh air to know I'm not alone. The idealism behind XP translates nicely into the world of aviation as well. I'm obsessed with flying and the practices of professional pilots and I can clearly make analogies between the two, so I must say, I'm happier than a pig in s*it right now. :P
You can't change a company's culture overnight...
Nope, but you can change a single developer...so being a sole developer does have it's advantages :P

Honestly, one of my biggest complaints about the industry...is so many developer firms have some yahoo who is all business and no programming...so they allow crufty code...working under the assumption that as long as a application works and the client is happy, that is all that matters...

This is clear in so many existing PHP applications where the program works good and clients are typically happy, but the backend is such gibberish, if any client gained the know how, they'd likely stop doing business with them immediately...

I've worked on a few known commercial PHP projects both in my free time, making suggestions/code changes and as a hired gun to get deadlines met. The culture was cool and supportive, many of them have nice offices with plush couches and playstations, etc...which is grand...although meaningless to an outsourced developer :P

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...

Obviously they all do something right, whereas I have clearly done something wrong...as I have acheived only moderate success and most others are fully licensed, registered & incorporated businesses...the fact is...none of those work environments interest me enough to bother even applying. I'd rather do my regular boring stupid and mindless day job for now until I get my own business off the ground and properly... :P

Over the last 4 years I have become obsessed with getting my own cultured style business off the ground...one which changes rapidly when needed, but changes only when it makes sense. Evolution at this human cognitive level is what has allowed humans to supersede natural selection and allowed us to macro evolve instead of micro evolution. Whereas 'life' just changes for the sake of changing, sometimes for the better and others for the worse...changing when it only makes sense is the real magic in being human.

Sorry about that part guys I just read a stupid book on evolution :P it was really ghey...called "Everything you think you know is wrong" or something to that effect...some points were interesting...and others just silly :P

I'm done ranting or whatever the above would fall under :P

Cheers and thanks for listening...everyone else around me thinks I'm just hot air...

edit patrikG: Leave any references to drugs out, please.

Cheers part deux :P
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post by onion2k »

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 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:

Noone wants to work with a boring git who does nothing but the job.

If you're in a team you need to be able to relax and take time out. It's great to be driven and motivated to work on code all the time, but who are really like that are very rare indeed, and people who think they're like that when they're not are on the fast track to burning out. Seriously, there's a lot more to life than writing the best applications you can.

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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Awesome projects happen in your spare time.
I definitely didn't get involved in an AJAX based web game project by sitting in my cubicle reading a client specification report...;)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

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.
I didn't explain my self properly I guess...

It's not the project which makes for an interesting project, although it does help. It's the culture and the quality of code, etc I find makes a project interesting...

I'm very business oriented...so applications like knowledgebases, CRM, ERP, CMMS, etc...

i design and develope those in my spare time anyways, so business software is right up my alley :P

I'm not sure what you define as "awesome" projects, but PHP games certainly don't do it for me...although I don't play games, so thats probably why...I see very little practicallity in developing games in an environment such as PHP...

You would be (correct me if i'm - i probably am) limited to pretty much RPG's which I've always found extremely boring...you need patience and the ability to think creativly like a game designer or have read novels like Lord of the Rings, etc... :P

Seriously no joke, my mom and sister love those games...and love novels like Lord of the Rings...my sister would play Link on the NES for days on end...and I could never understand the excitment in walking around talking to dragons and solving such silly puzzles. :P Although, I found even fewer people enthusiastic about planning a flight from Vancouver to Hong Kong and then watching a screen refresh 18 times per second for the next 12 hours, while monitoring instruments, etc... :lol:

I lost a few friends while requesting they sit down and play my co-pilot :P

Anyways, the point...what was the point? :P Oh yea, RPG sucks... :lol: business applications are a blast to develop, but the environment is absolutely key for my interest. I would have no problems working on an RPG as long as the detailing plans were kept out of sight and I focused strictly on code and architecture, etc...

Programming is my life, passion and love I have dedicated everything I have emotionally, physically, spiritually and financially to my passion.

What is good for the goose is not always good for the gander ;)

Cheers :)
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Hockey wrote:Anyways, the point...what was the point?
"Methodologies versus Best Practices". Time to get back on topic.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

patrikG wrote:
Hockey wrote:Anyways, the point...what was the point?
"Methodologies versus Best Practices". Time to get back on topic.
A methodology can be considered a best practice so they are not really competing.
Post Reply