http://qs321.pair.com?node_id=372773


in reply to Programming is combat

According to Sun-Tzu, who wins the war is almost always who wins the logistics fight. This has two implications when it comes to programming.
  1. The logistics of programming - we have a set of needs that have to be provided, just as an infantryman has a set of needs. Without these needs being fulfilled, we will fail in our fight. These needs are well-known:
    • Solid, unshifting requirements
    • Time to reflect and look at the big picture
    • Time to provide a design
    • Time to write unit-tests
    • Time to actually write the code
    • Other professionals who do the system test
    • The ability to push back when anything we are lacking

    The good general is the one that provides these items for his troops. Often, like my current situations, my general is inadequate, but I have an excellent lieutenant. I also attempt to be a good NCO for my troops.

  2. The logistics of information - every battle that has ever been won and lost did so on the basis of timely and good intelligence. Even more so that the logistics of goods, the logistics of information wins and loses battles. There is an example in the US Civil War where the North accidentally found the battle plans of the South. The North was outgunned, had poor morale, and had the weaker ground. Yet, they won the battle so decisively that it is often considered the turning point of the war.

    As IS/IT professionals, we are the logisticians of information in the world of business. We provide the capability for information to be available at the fingertips of our generals. We don't gather the information - we facilitate the gathering. We don't organize the information - we implement the organization. We don't analyze anything - we make sure that those who do can find the information they need.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Replies are listed 'Best First'.
Re: We are the logisticians of information
by freddo411 (Chaplain) on Jul 09, 2004 at 18:01 UTC
    I think that "Solid, unshifting requirements" would be analogous to perfect intellegence. Nice to have, but it doens't work that way in the real world. However, one should always try to get as close to it as possible lest you end up fighting the wrong war, or the war wrong.

    I really like the metaphor of IS/IT as logistics. It is very difficult to program well if one doesn't have good basic supporting infrastructure:

    * A developement box
    Is an OS that is patched and working, provided by IT?

    * A UAT environment that is a good copy of production

    * A seperate production box
    If you dont' have this seperation, then it becomes very difficult to use good practices like load testing, practice installs, practice migration, User testing and acceptance, etc.

    * Backups and version control software.
    A must have, and a must use!

    * Testing (as mentioned in parent threads)

    * Shared software libs
    Does programmer A use common code from programmer B? How does A know about B' code?

    * Installation tools
    Its fine to code the next release but have your designed, coded and tested the installation scripts?

    * Good software tools
    Does management pay for the software tools requested by the workers? Is there a modern bug-tracking DB used by the org? Other electronic collabaration tools? Shared docs?

    * Good information and UI design
    ( I hate my companies products because we don't have this)

    * Good documenation for your products

    * Good human resource management
    Who fills in when I'm gone? Does everyone have a desk, a chair and a phone? Will I loose the best programmer over a cheap, easy to fix problem? ( not enough parking, no flex time to go to the DMV, no cokes in the fridge? )

    * Good project management
    Has the project schedule been vetted with the programmers or driven by unrealistic external needs? Is there effective feedback from the work team back into the requirements/schedule?

    * Good Strategic management
    Lots of canceled projects/efforts and changes of directions? Low morale?

    If you fail to provide these things to your 'troops' (aka programmers) then they will be less effective. Provide these things and you have a force multiplier.

    -------------------------------------
    Nothing is too wonderful to be true
    -- Michael Faraday

Re: We are the logisticians of information
by adrianh (Chancellor) on Jul 09, 2004 at 15:31 UTC
    Solid, unshifting requirements

    If you believe in these then I have this bridge you may be interested in ;-)

      *laughs* I don't believe in them. I am merely stating that for us to be truly successful, "solid, unshifting requirements" go a long long way. In fact, I'd say that if I had solid, unshifting requirements and not much else, I'd do better than I would without them, but with everything else. Would you disagree?

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

        If someone handed you truly solid, unambiguous requirements, that cover all cases then you've been handed your final program, only written in the wrong language. If anyone could guarantee a source of requirements like that, then we could just write a good compiler and get rid of the programmer.

        Shifting and ambiguous requirements are not just an annoying part of your job, they are why you have a job.

        I'd say that if I had solid, unshifting requirements and not much else, I'd do better than I would without them, but with everything else. Would you disagree?

        No, I wouldn't disagree.

        If I had a little man that could spin straw into gold I'd have much less trouble paying the rent each month. Would you disagree? :-)

        In my opinion fixed requirements are one of those harmful lies we tell ourselves. It encourages us to focus on the impossible (fixing the requirements in stone), blame the wrong people (it would of worked if the client hadn't changed things) and prevents us addressing the real problem (finding a process that can deal with the reality of changing requirements).