Posts by TJ930

So you're 'agile', huh? I do not think it means what you think it means

Re: So many misunderstandings. "Customer Collaboration over Contract Negotiation."

In relation to your concerns about being sued, suggest a couple of intro books for you, like Tom De Marco's "Peopleware" and "Slack."

But, yes, as I think mentioned in "The Phoenix Project", 99.9% reoccurring of companies, whether they realize it or not, are IT Companies that sell plane tickets, energy, products, finance, services or whatever... But their business is entirely based upon IT.

No, they don't have to form a Waterfall-Agile-Waterfall Sandwich. Read one of Mary Poppendieck's books, learn about Lean companies (like Toyota, Harley Davidson, or Porsche), or look into Dean Leffingwell's SAFe... When you get a little more advanced, learn about 'Lean-Startup' to truly liberate your mind. Eric Ries has a couple books on that.

These are all bedrock principles

..Which are all far too complicated and totally unnecessary for anybody to bother following? So should be mocked and ridiculed in direct proportion to their effectiveness?

You don't see a contradiction here?..

Re: Successful implementations?

Well let's just list a few company names, shall we?...

Amazon.

Google.

Adobe.

Right, where's your list of successful Waterfall implementations?..

Nokia (*long gone* They couldn't react quickly enough to the iPhone)

etc.

etc.

Yours are as rare as rocking-horse manure, boys...

Whereas Lean Companies (such as Toyota, Harley Davidson and Porsche) trounce the opposition in terms of efficiency, time-to-market, customer choice, etc...

You're a dying breed, boys. "Bye bye!"

socialism/communism. Never been implemented 'properly' yet

I’d absolutely with you agree about the Socialism/Communism, and taking these sorts of people “for the helicopter ride.” However, the weakness in your argument is that this quip could far more easily and more accurately be applied to Waterfall! The idea that you always get it exactly right first time is rocking-horse manure…

I’ve heard it said that Waterfall is actually an iterative, adaptive approach – it’s just that the iteration lengths are muuuuuuch longer and slower. (Typically 6 months to 2+ years.)

So you guys send out v1.0 on (or somewhat after the deadline), it’s full of bugs, and doesn’t work how the customer wanted or expected; then – rapidly as you can (another year later) – you send out v1.1… And shortly after that, v1.2, v1.3 etc. etc. etc. to fix (some of) the bugs in the previous versions…

So you see, proper Agile is just a better way of doing it. Less time. Less waste. Fewer pages of unread documentation… Bit like Capitalism? (Just pay for what you need, rather than being taxed to extinction, paying for ‘non-jobs’.)

25yo legacy app

Hmmm.. Michael Feathers’ famous definition of Legacy Code: “Code without tests.”

Seriously, I mean to help.

So are you Scaling with ‘Scrum of Scrums’? Or something a little more structured like Nexus, LeSS or SAFe, etc.? (Or is it rather more like ‘The Wild West’?)

But why are the Teams under a lot of time pressure? They are meant to be able to maintain this pace indefinitely – are they very poor at estimation? Are they doing sufficient Backlog Refinement? Which technique do they use to estimate – Relative Sizing or Capacity Planning (i.e. Time)? Or is somebody else from outside just “pushing” the work onto them?

Why not take a look at Henrik Kniberg’s checklist and – be honest – count how many your aren’t ticking? https://www.crisp.se/wp-content/uploads/2012/05/Scrum-checklist.pdf

Scrum should be bringing Transparency through its Principles, Practises, Events and Artefacts:

Potentially Shippable Increment = Fully merged, fully tested.

Continuous Integration = Merge to trunk (i.e. no branching).

Sustainable Pace.

Definition of Done. (Basic one that all the Teams agree to, with more exacting and tighter definitions for the better Teams, once they have started the Continuous Improvement process).

Continuous Improvement of processes, tools and techniques.

Who is the Teams' Scrum Master? The phrase, “Where Scrum isn’t fully adopted and fully understood,” is used as a caveat to give Scrum Master’s a bit of elbow room to correct errant behavior… Maybe time to have a word with the SM?

25 years ago = circa 1992 code, and so I’m guessing primarily C/C++? (If not Pascal or COBOL or something?)

Now I’ve used .NET static-analysis tools before to help identify redundant, legacy code. (But I'm sure there’s C++ stuff out there - have you checked into this?)

Does sounds like you’re already aware of your problem – a lack of Technical Excellence and Discipline (probably brought about by a lack of Transparency) – what can you do to hold them to account? (Are they Pairing?) Maybe you could work on their Teams for a Sprint and check that each Story has a Code Review Task? Or how about Martin Fowler’s “StranglerVine”? (Pay down that Technical Debt?)

And then how do you use the remaining 90% of the developers?

Although "compost" might be a glib reply, I'll try to give you a serious answer. Let's say we have a department with 100 Developers and the company's decision is to use the most popular 'de facto' Agile Framework, Scrum.

The 3 Approaches are:

1) ALL AT ONCE - i.e. Spell out to the Developers what a successful Scrum Team looks like:

i) 3-9 Members.

ii) Optimum of around 5 Developers. (No split-Team membership.)

iii) Cross-Functional (i.e. all the necessary skills required to produce a working Product from a Product Backlog Item)

iv) Self-Organizing

Then allow the Developers to choose their friends, however they want, provided their Teams meet these acceptance criteria. (This may take several goes - i.e. iterations - and expect a lot of girlie whining for the first couple of weeks.)

2) CULTIVATE FROM EXCELLENCE - i.e. "one volunteer is worth 10 pressed men", as the saying goes. So start small with a Team of Volunteers, then once this Team starts trouncing the White-Water-Rafting and Big-Bang Boys - which will happen (these Teams are easily x4 times quicker) - create an air of mystique for this Team based upon Great Results and well-earned bigger bonuses, etc. Then 'take clippings' and form a new Team around each of these individual winners, who've done it before and now know what it takes to succeed. Keep spreading the love.

3) BUILD A SHINY NEW BUILDING with security on the door to keep out the riff raff / rotting vegetation. Recruitment Policy: Only competent people who know how to do Agile.

Then start winding down the old place, giving the less skilled less and less to do, hoping that they get bored and leave of their own volition... Saving on the number of redundancies when 'push ultimately comes to shove.'

If a team can't communicate adequately doing waterfall, they can't communicate doing agile.

No, you're just showing your ignorance off again, aren't you?

What size is the average Waterfall team?.. What size is the average Scrum, XP or Kanban Team?

The fact there are far fewer people in Agile Teams and there is far more transparency means there is nowhere to hide. It's pretty obvious in a Daily Stand-Up when a Team Member isn't pulling their weight and needs a talking to! Or when somebody has a blocker, they can more easily ask for help.

The fact that we are dealing with smaller chunks of work means that the shared understanding of the work in progress improves.

Also the fact that the team wins and loses together, sets its own targets, improves its own processes, is its own boss, de-emphasises job titles, typically co-locates teams and communicates with each other face-to-face, rather than through hefty documents, phase gates and sign-offs.

The cross-functional nature of teams also improves communication, reduces bottlenecks and reduces delay.

Yeah, you don't know what you're talking about, do you?

Not just how to write software with fewer defects

Sympathetic to your viewpoint. However, I feel you’re missing the bigger picture - but first off, some QA definitions:

Verification error - The code doesn’t do what the spec says it should.

Validation error - The spec was wrong.

(The latter is usually far worse, because it often results in large portions of the code base being binned, due to building totally the wrong thing!)

So rather than Documentation, Sequencing and Phase-Gating, Agile Frameworks are based on the principle of Empiricism, and Empiricism rests upon the 3 Pillars of Transparency, Inspection and Adaptation.

To help you understand this purer form, let me ask you why you are running tests against your source/executable code? You’re inspecting it, that’s why. But why are you doing that? To gain transparency of your code’s quality and suitability. But why? So that you can make corrective changes (adaptations) if there are problems. In short, it’s all about Feedback.

So will your coding practices help you if the Business Analyst totally misunderstood what the customer wanted? (Or, more truthfully, if the customer didn’t really know?) No, of course not, and so your approach will not prevent Validation Errors.

You may then retort, “They would have found it in UAT!” But a typical Scrum Team gets feedback after just 2 weeks; your Waterfall approach is going to have to wait until the whole thing is finished (typically 6 months to 2 years later). So how much extra code is going to get binned? How much more rework is going to be necessary? (And let’s not forget that the Scrum Team didn’t waste 3-6months writing this useless specification in the first place!)

So this, amongst many other reasons, is why Agile is upwards of x4-to-x10 faster because it removes so much unnecessary waste from the processes. (It’s not just about fewer bugs!)

I see that you’ve used the words “a strong suspicion” – this sounds rather like you’ve never experienced Agile for yourself? Am I right? Psychologically, I think the behaviours of yourself and other commenters on here can be explained as not wishing to feel stupid again, having to learn something new, and so your egos are preventing you from seeing the truth.

The thing is, reality doesn’t care about your feelings.

Software Engineering

Software-Engineering practices will not prevent you from building the wrong thing.

Customers and shovels

So you haven't heard of "Personas" and "User Stories", then?..

Or you have and haven't understood them, but this hasn't prevented you from offering up an opinion?

1 trhough 7 you mentioned are what is called requirements analysis.. in classic waterfall

I think the simple analogy that counters this weak line of argumentation is that of driving a car.

So, when you're driving a car, which is the "Looking-out-of-the-windscreen phase"?...

"Let's do all our looking out the window before we set off. That'll work!"

Not.

30 comments or more, and not even one that actually defends agile as a way of working.

FYI: This logical fallacy is known as "argumentum ad populum" (i.e. "argument to the people" or "appeal to the majority"), e.g. lots of people say "the Earth is flat", so the Earth is flat; lots of Creationists say that "Darwin's Theory of Evolution is wrong..." etc. etc. etc.

So, back to the topic at hand, there are really only 3 choices:

1) Do all your planning up front.

2) Do no planning.

3) Use an Agile (adaptive) approach...

For anything other than the trivially simplest of projects, I don't think the first two are not sensible options. But if you don't want to be sensible, do feel free...

Oh and I have been defending Agile, and doing a rather good job of it. You can't knock down my arguments; instead, I just get name-calling ("argumentum ad hominem"). How very grown up. Not.

Re: "Scrum" and "Agile" / Rugby

Tedious and predictable.

Web-Ellis would not be proud of you.

Re: Agile Project Manager

Yes. Quite so!

It's a true oxymoron... God, I can read a job spec and with 99+% accuracy predict all the problems the organisation is currently experiencing..

Doesn't mean that i can necessarily fix them, because people with lots of power might have other ideas...

Re: Too soon?

Was the customer feedback positive?...

Re: agile with a lowercase a

Agile Frameworks make your pre-existing organisational problems visible for all to see..

"Shoot the messenger", eh?

Re: agile with a lowercase a

Right. So everybody knew it already?.... So why the backlash, if everybody knew it already?...

Re: Windows user is Medieval

Yeah, you don't know what you're talking about.

The maximum size of a Scrum Team is.... No, not the size of a whole village *sigh*

You haven't seen Agile.

Re: No true agile developer...

To give it its proper name, it's known as the "no true Scotsman fallacy."

The thing that separates, for example, Scrum from the No-True-Scotsman fallacy is what's called the "End Note" in the 2016 Scrum Guide.

"Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices."

So I rather suspect that the "twits with an 'A' " who claim to have done Scrum but it didn't work, actually haven't done Scrum at all..

If you wan't help, see either Erik Kniberg or me... I'lll be able to diagnose your malignancy in seconds.

Its a F******g disaster for everything else.

In the "early stages" - you mean before the Monkeys touch the keyboard? Right... Here's an idea - get rid of the Monkeys! Problem solved! :)

No, Agile - e.g. Scrum - can be applied to anything from Software Development, to house refurbishing, to self-educating Dutch School Children, to planning weddings, to refurbishing old-classic-Sports Cars...

But we wouldn't expect you to know about all that. You're only spouting..

:)

Re: Agile

And the alternative is?,,,,

Bearing in mind that, like an ON-OFF switch, an alternative has only one other state. (Poor English speakers tend to confuse "options" with "alternatives".)

Re: Agile

How many miles on that odometer, Johnny Boy? I don't want to say that "you aren't doing it properly", but "you sure as hell ain't doing it right." And that is your problem.

XP bods would have an apoplectic fit if you talked about code duplication as if it were passe or 'business as usual.'

You seem to be complaining about the symptoms without first understanding the underlying problems.

Re: The main issue are those who turned it into a sort of religion...

Tom Cruise thinks otherwise... Dzzzzt

;)

Re: Agile

You're a nice guy. I can see that. But this is "scary unknown" speaking, isn't it?

Imagine if you had much greater visibility of what you were doing; imagine if your assumptions got tested in the real world much more frequently; imagine if you could replace vague guess-work with knowledge...

Communication in Agile is 'bolted in' - I don't want to sound like the "No True Scotsman fallacy" - but the number of people who claim to have done some form of Agile, Software Development but don't have the first clue about what they're doing... Well we've got to use binary and everybody in the room to count it on our 10 fingers!...

We ended up calling him the scum master...

Hilarious! :)) Yeah, the guy doesn't sound like he was living up to his education job description, so deserved to get the 'chop of the sword'

Yes, we've all mistyped stuff in our time; Did you know that incompetent Developers get called "Divs"?

King Knut and the JUNIOR PEOPLE

The tide is coming in, Knut. (Did I spell that right?)

Yep, I have a cool, new name for the old, dead horse: "W**k**fail" :)

Distributed teams, and varying skills, it's also more difficult.

I really don’t accept this assertion. Are you seriously suggesting that “Traditional” / old-fashioned approaches are completely impervious to the effects of those same complications?.. Seriously?.. Have you been drunk typing?..

Giving to short targets and schedules

Yeah, I suspect that you understand how a Product Backlogs work. Look up the “Iceberg Model” (and Epics->Features->Stories). Sounds like your Backlog is a “Sea of User Stories”?

But really?!.. Rigid inflexibility is better, is it? Dogmatic adhesion to a bad plan? Blind obedience in the face of overwhelming evidence because our (religious) leader said so?

There are only 3 roles in Scrum… So, if the Product Backlog isn’t being prioritized to maximise business value, who is to blame?...

Hint: It isn’t going to be the Framework or Methodology.

Stronger hint: Neither is it going to be the Scrum Master or Developer (unless they are staying quiet when they know they should be saying something – see Principles of “Self-Organisation” and “Continuous Improvement”).

People shared understanding and planned what to do even without formal stand up meetings.

If you were doing it anyway, why then the complaint about codifying these approaches and putting them in the public domain? Sounds rather like those who complained about the King James Bible being written in English (instead of Latin)? Sharing it with the “common people”, eh?

Perhaps it is because you want to keep this near-religious experience all to yourself, and continue to be treated like a deity? That Super Programmer who walks on water? ;)

Also seems strange that you complain that time is being wasted, but then complain about a technique proven to reduce wasted time… You don’t actually have to stand for a Daily-Scrum if you don’t want to. (The standing-up part actually comes from XP!) But, if you’re struggling to keep to that 15-minute Time-box, why not try standing?.. The clock doesn’t lie.

As regards the frequency of the “inspection”, Daily Planning does not preclude longer-term Planning – or hadn’t you understood that? The fact is, if there is some serious impediment or some exciting opportunity/Emergent Design to exploit, would meeting less frequently help or hinder your progress?..

Remember also that a time-box is a MAXIMUM (not a MINIMUM). So, if you have nothing much to say today, you should be able to wrap up the Daily Scrum inside 2 minutes! (Almost no time wasted, and way less than the amount of re-work created by not talking to each other enough!)

*P*retentious *T*itles like *S*crum *M*aster.

Yep! I’ll give you that one… I personally might have chosen different names… But have a think what would happen if instead of “Product Owner”, we just used, “Business Analyst”? Or instead of “Scrum Master”, we continued along with the title, “Project Manager”?.. What would be the result? Would people appreciate that their roles had totally changed?

If you keep the name “Manager” in your job title, are you more or less likely to desist from telling people what and how to do their jobs?... Are you more or less likely to let the Team Self-Organise and make their own decisions?

One could even make the case that the very name they haven’t changed (just the definition), the “Developer”, is the one that causes the most issues in Scrum! In a Cross-Functional Team, “Developer” applies to anyone doing the development work (so QA, Architect, Programmer, DBA, Basket-Weaver, whatever). This change is intentional and absolutely essential, because it’s trying to knock down “over-the-wall” and “siloed” thinking, trying instead to create a Team ethic where “everybody in that small Team is responsible for ensuring the Team’s overall success..”

"something to show"

"Exhibitionist"?

Scrum is a “pull” system. Back in the Sprint Planning, you were meant to have negotiated with the Product Owner what you were going to be working upon, and then pulled it into your Sprint Backlog; in the Backlog Refinement sessions, you were meant to have helped the Product Owner write those self, same Stories in that Product Backlog (from which you then went on to select your Sprint Backlog).

Hence, I’m now reminded of Douglas Adam’s famous quote – no, not the one about fish or the meaning of life – if you are an ingenious idiot, I can’t help you. Sorry. Scrum isn’t idiot proof.

That said, maybe your Product Owner and Scrum Master could do a better job as “Heat Shields”, protecting you from Management pressure? But if you’re frequently showing them good, working software in the Sprint Reviews, their trust should build and the pressure should subside.

Maybe you just aren’t doing your Sprint Reviews frequently enough?...

“That implies that ‘feedback’ can come just at the end of a Sprint[?]”

No. You imputed that. Now, where possible, I personally consider basic TDD/CI to be far superior to Debugging, but each to their own....

You’ve specifically used the word “Sprint”, rather than “Iteration”, so we’re talking Scrum – am I right?..

So what are the 5 Scrum Events?.. Do you know?.. No?.. Read on..

- The Sprint

- Sprint Planning

- Daily Scrum

- Sprint Retrospective

- Sprint Review

The first is a “time-boxed” container for the other 4, and each of those is an “inspect-and-adapt” (i.e. a “Feedback”) opportunity for each of the different aspects of the development processes. (NB: Feedback is not strictly limited to these Scrum Events!)

In my experience, whatever Sprint length the Team chooses, when Scrum Teams are very inexperienced, the Programmers (despite protestations from the QAs) typically pull in far too much work. (Usually ~150+% of what the Team can actually finish in the time-box: so a 2-week-Sprint Team will pull in 3 weeks’ worth of work; a 4-week pulls in 6 weeks’, etc.) This usually originates from “I’ve-done-MY-bit” and “quality-&-testing-are-someone-else’s-concern” thinking; the Sprint Time-Box and Sprint Review force errant, lazy programmers to ‘face the music.’

“Hardening Sprints” and “Bug-Fix Sprints” are not part of Scrum; they are a managerial dysfunction/anti-pattern caused by not finding and fixing bugs (i.e. inspecting & adapting) early enough in the Development. This reduces the transparency of how much work actually remains, destroying Scrum’s empiricism, and with it the ability to predict the finish date with any kind of accuracy…

I’m guessing that this sort of failure thing sounds quite familiar to you, right?

Now, splitting Stories is a skill to be acquired with practise. Yes, Product Owners and Developers need teaching, coaching and advising to that end. But look up “Walking Skeletons”, “MVP” and “Story Mapping” to help you understand the basics… In your Sprint Reviews, you’ll want to have a ‘working Prototype’ – so stub out/fake the bits that aren’t finished yet – but proudly show the bits that are, and then let the Customer glean whether what they requested is what they actually want (i.e. a “validation error”, as it’s known) – whilst we can still easily do something about it!

All of these Agile Methodologies are based upon transparency and feedback loops. So, yes, in summary: Feedback. Feedback. Feedback. Ad infinitum.

*P*rinciples, the *P*ractices, *E*tc. *E*tc

*A*d hominem *A*ssertion *A*d hominem *A*ssertion.

Okay, I'll "rip you a new one" on each of these points... Yes, don’t bother challenging the argument; challenge instead the style or character of the person who made the argument. Far easier ;) (Though those with even only a cursory understanding of logical fallacies might consider this tactic to be rather less effective.)

I was explaining to you the underlying need for principles, and why they can seem a little abstract.

Just read some of the other postings on here. In the same breath as accusing the concepts, principles, beliefs and values as being too abstract, hazy, opaque or imprecise, someone will seemingly then go on to describe the practises as too concrete, over-exacting, silly and/or unnecessary.

No, “put the Principles into Stone”, not the Practises. Here the principle of Self-Organisation is the one that’s important – the Team should have the power to override “pointless rituals.”

Ipso facto. I think you have rather proven my point.

Re: Agile

Have you ever watched a group of 6-year-olds play Football? All chasing after the ball, all getting in each other's way?.. Have you ever watched a well-disciplined, lower-league, FA Cup 'Team' destroy a 'Group' of galactico, individualists on an 'off day'?

In short, it's the Team ethic...

There are various techniques for forming Agile Teams, but the very best - perhaps unsurprisingly - is to allow Self-Organizing, Cross-Functional Teams to pick themselves.

Re: Agile

Nope. Not at all.

I can send you a simple 'Scrum checklist' from Henrik Kniberg, or a James Shore 'XP Radar Chart checklist', if you'd like.

Should be more than apposite for somebody at your level.

Cheers

Project Management shister-speak for "Make it up as you go along"

I thought that was "Big Bang" (or "Silent But Deadly", as it's also known)?

Re: SAFe is uglyyyyyyy

Mate, I appreciate that everybody's first response to SAFe might, "WTF?!" But once you understand it, things make sense. A bit like x8086 Assembler, or .NET Intermediate Language, or Swedish, or whatever...

If you understand how to do Scrum, then you understand how to Scale Scrum (i.e. multiple Teams working from the same Product Backlog), and then you start to realize that the rest of the organization needs to get in step with this Lean-Agile think, Jemba (walk those 'value streams', etc).. It all checks out.

Or you could just rejoice in your ignorance and hope that this Agile Alligator eats you and your company last?...

"Make it up as you go along"

Yes, far better that we make up a piece of fiction right before we start, plan everything in microscopic detail as to the precise way things are going to occur for the next 2 years... Then just deny observable reality, blame and scapegoat the poor souls tasked with achieving the impossible, and watch as the 'final deadlines' keep flying by like miles on the odometer of a speeding car, as the Bugs in the Bug Backlog start to number in the thousands, as the customers grow more and more disgruntled, and the £ notes burn right before your eyes...

Way better? Or maybe not?...

"Code"

Feel I ought to help you out here: "Code" means that executable stuff your computer likes; not "Source Code."

Two clues comes from the Agile manifesto:

i) "Working Software over comprehensive documentation."

ii) Principle 7: "Working software is the primary measure of progress."

Two more clues come from the Scrum Guide (if we're talking Scrum)

i) "Potentially shippable increment" [i.e. fully merged, fully tested Code at the end of each Sprint.]

ii) The Scrum Event 'inspect-and-adapt opportunity' known as the "Sprint Review" [aka "Sprint Demo"]

Two more clues from SAFe Principles (if we're talking of scaling with something like SAFe)

i) Principle 4: "Build incrementally with fast, integrated learning cycles."

ii) Principle 5: "Base milestones upon objective evaluation of working software."

Re: wagile

In my experience, about 5% of Agile-Adoption problems are with Developers (most of whom just want to type code) and about 95% are with Management...

Management often likes to think the rules, practices and beliefs somehow don't apply to them, just the serfs beneath... Management sets the culture.

Re: The main issue are those who turned it into a sort of religion...

To be fair, I can understand why you would proffer such an opinion... By definition, a Belief is something that can't be proven - otherwise it's just a fact!

But, to understand your complaint, it's Lean-Agile Values and Beliefs that guide those Lean-Agile Principles, these Principles are then applied to form their own specific Practices (by the people doing the actual work - NOT top-down Management, far removed from "what's what"). So it's the Beliefs, Values and Principles that can make things seem quasi religious.

To explain why they're needed, a Practice which works very well for one Team / Department / Company / Organization / Hospital / whatever, might not work at all - due to local reasons - when attempts are made to apply the specific practices directly elsewhere. This is why an understanding of the basic Principles is required, because the Principles CAN ALWAYS be applied.

For example, the whole point of a "Daily Scrum" is NOT to answer 3 questions when standing up; the point is for the Team to gain a Shared Understanding of the current state, to formulate a Plan for the next 24 hours, to check things are on track, and make changes if they aren't... How you do this (the Practices you employ) is entirely up to you... So, if your processes aren't working, change them!

Given that "working software is the only real measure of progress.." and that Empiricism is based upon Feedback loops (i.e. checking your assumptions) ; if your Sprints last longer than 4 weeks, are you increasing or decreasing the number of Feedback opportunities you will have in a given year?

"Scrum is a framework for creating complex products in complex environments..." People always make excuses about complexity; why not try breaking the complexity down into smaller problems?

"Oh, no.. Couldn't possible do that!..."

Oh, yes, you can.