Is there any joy left in this industry?

[david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org (David Kramer)]

I've always gotten a low response rate when I've tried to suggest
software topics (vs IT/SysAdmin) at BLU, but there certainly seems to be
interest now.  I can tie it into Open Source/Free Software (if you
promise I won't get things thrown at me if I use one term or the other).

If we can't get Eric Raymond again (the author of The Cathedral And The
Bazaar, which is highly relevant), I'll do it.  Let's discuss dates
off-list.

It sounds like we have another topic out of this thread though;
interesting software projects.  Maybe we could have a round table or
audience participation meeting with that too.  If we run out of
contributors we can expand it into crazy hardware hacks.


On 10/30/2010 12:04 AM, John Abreau wrote:
> Hi, David. A talk on Agile might be interesting for a BLU meeting. Would
> you like to 
> do a talk on Agile, or can you recommend someone to give such a talk?
> 
> 
> 
> On Fri, Oct 29, 2010 at 12:45 AM, David Kramer <david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org
> <mailto:david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org>> wrote:
> 
>     On 10/28/2010 10:24 PM, Mark Woodward wrote:
>     > On 10/28/2010 12:00 PM, discuss-request-mNDKBlG2WHs at public.gmane.org
>     <mailto:discuss-request-mNDKBlG2WHs at public.gmane.org> wrote:
>     >> Date: Thu, 28 Oct 2010 00:42:02 -0400
>     >> From: David Kramer<david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org
>     <mailto:david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org>>
> 
>     >> Most things made for 25 years become commoditized as the hard
>     problems
>     >> get solved, eh?
>     >>
>     > Perhaps, but I can't believe that there aren't any "hard problems"
>     left.
>     > There are plenty, but the industry has basically decided to fight over
>     > commodities instead of growing the environment.
> 
>     OK, go do it!  What's stopping you?  I did it.
>     I gave you several examples of companies.  Of course there aren't as
>     many as there used to be.  The combination of the bad economy and the
>     fact that very few executives are thinking more than a quarter or two
>     ahead makes companies more conservative.
> 
>     >> I will agree that a lot of very stupid things are being done in
>     the name
>     >> of Agile that are not Agile at all, but that's not the fault of
>     Agile.
>     >>
>     >
>     > Here's my problem with Agile, the Agile proponents claim it is a good
>     > system, but decry that when people do it wrong, its the people's fault
>     > and not "Agile."  A system or practice that depends completely on the
>     > the people doing it right for success isn't really a system. The
>     fact is
> 
>     Uhm, so you're saying if you do Agile wrong and you fail, it's Agile's
>     fault?  "Doc, you told me to take one of these pills a day, but I felt
>     really bad so I took 8, and now I have a stomach ulcer, so I'm suing
>     you".
> 
>     Requirements gathering, software design, software development,
>     integration, testing, and deployment are all hard problems fraught with
>     innumerable opportunities for failure.  Yes, if you do it wrong, you
>     open yourself up for a world of problems.
> 
>     Any practice that is so fault tolerant that you can do it poorly and
>     still succeed is trivial as to not be comparable to the business of
>     developing software.  The coffee maker at work isn't even that fault
>     tolerant.
> 
>     Waterfall is much less fault tolerant that Agile is.  Even if you design
>     the perfect software program to suit the initial requirements, by the
>     time you're done, it's almost guaranteed to no longer be what's needed,
>     even if the initial design ever *was* what the user needed 8 months ago.
> 
>     > "competent" people will do a competent job, and incompetent people
>     will
>     > do an incompetent job. "Agile" does nothing to improve this truism. It
> 
>     But it *can* mitigate its effects.  When you have to show your work
>     frequently, it becomes very obvious who is not holding their own.  It
>     also means if someone does muck things up, you've lost a few weeks
>     instead of a few months.  If you're pair programming (which I am a big
>     fan of), you may be able to compensate with proper pairing.
> 
>     > only makes the development process short sighted and puts the team
>     on an
>     > endless treadmill of unobtainable "sprints."
> 
>     The developers are right there in the sprint planning meetings, daily
>     standups, and sprint retrospectives.  If the plan for the sprint is
>     unobtainable, the developers are just as much to blame.  If the
>     developers aren't thusly empowered, then it's not Agile.
> 
>     Part of the process [in most flavors of Agile] is tracking velocity (how
>     many story points can be completed in a sprint) and how big a story
>     point should be (based on estimated vs actual).
> 
>     > Agile becomes a cudgel for management to have developers ALWAYS behind
>     > the 8-ball because things always take longer than estimates. Agile's
> 
>     Agile doesn't dictate how long things should take; you and your
>     coworkers do.  Even if you have two-week iterations, that doesn't mean
>     every piece of functionality has to be developed in two weeks.
> 
>     One aspect of [most forms of] Agile is a balance of power  (the
>     following is an oversimplification and generalization):
>     - The PO (Product Owner) comes up with the stories (requirements).
>     - The PO and the developers discuss implementations and acceptance
>     criteria.
>     - The developers break stories up into tasks and assign story points
>     (time estimates).
>     - The PO, armed with this data, decides what stories should be in the
>     next sprint, subject to the story points adding up to less than the
>     length of the sprint plus testing time, etc.
>     - Everyone meets regularly so if things are going off-track, measures
>     can be taken to compensate (dropping stories from the sprint,
>     redeploying resources, etc).
> 
>     You see, the *developers* say how long things should take, and the PO
>     says what gets worked on and when.  Balance of power.  The PO can only
>     put one sprint's worth of work *based on the developer's estimates* in
>     the sprint.
> 
>     > time constraints forces a reduction in problem analysis which means
>     > that
> 
>     Not reduction; deconstruction into manageable testable chunks, and not
>     working on things you don't need yet, because you may never need them.
> 
>     > you don't really understand non-trivial problems until you are already
>     > late. Before you know it, you're at work at 9:00 PM working feverishly
>     > to complete a feature before the next day's stand up.
> 
>     > In several companies I have worked at or with in the last few years, I
>     > see the same thing. The old adage is more true under "Agile" than ever
>     > before: "There never time to do it right, but there's always time
>     to do
>     > it again."
> 
>     I have never faced a situation in my current company or my last where I
>     was told to opt for the quick fix instead of redoing it right.
>     Shortsighted bad management is shortsighted bad management no matter
>     what process you claim to follow.
> 
>     > Then, don't get me started on CEOs and MBA types that preach
>     "Agile" to
>     > "get engineering under control." Kiss that 50 hour week goodbye. You
>     > might as well change your designation from "human" to "veal," because
>     > you are sitting in a small box for the foreseeable future.
> 
>     You can fill in almost any process (Six Sigma, ISO-900X, TQM, waterfall)
>     for Agile in that sentence.  Managers want a silver bullet and are
>     unwilling to accept that TANSTAAFL.  As with all of these processes,
>     there are pundits who hawk it who don't understand it themselves, or
>     knowingly misrepresent it for their own gain.  That has nothing to do
>     with whether Agile is good or bad.
> 
>     > Some of the core principles of agile are, of course, hold overs
>     from the
>     > old days and hacking. Iteration instead of in-depth design, favoring
>     > napkins over velum is better, sure, but while "agile" might have
>     started
>     > as a way to improve the software development model, like "Rock & Roll"
>     > it has become a corporate cesspool of the worst sort of practices.
> 
>     Every method, tool, and practice is a compromise with costs and benefits
>     (See TANSTAAFL).  Agile does not claim to have invented a miracle cure.
>      The various flavors of Agile propose that they have each come up with a
>     set of practices that compliment each other well, provide measurable
>     benefit when done right.  That benefit comes from coverage of required
>     safeguards and the benefits of one practice compensating for the costs
>     of another.
> 
>     What this means that if you take Scrum, or XP, or Lean, or Kanban, and
>     decide to do *most* of it, it's as if you've followed a recipe leaving
>     out random ingredients.  It only required a dash of red wine vinegar,
>     but dammit that dash is important to balance the ph of the dish.
> 
>     So if you decide you're going to do Scrum But ("We're doing Scrum, but
>     we're not doing practice X"), and decide to leave out pair programming,
>     unless you put some other practice (code reviews, brown bag
>     presentations, code analysis tools, internal knowledgebase, etc) in its
>     place to serve the purpose it was serving, you're gonna end up with a
>     big pile of Jenga pieces all over the table.
> 
>     I have found that the most successful Agile projects take the practices
>     that will work best in their organization and follow them well.  I have
>     also found that the LEAST successful Agile projects take the practices
>     that will work best in their organization and follow them well.  The
>     difference?  Understanding what each practice is for, and picking
>     practices that cover what need to be covered and complement each other.
> 
>     > In short, if you are doing "Agile" right, it isn't because of "agile,"
>     > it because of you and you just happen to have chosen agile. Agile
>     in and
>     > of itself only makes things worse.
> 
>     You haven't backed up that claim at all.  You've only proved if you do
>     Agile wrong it makes things worse, which I agree with.  If a 12 year old
>     steals his dads keys and gets into a car and smashes it into a pole, the
>     problem is probably not the car.
> 
>     I have a recommendation for you.  Agile Bazaar started something new
>     last month, and we're doing it again for the next few monthly meetings.
>      It's "Agile 101" courses that are only half an hour long and are before
>     the regular meeting.  There you will be able to understand the concepts
>     of Agile you are missing.  It's free, too.
> 
>     Think of it as a job hunting activity.  In fact, stay for the meeting,
>     where we always have a "jobs needs and leads" segment.  You never know
>     what interesting problem you'll run into ;)
>     _______________________________________________
>     Discuss mailing list
>     Discuss-mNDKBlG2WHs at public.gmane.org <mailto:Discuss-mNDKBlG2WHs at public.gmane.org>
>     http://lists.blu.org/mailman/listinfo/discuss
> 
> 
> 
> 
> -- 
> John Abreau / Executive Director, Boston Linux & Unix
> GnuPG KeyID: 0xD5C7B5D9 / Email: abreauj-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
> <mailto:abreauj-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
> GnuPG FP: 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99