Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: OpEd: Programming is not Team Sports

by talexb (Canon)
on May 25, 2012 at 17:13 UTC ( #972500=note: print w/replies, xml ) Need Help??

in reply to OpEd: Programming is not Team Sports

I used the agile methodology at last workplace, and I use it now at my current workplace. And both approaches were different.

At the old place, we'd gather at about 10am and have a quick stand-up meeting: 1. Here's what I did yesterday; 2. Here's what I plan to do today; and 3. This is what's blocking me. Everyone got 1 minute; committee business would get put off until later. And it worked fairly well.

At the new place, every work item is costed out very carefully, we update our issues regularly, and we meet daily. It sounds roughly the same, but it feels like *much* more process, and a bit cumbersome.

The waterfall approach is close to what I learned at university (Systems Design Engineering at Waterloo), but it's a more academic approach than what I think really works well in the real world. In the real world, you don't want to spend weeks writing a perfectly detailed specification on what the system's going to do. It's much more productive to have a good general idea of where you're starting from, and be able to show a version that does a little bit, but does it well, shortly after starting. That's a much better approach than coding for eight months, finally having a demo of the system and hearing "Nah, that's not right."

Building software is *not* like building a house or a bridge. You don't think about rebuilding a house's entire foundation after it's been in place for 50 years, but, if the software's structured correctly, that type of thing is, or should be, fairly straightforward for a legacy system.

Really, agile should be about finding a good balance between planning and doing. That's all.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

  • Comment on Re: OpEd: Programming is not Team Sports

Replies are listed 'Best First'.
Re^2: OpEd: Programming is not Team Sports
by sundialsvc4 (Abbot) on May 25, 2012 at 17:52 UTC

    Bouncing a bit off of your fourth paragraph, let me play Devil’s advocate for a sec.   I wonder if it could be argued that ... if you spent X months building something to be told then that “that’s not right,” then you obviously didn’t build your blueprints.   I wonder also if it could be argued that what you are suggesting is actually an apologetic for, “let’s just make the whole thing up little-by-little as we go along.”  

    “If you do not know where you are going, you will get there ...”

    If one oh-so confidently asserts that software should be designed on-the-fly whereas a building or a bridge (that maybe costs less) requires rigorous design and specification ... what is it, exactly, about software that justifies exempting it from the advance planning process that is required even of a company that fixes pot-holes in the street?   (The original builders are frequently held liable for those pot-holes, by the way...)

    Are you seriously telling me that the only way to determine whether a system will be capable of supporting the intended transaction volume is to build the thing, throw it into the water, and see (for the first time, as it were...) if it swims?!

    I am unconvinced that “there is only one way to find out...”   You can’t figure out where to put in a septic tank, much less actually put one in, without doing a soil-percolation test first.   (Phew.)   When the plans are drawn-up and approved, this sort of preliminary investigation and calculation has already been completed.

    This Devil’s advocate says ... “Baloney!”   What say ye now?

      What say ye now?

      I say 40 years of people misunderstanding Dr. Royce, failing, and saying "It would have worked if we'd only BDUF more!" and failing just as badly next time gives me little confidence that BDUF more next time will ever work.

      To follow your boat analogy, I'd build the hull and make sure that it floats, draws the depth that I expected, performs in the wave tank correctly, and then continue with the deck, the fittings, the rigging, engine/sails, nav equipment and so forth.

      I may not have explained my 'on the fly' approach very well: I'm talking about getting started with the basics, and making sure that the basics work correctly.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://972500]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2018-05-25 05:06 GMT
Find Nodes?
    Voting Booth?