Busy Bees

Homepage Forums Small Talk Busy Bees

This topic contains 18 replies, has 7 voices, and was last updated by  _Robert_ 1 week, 5 days ago.

Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
    Posts
  • #29348

    Bill
    Participant

    I will not lift a finger until I have a plan. As a result I am efficient getting tasks completed.

    You may be efficient in the time the task takes from beginning to end but are you including the planning time in your total?

    In contrast, as long as I have a general idea of what I need to do, I tend to just dive in on tasks adjusting as needed when something doesn’t work as I expect it to. In today’s software engineering world, this is known as “Agile” – just get something out in front of users because they won’t know what they like or dislike about an application until they have a chance to use it.

    My wife takes the same approach as you do, not starting on anything until she has completely evaluated all possible approaches and outcomes. She hates doing anything wrong. I call this “analysis paralysis”. She’ll often ask me how to perform some action on the computer in some application that I have never used. I just start looking for things that look or sound like they’ll do what I need and clicking on them. More often than not, the action at least <i>leads</i> to what she wanted to do although (potentially) with many side trips along the way. She hates that because it means that she did something wrong. I take the viewpoint that anything done wrong is just knowledge for the next time that you want to actually do the thing that happened.

    #29352

    _Robert_
    Participant

    I have had to repair and untangle very poor software written with little planning or requirements. It’s often better just to start over. Your understanding of “Agile” is different than mine. Implementation experience is used as planning tool.

    #29355

    Bill
    Participant

    Agile doesn’t mean that there are no requirements. In fact feature requirements are very important. It simply means that you don’t have to specify the behavior of the entire system in order to deliver value to the customer. Check out the Agile Manifesto. Three of the four values are “working software”, “customer collaboration” and “responding to change”. If you have fully planned out everything that you’re going to do, then, when change comes up, you have to throw away part of your plan – so why spend time coming up with a plan if it’s likely that you’re going to have to revise it anyway?

    In an effort to bring things around to the purpose of this forum, it occurs to me that the religious notion of God isn’t Agile either. According to believers, God has a plan. God’s customers (mankind) sometimes ask Him to make changes to His plan in the form of prayers. Most of those requests He refuses. He only grants the ones that already fit into his plan.

    God (such as it is) is the ultimate waterfall project manager.

    • This reply was modified 1 week, 5 days ago by  Bill.
    #29357

    _Robert_
    Participant

    Using ‘Agile’ is just part of a plan; to help reduce risk in said plan. Requirements are also plans. Are you making a poor assumption that a plan cannot be flexible? I even mentioned flexibility and contingencies in my original post. Planning and estimating a project has nothing to do with what god’s believers may say. Thirty years of designing computer boards and I never once had to include any supernatural line items in a project plan.

    Now I know many software developers who “just started coding”. It was very prevalent in the early days of 8 or 16 bit processors. Their code was always shite.

Viewing 4 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic.