Searching \ for '[OT]: Software developmentmethodologies(was[OT]Tec' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=
Search entire site for: 'Software developmentmethodologies(was[OT]Tec'.

Exact match. Not showing close matches.
PICList Thread
'[OT]: Software developmentmethodologies(was[OT]Tec'
2007\04\23@053938 by Tony Smith

picon face

{Quote hidden}

Fix it until it breaks, and then fix it again.

Tony

2007\04\25@000733 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
> It seems you're not working much for customers -- are you?

The project I've been working on for the past few months is for an external
customer. In the end, any project is for a customer -- even if it's you.

> Or are you doing
> more in-house development?

Most of the time, yes.

> Those are two quite different situations. I bet
> you won't easily find a customer who hires a team, pays the team, and just
> takes whatever comes, and says "well, if I can't get it all, I'll just be
> happy with less"... :)

I think you and Nate are missing the point.

By definition, projects involve uncertainties. If you remove all uncertainty
from a project, it stops being a project and turns into a manufacturing
activity.

With Agile, you still have a schedule and a plan. The difference is, Agile
recognizes the fact that schedules are guesstimates, and that plans tend to
change.

> Most want to have up-front a scope, a schedule and a price (with payment
> terms based on delivered scope and schedule). All three may be staged, but
> I haven't yet met a customer who was happy to pay and just take what he'll
> get.

You misunderstood what I said.

With Agile, you still define those things with the customer. You know that
you're working with limited resources, so you rank the features (with
customer's help) in order of priority, considering cost/benefit of each
feature, etc. You end up with a Users Guide, a requirement spec, whatever
else you end up with that you use for quoting.

With traditional "waterfall" development, you just follow these steps, in
the order shown, until the project is done:

1. Requirements
2. Design
3. Implementation
4. Verification
5. Maintenance

You have a schedule which reflects this. So you have a 10-month project, and
you divide the time up evenly, after 4 months you have nothing but paper.

With Agile, you have short development cycles (usually 2 weeks). You pick a
set of tasks (or just a single task) that you can complete in one iteration.
Each iteration includes test & debug phase, so at the end of the two weeks
you end up with fully functional, tested and debugged software.

Now, what I said was, if you're doing Agile development the customer can
easily terminate the project pretty much at any point. They can do that for
a number of reasons, for example:

- They ran out of money, or
- They decided that the software has enough features, and that the remaining
(low-priority) features are not worth spending their money on, or
- They decided to devote the resources to another project

Whatever the reason, you give the customer SOFTWARE THAT WORKS.

Depending on where you are in the waterfall model, you give the customer
either a pile of PAPER, or a heap of non-functional, bug-ridden, untested
code.

--> By the way, another advantage of Agile is that you can ship the product
early (whenever you decide that the feature set is sufficient). In the
meantime, you continue development and implement those fun and exotic
features you wanted to implement from the start.

Also, with Agile, you know from the start that the plan will change. So when
it happens -- customer changes their mind about which features they want
most, you encoutner some external limitation, etc -- with Agile you can turn
on a dime, figuratively speaking. With traditional development, your
schedule and your plan come crashing down at the first sign of change.

>> With traditional development, the customer may end up with a pile of
>> out-of-date documentation, and software with lots of features that don't
>> work.
>
> Same can happen with Agile -- just the docs will be missing :)

Not true (see above).

> Believe me, you've got to do it right. If Agile helps /you/ to get there,
> that's very good. But it might not be that helpful for someone else.

What does "right" mean to you?

> Again... are you bidding for paid projects? There /is/ a difference
> between
> in-house projects and for-hire projects. With in-house projects, you trust
> the team -- it's the team you have --, and if things don't go with that
> team, they just don't go (or you increase the team). With for-hire
> projects, this tends to be different.

I don't understand why you bring bidding into this. You make your educated
guesses, bid on the project, and THEN development begins.

>> I will take "never-ending small Agile cycles", each of which results in
>> WORKING software, over any of the the waterfall methodologies, anyday.
>
> See, maybe this is our misunderstanding. I see a world of possibilities
> between and around Agile and Waterfall -- it's not an either-or situation.

I'm not married to Agile. I don't even have much experience with Agile. It
just makes sense to me. For those of you who are familiar with Eli
Goldratt's ideas, I believe that Agile is an extension of Critical Chain, as
applied to programming. Improve the process repeatedly.

I look at past projects and see that projects that were done in the "Agile
spirit", succeeded. Others, where we spent months documenting and speccing
out every little detail, failed. I read about the same thing happening to
other companies, all the time.

What I'm trying to do now, is consciously practice the common-sense Agile
principles.

>> Why do you think scope clarification and overall effort and schedule
>> estimates are not part of Agile?
>
> Because you may need to decide the scope of the delivery after the eighth
> iteration cycle before you start with the first. That's not Agile.

You can do the quoting the "traditional" way, then switch to Agile for the
actual development. Your up-front estimates will always be wrong, anyway. If
that's not true for you, you're not in the project development business.

> For
> Agile, you need a customer (or boss) who wants to work Agile. That's a lot
> easier to find with in-house work than with work for hire.

Sure, having a customer who wants to work Agile helps, but it's not a
prerequisite. I would have to agree with you on the boss part, as long as by
"boss" you mean person with decision-making power, closest to the
programmers.

>> What you're saying sounds logical, but my limited experience with
>> distributed development has for the most part been negative.
>
> I have largely positive experiences. But you need to adapt to the
> situation.

What kind of projects were these (complexity, duration)? How many people
were involved?

I'm genuinely interested in hearing about your positive experiences (maybe
you can start a separate thread?). My limited experiences with outsourcing
involved relatively small projects, requiring no more than one man-month of
effort.

>> "The most efficient and effective method of conveying information to and
>> within a development team is face-to-face conversation."
>
> This is true, if you only take the project. I, like most other people I
> know, don't live my projects, I work on them. I have other things to care
> for in my life, and the most effective method for running a project may
> clash with the most effective method of running my life. So again, it's
> about finding the overall maximum -- just with more dimensions :)

What if you already have people in the same building, what's the problem
then? Most companies work this way.

By the way, there are examples of executing successful distributed projects.
But you still have face-to-face conversation and theory building --  
documentation is not enough, you need to fly one of your team members to
Russia to explain the theory to the Russian programmers. Always-on video
links can also be helpful.

The problem with documentation is, some things are difficult to explain in
writing, and some are impossible.

>> If a bunch of smart, experienced programmers got together, and came up
>> with a simple set of principles that they all agree work, wouldn't you
>> want to at least investigate what their methodology is really about?
>
> What tells you that I didn't?

The comments you make about Agile, of course. I think you're confusing Agile
with a twisted version of XP.

> Besides, some of these smart, experienced
> programmers already left the Agile train and are now in post-Agile
> movements.

Who are those programmers? Which post-Agile movements?

> The whole software development methodology area is full of
> groups of smart, experienced programmers who have found something that
> works -- to some degree, under specific circumstances, and for certain
> purposes.

I'm yet to hear you offer an alternative methodology. What works for you,
personally? How do you approach a project?

What do you think works for other programmers?

> For Agile, two of the requirements that kill it for me in most cases are
> the physical proximity of the team members

That makes it more difficult, but certainly not impossible.

> .. and the fact that the customer
> has to want it and work in the Agile way.

Helpful, but not required.

>> You can label any set of useful principles "religion", and reject it on
>> that basis.
>
> Maybe you're getting a bit defensive here. I marked my respective comment
> with a smiley, it was in a tongue-in-cheek context from a previous message
> -- and I never said I rejected Agile, much less that I do it because I
> could label it as "religion".

It was Nate who said: "Welcome to the church. Agile is just another
methodology/religion."  The sentence above was my reply to his statement
(which you echoed). I'm not paranoid. :)

> I just think that while it has a few good
> thoughts worth thinking about and considering, it's not a silver bullet.

Brooks already proved that silver bullet doesn't exist, so no point arguing
it.

However, some methodologies are better than others.

Vitaliy

2007\04\25@022342 by Nate Duehr

face
flavicon
face
On 4/24/07, Vitaliy <spam_OUTspamTakeThisOuTspammaksimov.org> wrote:

> I think you and Nate are missing the point.

Not really - Agile doesn't fit telco very well... I'll explain...

> By definition, projects involve uncertainties. If you remove all uncertainty
> from a project, it stops being a project and turns into a manufacturing
> activity.

Which is *exactly* what telco customers want.  You don't *EVER*
release code that causes massive problems or outages into a production
telco network.  Phone calls are a 24/7 business.

This means changes are slow and gradual -- or -- an all out "all hands
on deck" push is made to a big new system, with insane amounts of
testing/certification done before the thing ever goes anywhere near a
Central Office.

Not to mention that in reality, a "manufacturing process" is exactly
what software companies claim that they're working toward, every
year... "code re-use", "object orientation", "virtual sandboxes"...
all of that crap is just another way of saying, "stable, reliable
changes that work".

Agile (to me, anyway) is just the latest promise from an industry full
of ADD poster-children who can't seem to ever learn to stick to one
thing and do it well, and are always chasing after... "oooh, shiny!".

> With Agile, you still have a schedule and a plan. The difference is, Agile
> recognizes the fact that schedules are guesstimates, and that plans tend to
> change.

Plans don't change in production telco systems unless they're in
writing and reviewed.  They are laid out and PLANNED ahead of time.
This is the point of a PLAN.

All changes are reviewed by both the Engineers involved, their
managers, a Change Control Board, and the customer.  When I say "the
customer", they have the same structured review by multiple people.

I think Agile tends to work well in organizations that lack the
DISCIPLINE to follow their PLAN.  Or perhaps who are stuck with
terribly undisciplined customers.

Telco can be frustratingly structure-bound, but at least our customers
know their priorities up-front.

I laugh when I see people saying their plan changed... you don't DO
that in telco.

> With Agile, you still define those things with the customer. You know that
> you're working with limited resources, so you rank the features (with
> customer's help) in order of priority, considering cost/benefit of each
> feature, etc. You end up with a Users Guide, a requirement spec, whatever
> else you end up with that you use for quoting.

Ranking isn't done in my world, once the purchase process is over with.

The feature is either in, and PLANNED to be fully tested, or it's out
at the very start.  The dollar amount is agreed-to up-front, and the
clock is ticking.  Nothing truly gets paid for until after it's
deployed and through production certification... there's a Purchase
Order, a sales contract, and a deadline.

It's all based off of cost/benefit analysis.  You can learn to live
with a lot of bugs if it'll take five minutes to re-write the fix and
two YEARS of lab certification testing before that code will ever see
a production environment.

You missed some stuff below... I'll add in my world...

> With traditional "waterfall" development, you just follow these steps, in
> the order shown, until the project is done:
>

0.1 A year of hinting that new features are coming.

0.2 At least four quarterly meetings with the customer to carefully
detail possible upgrades to get a feel for which ones they'll even
consider doing a standard year-long certification cycle on in their
lab.  Maybe even a mock-up demo of an interface or idea that doesn't
even exist yet, with lots of warnings that it's not even really
started yet.

0.3 Regular visits by a salesperson to get a feel for which of the
proposed ideas/products the customer is truly going to go fight for a
capital budget for.

0.4 Some internal coding and design work to be prepared to move on any
customer sales of things not even marketed yet, but already floated
past the decision-makers at the customer.  (Weird, huh?)

0.5 RFQ from customer to you and all your competitors, asking for the
features you've been touting to them for a year.

> 1. Requirements
(Mostly done pre-sales above.)

> 2. Design

2.1 Customer review by their own lab of the ENTIRE system and any
proposed design changes under NDA.  All revisions made here.  Tight
loop that Agile espouses is done up-front... not during
Implementation, ever.

> 3. Implementation

3.1 Release of "beta" or better to customer's internal labs for
interoperability testing, usually a fully-working product that is
missing "polish" and/or a few non-critical features that are still
being coded.  This allows their internal deployment teams to
understand the installation/restore/recovery process, so they can
start to work with our support team to come up with procedures for the
next step... full lab integration testing.

3.2 Full release and customer re-analyzes all changes and mountains of
paperwork are signed off agreeing that from the lowliest cable puller
to the architecture folks, the system is documented to the point where
every wire is traceable, and every code change is approved.

> 4. Verification

4.1 Customer flattens a production quality machine or entire group of
machines, and loads it from the ground up with previous version and
tests their internal deployment documentation to a point where a
monkey could deploy the software, in another VERY expensive lab.
Every single command to execute the upgrade, including a full
roll-back procedure and escalation phone numbers for every person
touching or responsible for each upgraded site are documented, the
tenative times/dates of upgrade are published, and "Method of
Procedure" documentation is signed off by customer and by us after
dry-runs of the upgrade.

4.2 Maintenance windows are set, usually at least a month in advance,
with some deployments taking longer than a year to reach all affected
sites.  Some customers even call this process a "Network Threat"
process, and have to approve each "Threat" with their Network
Operations Centers.  No site is ever allowed to have multiple
"Threats" open without the appropriate number of on-site staff.  (Many
sites are unmanned, otherwise.)

4.3 Test deployment into a lower-activity production site after
multiple dry-runs through the upgrade in the lab environment.  If
anything so much as hiccups or looks different from the dry-runs, the
system is immediately recovered to original state.  Timed sections and
"red lines" are places where you shall NOT cross into that stage of an
upgrade without the express permission of the customer -- usually a
Subject Matter Expert is present on the conference call throughout the
first few deployments, and they can call an upgrade off at any step in
the process.  The recovery process timeline is KNOWN ahead of time,
and everyone knows not only how to back out the upgrade, but how LONG
it will take from any point in the process.

(A screw up here can send you back to lab re-certification, cost at
least a quarter or two in sales revenue, and it's a major
all-hands-on-deck experience.)

4.4 The rest of the sites are done.  If any changes or mistakes in the
process are found that affect the early sites, new maintenance windows
are opened to return to those sites and you don't move on until
they're done unless the customer approves a "final cleanup" of any
human error or configuration gaffs.

> 5. Maintenance

5.1 Bugs found at this point, once the system's deployed, are assessed
for overall impact to the bottom line ("If you can't bill for it, it's
just a hobby!"), and customer impact.  The cardinal sins in telco are
a) Not answering the phone line during an inbound call, and b) hanging
up on someone in the middle of a call.  If you hit one of those two
hot buttons with a bug, an Emergency patch might be issued.
Otherwise, you'll probably go a couple of years after deployment with
only minor changes to system admin type settings, and those must go
through the same process as deployed software, but they're considered
"maintenance".  Code doesn't have "maintenance", it has VERY small
"emergency" changes to avoid only the largest customer-impacting or
operational issues.

5.2 We're now one to two years from the original date of the release
of the code, and changes at this point are cost/benefit analyzed to
death by both sides.  Nothing happens on this version again, unless a
crash or other major issue comes up.  The Sales/Marketing/Engineering
side of the house is already on to steps 0 through 1 above for next
generation software, and customer is moving toward next "major"
upgrade.  Any changes made at this point are MINOR and only allowed if
direct customer or revenue impact is seen.  Minor bugs, interface
problems, etc.. are considered low-risk, and therefore low-priority by
the all.

5.3 Sometime in the not too distant future after 5.1, an
end-of-service and pre-end-of-life  announcement is sent, usually
around the 4 to 5 year mark.

In the highly disciplined release process above, Agile sucks.

I have customers running 4-8 year old software on production systems
with KNOWN problems, and they're much happier with KNOWN problems than
UNKNOWN ones.  Every code change adds risk, leaving it alone adds
none.

Risk isn't tolerated, and those with bad risk assessment skills don't
last long.  I have had maintenance windows "go south" on me, through
no fault of my own (hardware failure, etc...) and changing the
procedures being used if the procedure must have risk added during a
maintenance window and you're past a reasonable fall-back point, can
easily involve escalations to three layers of management on both
sides, usually stopping at the VP levels in most telco organizations.

(Example, a bad SCSI controller and a very peculiar failure mode of
both some Clustering software and an external JBOD disk array caused
an outage of a site during a routine stop and start of a piece of
software to clear a known issue.  That particular failure had a VP on
the phone in 5 minutes flat on a Saturday morning at 3AM his time.  We
barely had time to make sure our own management levels were notified
that high up the food chain.)

So anyway, that's about the way I see it... this "world" differs from
most in that one of these single systems makes enough revenue in cash
in three days to pay my annual salary and have change left over.  When
that kind of money is flying around, processes like Agile and
iterative development are scoffed at... and rightly so.  But that cash
is diluted severely by the amount of process and engineering effort
that has to go around the system to keep it up 24/7, so while the
numbers sound huge -- they're mostly eaten up by overhead.

Agile really can't be wedged into the above processes (which I've
watched and done for close to 14 years now, with a few years off in
the middle to play in the large data-center/ISP sector)... it's too
rigid, and for good reason... it's rare someone can't make a phone
call.

(VoIP general crappiness and cellular RF front-side and back-haul
system overload during emergencies, notwithstanding.)

Oh for those that made it this far... what day is NO maintenance or
upgrades EVER done in telco without emergency authorization?  Mother's
Day.  Never ever.  Busiest telco day of the year...

Nate

2007\04\25@085954 by Gerhard Fiedler

picon face
Vitaliy wrote:

> You misunderstood what I said.
>
> With Agile, you still define those things with the customer. You know that
> you're working with limited resources, so you rank the features (with
> customer's help) in order of priority, considering cost/benefit of each
> feature, etc. You end up with a Users Guide, a requirement spec, whatever
> else you end up with that you use for quoting.
>
> With traditional "waterfall" development,

I wrote a whole bunch, then I decided to take a step back, go straight to
the roots and have a look at the Agile Manifesto
<http://agilemanifesto.org/principles.html>. If this is what we're talking
about... things are different. And so I deleted most of it... :)

I agree with everything that's said there -- but nowhere in there is said
that a waterfall methodology may not be the best and most suitable one in a
given situation :)

The Agile Manifesto makes a lot of sense -- because it is kept very
generic. That also makes that deriving any specific structure or
organization technique from it is quite difficult. Part of my confusion
came from you citing specific techniques and labeling them as "Agile". They
may be -- but so may be any number of other techniques.

There is no single technique and organization structure that's natively
Agile (in the sense of the original manifesto) -- and there's none that's
by definition not Agile, at least according to this manifest.


> With Agile, you have short development cycles (usually 2 weeks). You pick a
> set of tasks (or just a single task) that you can complete in one iteration.
> Each iteration includes test & debug phase, so at the end of the two weeks
> you end up with fully functional, tested and debugged software.

Hm... including a manual for it, an installer for it (possibly for all
three layers), and software that moves over the existing customer data? The
way you describe only works for /very/ small projects, or projects where
/very/ few people work on.

> Whatever the reason, you give the customer SOFTWARE THAT WORKS.

In theory, maybe -- but even then only with incomplete theory :)  One thing
is what Nate is talking about in his response. The definition of "software
that works" can be quite a bit different from the standard desktop software
case. But even if it doesn't go to such lengths as in the telco business,
must business software has specific interface requirements, and half
working in that respect is usually not working. E.g. a billing system
that's half working (that is, implements fully some of the billing rules)
will generally be considered not usable at all.

> --> By the way, another advantage of Agile is that you can ship the product
> early (whenever you decide that the feature set is sufficient). In the
> meantime, you continue development and implement those fun and exotic
> features you wanted to implement from the start.

This is not Agile, this is plain common sense. If you have this freedom and
the architecture and requirements allow it without adding much to the cost,
that's how you work to minimize the risk, even when working with a
waterfall model. But that's what I've been doing 20 years ago when possible
(and I'm sure I wasn't the only one -- it's not something I'm considering
especially smart, more like obvious :).


> What does "right" mean to you?

All agreed-upon features, on schedule, within budget, client happy,
programmers/engineers happy, me happy :)


> The comments you make about Agile, of course. I think you're confusing Agile
> with a twisted version of XP.

You're right, I confused them a bit. OTOH, it seems you brought in some
confusion, too -- at least I can't follow how you derive that the waterfall
method is /not/ in accordance with the Agile Manifesto, if applied
appropriately. There's nothing in the waterfall methodology that says that
it can't be applied to sub-projects.


> Who are those programmers? Which post-Agile movements?

<http://en.wikipedia.org/wiki/Agile_software_development#Post-Agilism>

This is all nice, but then there's the question how in accordance with the
Agile Manifesto it is to spend that much on defining management techniques
:)


> I'm yet to hear you offer an alternative methodology. What works for you,
> personally? How do you approach a project?

Depends a lot -- how big, how long, what kind of customer, whether I'm more
a partner or a service provider or selling a product, and so on.

> What do you think works for other programmers?

Depends a lot, on the programmer, the team and the project, at least -- and
often on the client, too. I've worked with programmers that I had to shield
completely from client contact in one project, while in another I could let
the same guy handle 80% of the client contact.

That's what I meant with "flexible" -- IME it depends a lot on the specific
circumstances.

>> For Agile, two of the requirements that kill it for me in most cases are
>> the physical proximity of the team members
>
> That makes it more difficult, but certainly not impossible.

Again... the manifesto is so generic that almost everything can be fit in
there. Which makes it difficult to talk about "Agile".



[Gerhard in reply to Vitaly, 4/14]
>>>> Rather than "Agile", I prefer "flexible" (note the lower-case "f" and
>>>> the upper-case "A"; I think it's the case that makes a religion, not
>>>> a deity -- everything and everybody can become a deity :)

[Vitaly in reply to Gerhard, 4/14]
>>> You can label any set of useful principles "religion", and reject it on
>>> that basis.

[Gerhard in reply to Vitaly, 4/14]
>> Maybe you're getting a bit defensive here. I marked my respective comment
>> with a smiley, it was in a tongue-in-cheek context from a previous message
>> -- and I never said I rejected Agile, much less that I do it because I
>> could label it as "religion".
>
> It was Nate who said: "Welcome to the church. Agile is just another
> methodology/religion."  The sentence above was my reply to his statement
> (which you echoed). I'm not paranoid. :)

Hm... see the dates added to the citations above. When you wrote that >>>
text, it was right below the cited >>>> text :)


> However, some methodologies are better than others.

I still fail to see a /methodology/ in the Agile Manifesto. It's a few good
thoughts, but they don't imply (or disqualify) any specific methodology --
if it is applied with the proverbial grain of salt.

Gerhard

2007\04\25@121948 by Vitaliy

flavicon
face
William Chops Westfield wrote:
>> That was my point exactly. Agile makes sense.
>>
> Having documentation makes sense too.  If it's accurate and well
> written.

"Agile" does not mean "no documentation". In fact, with Agile, you're much
more likely to end up with accurate, up-to-date documentation that reflects
the actual code. I can explain how and why it's better than writing the docs
upfront, but you need to tell me you want to hear it. :)

> You can come up with any number of "methods" that seem to make sense but
> don't necessarily work.  See my recent flame about ISO9000...

True, but not a good reason not to look into Agile.

> I may have to read up on this stuff.  But...
>
>> As short as one week, and as long as 2 months.
>>
> So exactly how does that interact with the HW team and its 9-month+ ASIC
> turnaround time?

I don't understand what you're asking. HW team has ways to test the code
before they put it in the ASIC, no?

> One of the big things I observed at cisco is that the same sort of
> development, management, and individual strategies that work really
> well for "small projects" don't work nearly so well for "large"
> projects (and vis versa, which is largely (and sadly) unrecognized.)
> "Small" means the whole team can go out to lunch and talk together;
> "large" is bigger than that.

Agile was originally designed for small teams. There are allegedly ways to
scale it up, but I haven't looked into it.

Vitaliy

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...