This is an off-shoot of this post ==> https://www.nairaland.com/nigeria/topic-878253.0.html (please read that thread and understand what is being discussed before contributing):

Fayimora:


,
Developing something like amazon is DIFFERENT. There is a much higher level of abstraction in such a project. For instance, I would do something like:

- Make static pages available, integrate a blog/update system
- implement store with primary features
- include a few novel implementations to store
*** Deploy starter application!
- Implement rating system and deploy
- Implement recommendation system and deploy
- Implement search engine and deploy

. . . . and so on and so forth. We can also go into a much higher level of abstraction. By the way note that am talking from the implementation side of things.

Have your customer with you at all times? NO. Absolutely not. You only need you customer with you at certain times which are before, inbtw and after(not always true). Your customer tells you what they want --> you make stories out of it --> You tell them what you can deliver and when --> Halfway thru you present what you have, make sure you are on the right line and revalidate the tasks -->You deliver when the time comes --> and then you go over the cycle again.

Waterfall methodology MAINLY works for those with the resources(mainly financial but other things count). A small startup would care less because they provide in stages. Facebook wasn't built at once! WHere would Mark have gotten the resources from?? However Twitter was! Dorsey had enough money, not to talk more about the funding he got!

Anyways, we should probably continue this somewhere else so we don't derail this thread

Shouldn't you start with abstractions and work your way down (considering you might be using rails) --- and where does testing fall?

Cant understand why this bot still bans mods, Anyways I have posted something so you would have to wait until I can get it unmarked as spam. . .

^^ you'd probably find a few of my post stuck in limbo there too, if you can unspam those too.

Fayimora:


To be honest with you. I only say I use Agile because after reading about the process lat year, I realised thats how I always worked. AFAIC, those are just buzzwords. Oh yeah they are METHODOLOGIES! I just develop my way and if someone decides to give it a name then good for them. . lol .

I think those words are overhyped! Especially that pair development thingy(I think its extreme programming), they program in pairs cause they are crap alone! #JustHating

LOL. Agile itself is an instance of Extreme Programming, which itself is an instance of Iterative Methodology. So this means that Agile also features Pair Programming which is one of the features of Extreme Programming. So if you are not doing Pair Programming, you are most likely not doing Agile.

logica:

, So if you are not doing Pair Programming, you are most likely not doing Agile.

^^ I'd disagree, see the Agile Manifesto (http://agilemanifesto.org/principles.html)

We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

,  tell me why a sole developer cannot achieve these (in fact it's probably easier). In my experience, [XP] PP can sometimes be a drag.

logica:

, So if you are not doing Pair Programming, you are most likely not doing Agile.

^^ I beg to differ, see the principles of the Agile Manifesto

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Ref: http://agilemanifesto.org/principles.html

How is PP a pre-/requisite?

I said Pair Programming is a feature of Agile Programming; will you expect a feature to be mentioned as part of the generic tenets? Pair Programming itself is a tenet of Extreme Programming of which Agile Programming is a type (depending on the source XP is the super-set or the subset). You will notice I said "most likely".

I can say the inconsistent documentation is simply due to the fact that XP predates Agile, and may have been retrofitted to fit in with the group of Agile implementations.

Even if we agree that XP is a form of Agile, it will still be the most widely used implementation of Agile (hence the expected feature of Pair Programming).

You should also note these methodologies expect a team. So if you are solo, you are obviously not using XP/Agile.

Anyway you need to properly understand Pair Programming and to use it properly to appreciate it. If you are the type that likes to write all kinds of unstructured code, you will of course not like it.

"That?" . . .Ambiguity is strictly forbidden in the software World.
Can a man who doesn't know what a design or technical spec is possibly grasp software engineering concepts like Agile or XP?
Just my twopence.

I'm outa here.

logica:

1 => I said Pair Programming is a feature of Agile Programming; will you expect a feature to be mentioned as part of the generic tenets? Pair Programming itself is a tenet of Extreme Programming of which Agile Programming is a type (depending on the source XP is the super-set or the subset). You will notice I said "most likely".
,

2 => You should also note these methodologies expect a team. So if you are solo, you are obviously not using XP/Agile.

3 => Anyway you need to properly understand Pair Programming and to use it properly to appreciate it. If you are the type that likes to write all kinds of unstructured code, you will of course not like it.

1. Superb clarification on #1, can't be overstated. I should however point out (as you've done earlier, vaguely) Agile extracted the best of these following designing methodology: Extreme Programming (per Kent Black's), SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming (as described in Andy Hunt's 'The Pragmatic Programmer: From Journeyman to Master.), there are notable flops to them all ( and in fact one of XP's flop was the need for PP) -- a very good read might be: http://agilemanifesto.org/history.html

2. See point #1, no, it's not obvious. I used pivotal tracker reasonably (www.pivotaltracker.com) which premises you are agiling (unless you think the customer as part of the team, which Agile assumes they "kind of" are).

3. Ditto point #1.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf[10] and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment (ROI) and ensuring alignment with customer needs and company goals.

http://en.wikipedia.org/wiki/Agile_software_development

So as you can see, Agile does not assume the customer is "kind of" a part of the team.

^^ I said "kind of" because often, it's not feasible to have a customer on-site all the site (either because of budget-constraints or just being a jerk, anyways, that's why tools like PivoTkr is great, you can let your "customer" tell their "stories" and you develop around that). But yes, it's centered around customer requirement and a sole developer can still pull it off.

I should add, most software framework these days (especially MVC/ORM/AD-based) almost force you to Agile (notoriously Cucumber on Rails). Get your customer need(s), develop your Model(s) -- put their stories in the controller's logic, show them a completed part (in some View of some sort) <--> Repeat (assuming you're not strictly doing BDD/TDD, I often don't >.<).

It will be tough to have a single developer work on an Agile project.

The customer rep I mentioned does not need to be affiliated with the customer, but he needs to understand the customer needs to a tee. Without this, you will end up developing software to your own taste and not to the customer's taste which might lead to rejection of the software and wasted effort (having to go back and redesign, etc). So somebody has to be there to keep an eye as things progress and speak from the POV of the customer.

And there is a conflict of interest if a developer also serves as a customer rep (this usually leads to the developer trying to force-feed the customer so as to make his work easier and he being a techie might tend to ridicule the customer's preferences/POV; but of course the customer knows exactly what he wants so there may be conflict). There is a reason the standard size of an Agile team is 8-10 and the debate on the optimal Agile team size (ranging from 5 to 15).

Now back to Pair Programming.

My first experience with it was about 10 years ago and initially it felt awkward, but then I very quickly began to see the benefits.

Firstly, there is always that stage immediately after coding called "Code Review". How often do people actually do that? It usually ends up being skipped because a lot of work needs to be done and code review can be very tasking and time consuming especially if you leave it till all coding is complete. But what Pair Programming does is, it embeds code review right in the coding cycle, not after. The observer is always doing the code review (even as the developers switch roles/places). So I was not surprised to see this:

Some studies have found that programmers working in pairs produce shorter programs, with better designs and fewer bugs, than programmers working alone.[2] Studies have found reduction in defect rates of 15% to 50%, varying depending on programmer experience and task complexity.[3][4] Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs; they also catch design defects early.[5] Pairs usually complete work faster than one programmer assigned to the same task. Pairs often find that seemingly "impossible" problems become easy or even quick, or at least possible to solve when they work together.

http://en.wikipedia.org/wiki/Pair_programming

If you read the entire page, you will see some more research results on Pair Programming.

There are way more advantages beside embedding code review in the code development cycle, and the other major one is knowledge sharing/transfer (and it can be bidirectional).

logica:

1 => It will be tough to have a single developer work on an Agile project.

2 => The customer rep I mentioned does not need to be affiliated with the customer, but he needs to understand the customer needs to a tee. Without this, you will end up developing software to your own taste and not to the customer's taste which might lead to rejection of the software and wasted effort (having to go back and redesign, etc). So somebody has to be there to keep an eye as things progress and speak from the POV of the customer.

Now back to Pair Programming:
3. => Firstly, there is always that stage immediately after coding called "Code Review". How often do people actually do that? It usually ends up being skipped because a lot of work needs to be done and code review,
http://en.wikipedia.org/wiki/Pair_programming

4. => There are way more advantages beside embedding code review in the code development cycle, and the other major one is knowledge sharing/transfer (and it can be bidirectional).

#1. I disagree, on enterprise projects, YES, otherwise, NO. (research has it that the maximum code base a developer can understand is ~10,000 lines). Don't forget that this methods assumes a significant level of experience, either way, it could be a very bad idea enterprise or not.

#2: That is a quandary. The point of agile is to involve the customer, not a rep, a customer with direct stake in the outcome of the project, as summerized:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

#3. I have no problem with PP, though I don't see the need for a developer sitting over another's shoulder and probing design/algorithm choices (a recipe for fist fights ) on a micro level when tool like GitHub could let you do in-line code review per commits. Just encourage best practices, have a team mentor and everyone check-in often.

#4. Extending #3, you can even, with github in-line code review turn those knowledge into documentation for future generations; that probably beats having to deal with some developers bad breath all day .

delomos:

#3. I have no problem with PP, though I don't see the need for a developer sitting over another's shoulder and probing design/algorithm choices (a recipe for fist fights ) on a micro level when tool like GitHub could let you do in-line code review per commits. Just encourage best practices, have a team mentor and everyone check-in often.
.

No it does not work that way, the way it works is that today one developer sits and watch the other do the coding, then tomorrow the developer coding today sits and watch the developed that was watching yesterday, do the coding today.

The level to which an organisation can properly implement a Software Development Methodology and its continuous improvements, will help to determine the level it gets for People Capability Maturity Model (PCMM) The levels ranges from 1 - 5, 5 being the top level. Organisations at level 1 are one man businesses, these cannot fully implement all the processes of an agile methodology or any of the other methodologies, 3 are those that implement proper agile processes and practices, level 4 and 5 will require a lot of resources in order to come up with improvements and new innovations to which ever methodology is being used. So the level to which an organisation can properly implement a Software Development Methodology will depend on its size and resources.

#1:

Maybe you don't understand my point here, but I am saying you need a team (not an individual) to actually make use of Agile. If you do understand my point and disagree, all I can say is I think the assumptions made by Agile are clear enough on this.

#2:

Once again:

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf[10] and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment (ROI) and ensuring alignment with customer needs and company goals.

http://en.wikipedia.org/wiki/Agile_software_development

So once again, the customer representative is NOT the same as the customer (hence the term representative). He of course simply REPRESENTS the customer and his interests since the customer is not part of the team. The customer representative of course fully understands the customer's needs and interfaces directly with the customer (liaison). So indeed the customer is involved THROUGH the customer rep.

#3:

If there is a good rapport, then there shouldn't be any "fist fights". It would not make sense to pair 2 people who don't get along anyway. And "fist fights" will occur in any team even without Pair Programming if they simply do not get along. So that is not a problem with Pair Programming but with the developers (poor interpersonal skills).

@logica: Oh, I see your point now, not disagreeing to that.

Per #3, PP is great like you said, when there's good rapport (and the dev're are skilled) and every dev'er knows their "pair" is not trying to flex "chop" (more often than not they are and end up arguing over trivialities).

@csharpjava

csharpjava:

No it does not work that way, the way it works is that today one developer sits and watch the other do the coding, then tomorrow the developer coding today sits and watch the developed that was watching yesterday, do the coding today.

Is this really efficient? I think switching programmer after milestones (but then, that's from my xprince).

Never seen this PCCM thing before, so much to learn, so little time (*sighs*). Can you send me a reference paper or link that expatiates on this? Your point on it wasn't very clear too, please clarify.

No no no. csharpjava has just told you exactly how Pair Programming works. You don't switch after milestones; rather you switch OFTEN (as recommended). He indicated a switch cycle of daily but it could even be much shorter than that - such as every hour or even every 10 minutes! The idea is to get both developers comfortable in the role of driver and observer otherwise you can quickly get too comfy in one role and be reluctant to switch. The frequency of the switch also increases the interaction between the developers and keeps both of them sharp, awake, creative, involved and focused on the task and makes the task seem less tedious. You should know how it is when you've been working on the same task for an extended period. When you work this way, you will see you are less prone to distractions and you will take less breaks from working on the task.

In regards to efficiency, once again please read this page:

http://en.wikipedia.org/wiki/Pair_programming

Some studies have found that programmers working in pairs produce shorter programs, with better designs and fewer bugs, than programmers working alone.[2] Studies have found reduction in defect rates of 15% to 50%, varying depending on programmer experience and task complexity.[3][4] Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs; they also catch design defects early.[5] Pairs usually complete work faster than one programmer assigned to the same task. Pairs often find that seemingly "impossible" problems become easy or even quick, or at least possible to solve when they work together

^^Continuing down the article:

,
However, a 2007 meta-analysis concluded that "pair programming is not uniformly beneficial or effective" because many other factors besides the choice of whether to use pair programming have large effects on the outcome of a programming task.[7] The meta-study found that pair programming tends to reduce development time somewhat and produces marginal positive effects on code quality, but that pair programming requires significantly more developer effort; that is, it is significantly more expensive than solo programming. The authors suggest that studies of pair programming suffer from publication bias whereby studies that would not show that pair programming is beneficial were either not undertaken, not submitted for publication, or not accepted for publication. They conclude that "you cannot expect faster and better and cheaper."

Even though coding is often completed faster than when one programmer works alone, total programmer time (number of programmers × time spent) increases. A manager needs to balance faster completion of the work and reduced testing and debugging time against the higher cost of coding. The relative weight of these factors can vary from project to project and task to task. The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[8] On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity. Productivity can also drop when novice-novice pairing is used without sufficient availability of a mentor to coach them.[10]

And, to the issues I slightly raised earlier (now per the [wiki] link):

Disengagement
Watch the Master
Silence

Now, to rephrase my question, how efficient it this for a small software company with constrained budget (and considering the potential for those 3 problems)?

Of course not everybody can benefit from Agile/XP and this includes those with financial and skill constraints. But if you take the reduction of defects which have to be later resolved that's some worthwhile savings.

And reading further down in your quote from the wiki, it is clearly stated that PP delivers best when the task is relatively new (such as is usual with initiating a new project from scratch) and complex to both developers and not when both are quite familiar with the task and/or it's a trivial task.

As they said, "you cannot expect faster and better and cheaper".

And with the issue of bad breathe, maybe the exponents of PP should encourage the habit of distributing mint at the stand-up meetings.

delomos:

#3. I have no problem with PP, though I don't see the need for a developer sitting over another's shoulder and probing design/algorithm choices (a recipe for fist fights ).

I missed this earlier but I had to backtrack to make a comment. If this is also from your experience with PP, then I can say the teams you've worked on definitely did not properly implement the Agile/XP methodology. So apart from switching pairs on a milestone cycle, you may have gotten things pretty wrong.

Developers should not be probing design and algorithm choices in the Coding cycle! They should simply be coding according to the agreed design arrived at in the Design Cycle. At this point, I expect all the developers have are a bunch of UML diagrams (class, sequence etc). All the driver does is code these, while the observer reviews the code as he (the driver) works to ensure it fits with the design and in so doing might notice design flaws requiring design changes. But neither of them can unilaterally change the design/algorithm; this has to be reported/escalated at the stand-up meeting and then the design will be changed if necessary.

logica:

,
And reading further down in your quote from the wiki, it is clearly stated that PP delivers best when the task is relatively new (such as is usual with initiating a new project from scratch) and complex to both developers and not when both are quite familiar with the task and/or it's a trivial task.

Some of the precise argument against PP, how many times are teams working from scratch? And. ,

logica:

,

Developers should not be probing design and algorithm choices in the Coding cycle! They should simply be coding according to the agreed design arrived at in the Design Cycle. At this point, I expect all the developers have are a bunch of UML diagrams (class, sequence etc). All the driver does is code these, while the observer reviews the code as he (the driver) works to ensure it fits with the design and in so doing might notice design flaws requiring design changes. But neither of them can unilaterally change the design/algorithm; this has to be reported/escalated at the stand-up meeting and then the design will be changed if necessary.

>> I want to be sure I understand this clearly, the pair reviews a code the driver is typing (without making suggestions)?

delomos:

Never seen this PCCM thing before, so much to learn, so little time (*sighs*). Can you send me a reference paper or link that expatiates on this? Your point on it wasn't very clear too, please clarify.

People Capability Maturity Model (People CMM)  was developed by the Software Engineering Institute. PCCM is a method by which organisations are graded based on the way they manage, develop and use their people for developing and maintaining software.You can find out more about People CMM from the Software Engineering Institute. The best way for an organisation to find out if they are following the correct processes and practices of developing their software without cutting corners, will be for them to sign up for an assessment with the Software Engineering Institute.

csharpjava:

, correct processes and practices of developing their software without cutting corners will to sign up for an assessment with the Software Engineering Institute.

Feels like it's violating a principle there (and I can imagine its going to be quite pricey): 'Working software over comprehensive documentation'

Or what Steve Krug might call "the Big Honking Report" (http://www.sensible.com/dmmt.html).

delomos:

Some of the precise argument against PP, how many times are teams working from scratch?

I have worked on about 12 projects in my career and out of which 10 were full SDLC projects. Even the other 2 were simply not full SDLC because I joined after inception. Several were upgrades meaning redevelopment using a new and better design while mostly jettisoning the previous design and code. So I can state based on my experience that a lot of projects are "from scratch".

delomos:

I want to be sure I understand this clearly, the pair reviews a code the driver is typing (without making suggestions)?

I believe I made that point clear enough, but let me do it again.

Programmers (who form the pair of driver and observer in the PP) are NOT responsible for design. Once again, their responsibility is simply to code the designs handed to them which are usually well represented using UML. The responsibility of design falls on the Senior Developers/Architects and to whom design flaws are escalated if any are found in the coding phase. So I don't see how either of the pair can critic the other on design when all they are doing is code implementation and code review.

http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

I remember my last company was CMMI Level 3 certified. CMMI was the biggest buzz word about 6 years ago.

^^

logica:

,
, The responsibility of design falls on the Senior Developers/Architects and to whom design flaws are escalated if any are found in the coding phase. So I don't see how either of the pair can critic the other on design when all they are doing is code implementation and code review.

So technically, these are just code monkeys, banging out code (and this sounds more waterfall-y if the programmers that will be implementing have no say in the system design)-- my question is specially direct at a small [web] software monkey.

Your case seem to be assuming a big company with huge resouces.

"CMMI" is definitely off-topic here: "CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University." (from your link above).

And as a side-note, you're quite lucky you're not "inheriting" legacy codes or working up on frameworks.

The methodology does not determine a programmer's tasks; the designation "Programmer" in itself has its meaning. Even in a small company, if a "Programmer" is responsible for application design, something is wrong somewhere. Even in a moderately sized team of say 8-10 members, you should have Programmers, Developers, Senior Developers, Architects, Testers and Customer Reps. There is a clear boundary and separation of responsibilities.

logica:

http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
I remember my last company was CMMI Level 3 certified. CMMI was the biggest buzz word about 6 years ago.

I was just about to post it here that you must have worked in companies that are PCMM level 3 to level 5 certified. I came to know about this PCMM or CMMI in my final year of SE at Uni. The advice my lecturer gave us was to look for company's that are level 3 and above certified when starting our careers in software development. He went further to tell us that level 3 companies are the ones that have properly implemented the processes and practises of agile methodology and that companies with level 4 - 5 are at a more advanced level in the way they implement the processes and practises of agile and other software methodologies.

delomos:

"CMMI" is definitely off-topic here: "CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University." (from your link above).

I disagree. PCMM or CMMI certification are not for the US only, Companies outside of the US have obtained different levels of certification, there are some software organisations in India that are PCMM Level 5 certified. When it comes to bidding for top software contracts at home and worldwide then a company's level of certification matters as it shows that the software organisation are following the proper processes and practises of the different software methodologies that are available. Just out of interest, which of the software organisations in Nigeria are PCMM or CMMI certified?

@Logica & @csharpjava, you guys are head on ,

About agile, apart from all you guys have said there's a fundamental property which agile breaks : OWNERSHIP.

[list]
[li]It removes ownership, first from a single developer or a group of developers. So you can't sit on code and not let others review claiming "I'm working on it".
[/li]
[li]It enforces standards, if everyone is authoring a document, then it has to be done the way EVEVRYONE wants it. It would also make the code "probably" simpler or better because there's consensus.[/li]
[/list]Then finally the frequent release/milestone. Manages risk, no "big baang" approach that bring surprises when the customer has rejected 6 months of work.

Agile practices manages the most risky part of software development : Change in all forms

And yeah lots of Indian companies are CMM LEVEL 5, they need it to bid with the big boys (They use it as a leveler to compete with US firms).
A lot of people believe it hasn't achieved what it set out to do.

delomos:

^^So technically, these are just code monkeys, banging out code (and this sounds more waterfall-y if the programmers that will be implementing have no say in the system design)-- my question is specially direct at a small [web] software monkey.
And as a side-note, you're quite lucky you're not "inheriting" legacy codes or working up on frameworks.

Funny enough, there are very few ways of writing good code. Everyone(?) knows good code when they see it. The developer(or code monkey as you call it) has a lot of freedom in implementation. The Architect  largely defines boundaries. So yes, selection of frameworks and APIs is mostly architectural. 

I've inherited a lot of legacy code in different respects, and i believe it made me better. I see solid design choices that'll make you whistle and bugs that'll make you wonder if the programmer went to elementary school, all in the same body of code. That's the reality we live in.