Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Programming is combat

by brian_d_foy (Abbot)
on Jul 08, 2004 at 07:36 UTC ( [id://372693]=perlmeditation: print w/replies, xml ) Need Help??

I've been collecting books on business written by former members of the military. For example, there is Business is Combat, written by a former F-15 pilot, and It's Your Ship, written by a former naval officer. There are a few more somewhere in the stack of books on my office floor.

My interest is more than acquisitive though: I've fantasized about writing my own, but applying it to programming. From time to time I take notes on it. I've been moving the same peice of paper onto and off of my desk for a couple years, but I'm going to dump that stuff here and get rid of the paper.

Most of this dreck has to do with leading a group of people, because that's what I do in the Army. If I follow the examples of the other books, I'll have to fill it with lots of meaningful stories of combat and danger.

For now though, my half-baked ideas:

Bypass points of resistance
There's a couple ways I could go with this one, but they both smack of loose cannons. The basic concept is to redefine the problem so the problem doesn't exist. There is a lot of old Soviet army doctrine tied up in this, too. Of course, this didn't work out so well in the latest US war.

Have an SOP
That's "standing operating procedure" to you civilians. You don't have to know it all before you start, but as you go along, make decisions about how you are going to do things, then do things that way. You can change how you do things, but otherwise you should try to do things the same way each time. This lets other people know what to expect and lets you concentrate on the parts of the problem that are unique rather than the parts that are the same.

Lead, follow, or get out of the way
The opposite side of this is "death by committee" where everyone thinks they should get to a chance to speak their mind or get their way. If you're the leader, lead, and if you are not the leader, follow. If you don't like that, get out of the way. Don't be the titular leader who lets people paralyze the project, and don't be the follower who thinks he should get his way every time.

Act, Don't think
Programming probably doesn't require the split-second decisions that more dangerous pursuits require, but it still has a lot of people who want to discuss things ad nauseam. The next time you're in a meeting that lasts longer than 45 minutes, think about how much value all that extra discussion is adding. Leaders have to stop the discussion sometimes, the followers have to realize that they can still say what they want to say, but in the hallways, around the water cooler, or at the local pub.

You never get good intel
Part of not thinking so much comes from the idea that the assumptions you started with are probably crap. It's not your fault. Things are going change, so don't get caught up in the big plan. XP talks a lot about this sort of thing.

Sometimes life sucks...
...and you still have to do the job. Complaining about it doesn't get the job done any sooner, and once you finish you'll have some good stories for the pub.

Learn other jobs
Get to know how other people do their job, and you will start to see why some things happen the way they do. You can sit in your cubicle all day long complaining about the people in accounting or marketing, and they are probably doing the same thing. Different groups of people have to operate under different constraints and conditions, and they have to answer to different bosses. Understanding some of those eases the pain. Be sure to check out the section on "Sometimes life sucks".

Take care of your people
The usual stuff goes here, but along with "Don't try to make everyone happy". People do whatever it is they do for a reason, and they need to move towards whatever goal they have. That may not always be possible, but you should at least know what those personal goals are and how you can help.

Train as you fight
The army says "More sweat in training is less blood in war". I'll really have to work hard to apply this one to programming. I got nothing.

The Creed of the Non-commissioned officer
I won't go into the NCO Creed here (you can find it on Google), but the main point is that you aren't going to make anyone do the job you are supposed to do, and you won't create unnecessary work for others. To paraphrase: My coworkers will have maximum time to do their own job.

Unless someone is shooting at you...
This one is going to be a bit touchy because people are invested in their own notions of urgency. I've pissed off more than a couple bosses by telling them that I'm not too worried because no one is shooting at me and nobody is bleeding. When you start to tense up over a programming bug, step back and get a little perspective. Take a deep breath and control your stress. Unless someone is trying to kill you right then, you can probably relax a bit.
--
brian d foy <bdfoy@cpan.org>

Replies are listed 'Best First'.
Re: Programming is combat
by EvdB (Deacon) on Jul 08, 2004 at 09:02 UTC
    I think there is a certain amount of milage in this. A couple of comments on some of your points:

    Act, Don't think. This is like firing a tracer bullet. In code write something quickly which is cheap and brittle. If it does the job then expand on it, otherwise fire another tracer bullet. I must confess that my analogy makes me queasy, human life and all that.

    Train as you fight. I think this can be applied quite simply. For perl it could be written as 'obfu when your off-work'. For me getting to grips with map relied heavily on obfu-like challenges that would not crop up in normal coding. Now that I can use map I can see all the times when it can be used where before I would have used a foreach loop or similar.

    Update: Train as you fight is (I think) meant to be 'Train in the same way you fight', not 'Train whilst you fight'. Bizarrely I seem to have missed both possible meanings with my comment above. Hmm, normal service will resume shortly...

    --tidiness is the memory loss of environmental mnemonics

      Actually, "train as you fight" has both meanings, but I wasn't thinking about the second one. Rommel is famous for keeping the Afrika Corps busy with training when they weren't fighting, but a lot of units train up during breaks in combat.
      --
      brian d foy <bdfoy@cpan.org>
We are the logisticians of information
by dragonchild (Archbishop) on Jul 08, 2004 at 12:49 UTC
    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

      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

      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

Re: Programming is combat
by BrowserUk (Patriarch) on Jul 08, 2004 at 11:50 UTC

    I pretty much agree with everything you wrote--but would I buy the book? Probably not. It would be like me buying a book on how to tie my shoes.

    Not that I always, or even regularly followed all those tenents when I was in the position to have to. I intended to, but we all know about good intetions. Then again, I haven't worn shoes with laces for 20+ years either.

    The problem with this type of book is you need public track record for it to be of great interest. If Carlos Ghosn wrote a "how to manage..." book, people would probably cough up and read it.

    With respect to Train as you fight. That's another way of saying "practice makes perfect". For applicability in perl, I suggest it could be translated into stuff like 'code your throw aways and one offs the same way you should code your production apps'. Always indent properly. Pass parameters to/from subs instead of using globals. etc.

    Most people write more one-offs than they do production apps and if you get into the habit of using bad practices in your one-offs, the temptation to skip the good techniques in your production apps when time is pressing (Isn't it always!), just becomes to strong.

    If a soldier trains as if it were real, he is more likely to react in the correct way when the chips are down.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
      Oh, no one is going to buy the book. I starting collecting these sorts of books because they show up on the remaindered racks at book stores. This is only a fantasy of mine because it would suck away a lot of free time and get me nothing that I could use to pay rent.

      For me, "train as you fight" shows up mostly as a t directory. When I am good about this (and I am not always that good), I at least create tests to ensure the code compiles and the pod is valid. When I get over that little hump, adding other tests is easy: I already have the t directory and am using "make test".

      --
      brian d foy <bdfoy@cpan.org>

        I'm still to be, and don't expect to be, convinced of the value of \t directory and Test:* modules.

        Don't misread that. I'm strong on tests and testing. It is the only tool short of suck-it-and-see that we yet have for trying to establish the quality of the code we produce.

        The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code. You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.

        In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.

        Design by contract shows great potential (IMO). I had hoped that something similar would be integral to P6, but I haven't seen any signs of it. I'm hoping that the (proper) macro facility will allow this to be added in fairly short shrift after the fact. Time will tell.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
      With respect to Train as you fight. That's another way of saying "practice makes perfect".

      With respect, the complete maxim was taught to me as "Train as you fight, fight as you train." If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear. If your training prescribes that you must use a checklist to launch the alert fighter, then you must use the checklist when the klaxon goes off.

      Relate this to programming:

      • Your program, application, or system must pass security certification and accreditation. So don't build your work with hard-coded, plain-text passwords.
      • Your work is going to have to meet the standards of Sarbanes-Oxley, plan for it and program accordingly.
      • QA testers are going to evaluate your work against requirements, write code that satisfies requirements.

      For those of you old enough to remember Sgt Rock and his Howlin' Commandos, "Nuff said"

        Hm. I don't think the analogy holds very well.

        If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear.

        Not all fighting is done wearing NBC suits, and as sure as hell, not all training is. Sure, they train under those conditions so as to have experienced them, but I doubt it makes up more than 2 or 3% of their total.

        Security.

        The app I wrote to index the ingredients in my sisters recipes has hard coded credentials. If hackers crack it, I hope they enjoy her profiterole recipe as much as I do.

        Choosing what to not to expend effort securing is as important as securing those things need it.

        I'd be interested to hear your solution to the problem of supplying credentials to your DB apps? (Assuming that they can't be entered manually every time. Eg. Web apps?)

        Sarbanes-Oxley

        Doesn't affect me (note my handle). But from what I scanned on wikipedia, it probably rarely affects programmers in general, being aimed at corporate/legal processes rather than programming in general. I can see how for example it might be desirable to have an MIS suite provide hooks for auditing, but a good auditor would probably ignore that on the basis that they can be as bogus as the glossy company brochure.

        Requirements

        Can't argue directly against what you say, but I see little correspondance between that and military practices and doctrines.

        Then again, maybe I can argue against it. Requirements (and plans) are a fine starting point, but in all but the most repetitious of projects, they change. In common parlance, "the best laid plans of mice and men", or as the military would have it. "No plan survives the first encounter with the enemy."


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Programming is combat
by demerphq (Chancellor) on Jul 08, 2004 at 12:18 UTC

    Combat as aprogramming metaphor is indeed interesting. Some thoughts for you: Soviet Military Doctrine was to "attack along organizational divisions" so for instance the Fulda Gap was the expected site of WWIII as that was the dividing line between the US and British Forces. This meant that they would exploit the inablity of the opposing forces to communicate with each other. Also the the Soviet Doctrine was "a full speed ahead" strategy. With troops (armor etc) moving at high speeds, Nato doctrine was the "sponge" (backed up by action point lines.) So while the soviets would try to go as fast as possible through the opposition (while exploiting poor coms between organizational units) the NATO strategy was to wait for them to pass through the lines then attack them from the sides and back. They didnt try to outright prevent the Sovs from getting through, they would essentially let them go and then get them in their vulnerable behind instead. All of this was backed up by a tactical nuclear posture that stated that if the Soviets crossed certain lines the response would be to turn much of Germany into a nuclear wasteland.

    Personally I can see various aspects of these strategies in software development. The place where your development efforts are going to go wrong is when you have poor comms because of organizational "ownership". Sometimes its no good trying a strong defence against various issues, instead its better to structure your systems for graceful failure followed by preventitive shut down.

    No doubt you could work these metaphors further... Anyway, nice node. ++ to you.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


Re: Programming is combat
by Hanamaki (Chaplain) on Jul 08, 2004 at 10:01 UTC
    My advise is to write that book and if you are finished to put it for a minimum of six month into your drawer without touching it. Than, if you still think it is a good idea to publish such a book, without hurting your reputation, go for it.

    We all have from time to time new experiences, which will change our thinking. Wether this is reading Julius Caesar, SunTsu, being exposed to a new culture or language, or whatever. This very often leads to book ideas like "Go and...", "Zen and...".

    If they tell me I have to go back to kindergarden, back to the Navy or whatever, I probably will be tempted as well to connect everything of these intensive experiences to my current life. Probably the combat methapor is as good, as all methapors. "Programing is like commuting by train" probably could lead to an insightfull book as well.
Re: Programming is combat
by castaway (Parson) on Jul 08, 2004 at 11:28 UTC
    My thought on Train as you fight (Which sounds the opposite to "More sweat in training is less blood in war" to me, as that implies training before fighting.. but whatever.. ):

    Train/learn during development/design, as opposed to during the "war", which I would define as crisis times when a customer has found a bug that needs to be fixed yesterday. At this point, there shouldnt be learning going on, just application of knowledge.

    Overall, it sounds like a good set of anologies, that make quite a bit of sense.. (Why does it remind me of of the Marcinko books?)

    C.

      Actually the Train as you fight and More sweat in training is less blood in war are two seperate principles. First, the "More...." implies that the more you train, the less lives are lost during war. The second, "Train...", implies that if you train differently than you fight, you are preparing for the wrong war. Basically its a quantity vs. quality type of difference. Both imply that less casualties will occur if there is training involved.

      I started writing about a corrolary between this and programming and realized that you said almost verbatim what I was starting to say...so I will bow, once again, to your wisdom castaway.

      Paulster2


      PS: Marcinco never had it so good.

      You're so sly, but so am I. - Quote from the movie Manhunter.
Re: Programming is combat
by NovMonk (Chaplain) on Jul 08, 2004 at 12:34 UTC
    I'd like to suggest an alternative to BrowserUK's comment "practice makes perfect," and one that his example actually brings out quite well. Practice makes permanent. That is, what you do, even while you're just "practicing" becomes habit. So it's worth the extra time to get it right, every time. I heard this in the context of a singing workshop, but find it has applicability in most areas of my life.

    Good node, and good discussion. ++ and Thanks.

    Pax,

    NovMonk

      Ah, yes, indeed. Thanks.

      In my military circles, we call this "muscle memory" (although it probably exists elsewhere, too). Do a physical movement, like drawing a pistol from a holster, a couple thousand times and it seeps into your brain so that you don't have to think about it.

      For instance, I have this really annoying keystroke memory in my fingers. If I want to change into a directory, I type "cd <return>", then out of nowhere I type "make <return>" even if that is not what I meant to do. I just do that sequence so often that it flows right out. Even worse than that is "make test <return>" showing up at any random coomand prompt.

      --
      brian d foy <bdfoy@cpan.org>
        Interesting node,

        On the subject of practice makes perfect, what I'd add is this; It doesn't!

        Let me qualify this; The technique of repetitively practicing a given action to effectively program your brain to perform this action without the need for thought is well stablished in sports science and military training. What you are actually doing is programming your cerebellum, which coordinates movements, to coordinate a given set of movements perfectly. The big but here is that to make this truly effective, you must make sure that the practice movements are exactly as the intended movement must be when used in anger.

        As a friend of mine once said, "Practice does not make perfect. Perfect practice makes perfect."

        The bottom line for this in programming is that you must practice programming as you mean to program "in anger"; Don't take falsely lazy shortcuts, for example.

        Elgon

        PS - Interestingly enough, I learned this principle largely in Long Range Rifle Shooting, in which I compete at international level.

        "Stercus! Dixit Pooh. Eeyore, missilis lux navigii heffalumporum iaculas. Piglet, mecum ad cellae migratae secundae concurras."

        For instance, I have this really annoying keystroke memory in my fingers...

        Every Unix account I've had since 1988 has had 'adrianh' as my login. It's now burned into my fingers and I cannot type/write 'Adrian' without adding the final 'H' unless I'm trying really hard.

        This can be annoying when you're filling in tax returns, etc. ;-)

        Well, yes, but programming, and singing are not primarily physical, muscle memory, things. Both require a lot of conscious thought, and carry a temptation at times to do what's needed to "get by." Maybe that's where the "programming as combat" metaphor begins to break down.

        There are times when it's absolutely appropriate to "get by"-- sometimes writers, to use another example, will combat writer's block by writing something they know isn't good, with the intention of changing it later. But in general, it's important to remember that you perform what you rehearse-- and it's a good idea to take the time to get the notes really solid before you go out on the stage. Or to apply it back to programming, habits of thought affect how you approach new problems, what it occurs to you to try to make things happen-- and that's a case where having practiced good programming practices can really save your behind.

        Obviously, I've been doing too much reading lately in my self-improvement quest. I'll add your book to my list if you finish it though, if only to show good monastic solidarity (probably won't buy it, but I'll encourage my local library to. Sorry, no independent wealth here. That vow of poverty really stinks sometimes.)

        Pax,

        NovMonk

Re: Programming is combat
by zby (Vicar) on Jul 08, 2004 at 09:29 UTC
    I don't have much of experience with combat, but if I am to believe the popular media on this subject (and my army training did enforce that view) it usually is a total chaos and as a programmer I do see here much similarity with many programming projects. I think the points about managing in the face of a total mess could be very insightfull.
Re: Programming is combat
by dws (Chancellor) on Jul 08, 2004 at 15:59 UTC

    I've fantasized about writing my own, but applying it to programming.

    Several years back I had some discussions along these lines with a coworker who'd been in the Isaeli army. One of the sticking points we had was on the subject of collateral damage. In a military campaign, particularly in a "take that hill, dammit" action, you expect collateral damage as a matter of course, but it's most often someone else's problem to clean up. In software development, collateral damage is another source of defects; you might try to shove it out of the way (or define it away), but it still represents a pile of new defects, and you're unlikely to be able to avoid dealing with those defects for long without taking a reputation hit.

    Dealing with collateral damage is where a number of approaches to reframing software development as X fall down. The level of precision, correctness, and robustness that software development requires is rarely understood or appreciated outside of our domain.

      In software development, collateral damage is another source of defects; you might try to shove it out of the way (or define it away), but it still represents a pile of new defects, and you're unlikely to be able to avoid dealing with those defects for long without taking a reputation hit.

      I've found the technical debt metaphor very useful for talking about this sort of thing. Especially with non-programmers.

Re: Programming is combat
by hv (Prior) on Jul 08, 2004 at 13:03 UTC
    More sweat in training is less blood in war

    Hmm, more bugs found by the test suite is less downtime in production - reminds me of Gordon Ramsay and "don't let your mistakes leave the kitchen".

    Hugo

Re: Programming is combat
by zentara (Archbishop) on Jul 08, 2004 at 14:06 UTC
    If "Programming is Combat " , then I must ask the question..."Who or what is the enemy?"

    Is it "unruly entropy-laden electrons", disruptions in the "stream of correct information", or greedy bosses trying to squeeze productivity out of you?

    We (especially in the US) are being overwhelmed with the "military mentality", but is it reality?

    It seems ( to me anyways) that reality is learning to live "in harmony" with the earth and the cosmos; and the "real battle" is within ourselves as we resist the "natural harmony" of things.

    Or maybe its like Pogo said "We have met the enemy, and he is us".

    So how about looking at programming as "making love".....we learn tricks to bring the code to "electronic orgasm" ( i.e. It RUNS :-) )


    I'm not really a human, but I play one on earth. flash japh
      It's not so much that there is an enemy, but that we can deal with life in the same way in different situations. Different environments emphasize different facets of a solution and add perspective.

      I can't carry any metaphor too far because ultimately one thing is not the other, so they are different. The trick is to find the areas where one can beneffit from knowledge of the other without experiencing it.

      --
      brian d foy <bdfoy@cpan.org>
      Pogo - put out or get out :D

      I wholehartedly agree. If "Programming is Combat", then I would define programming as "something which, while sometimes necessary, is best avoided". I just don't see the average coder envisioning themselves as being thrust into the middle of a violent coding session.

      The Military way of thinking is far too inflexible: as my Army father used to say, "there's a right way, a wrong way, and the Army way". It seems to run counter to TMTOWTDI, and indeed to every notion of great programming that I'm aware of. The whole of training and management in the Army is to keep people alive -- and that means that they must trust their commanders and be willing to blindly follow orders (it will probably save their lives).

      While I agree with some of the "lead, follow, or get out of the way" mentaility, I have to say that it goes much too far to be effective with a team of independant, highly-intelligent people. Lead, yes. Be willing to follow a leader, yes. Control the desire (in yourself or in others) to stagnate a project because someone "wants their own way". All of that can be accomplished through judicious use of democratic principles. Yes, strong leadership is required to ensure that everyone abides by the decisions of the group, but a leader who will simply quash dissent is a poor leader. Unfortunately, the military method of leadership often results in quashing dissent; quite possibly because the people who are implementing it haven't had the extensive officer's training that balances the "strict leader" theory.

      Rather that saying "programming is like X", how about "programming is programming". Metaphor and analogy are useful, up to a point, but letting a thing be what it is usually ends up being a better long-term strategy. That's a core principle of Taoism at work for you there -- we can learn about the Tao through metaphor and analogy, but "the Tao that can be named is not the true Tao". Likewise, we can learn the art of programming by comparing it to life, or military service, or the manufacture of hot-air balloons; yet, "the art that can be named is not the true art" -- all the metaphor in the world will not produce a better programmer than someone who just "gets it". And, that is achieved like it is in any other art -- practice, experience, shared knowledge, and practice.

      radiantmatrix
      require General::Disclaimer;
      s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

Re: Programming is combat
by QM (Parson) on Jul 08, 2004 at 18:22 UTC
    Along similar lines, I have this posted in my office:

    The Intrapreneur's Ten Commandments

    • Come to work each day willing to be fired.

    • Circumvent any orders aimed at stopping your dream.

    • Do any job needed to make your project work, regardless of your job description.

    • Find people to help you.

    • Follow your intuition about the people you choose, and work only with the best.

    • Work underground as long as you can - publicity triggers the corporate immune mechanism.

    • Never bet on a race unless you are running it.

    • It is easier to ask for forgiveness than for permission.

    • Be true to your goals, but be realistic about the ways to achieve them.

    • Honor your sponsors.

    [From Intrapreneuring, Gifford Pinchot III.]

    I don't pretend to understand them all deeply, but they speak volumes.

    -QM
    --
    Quantum Mechanics: The dreams stuff is made of


      Sounds too good to be true.
      All's well that ends well?
Re: Programming is combat
by adrianh (Chancellor) on Jul 08, 2004 at 23:18 UTC
    I've been collecting books on business written by former members of the military ... My interest is more than acquisitive though: I've fantasized about writing my own, but applying it to programming.

    While I find the author's style of presentation monumentally annoying you may find ARM/CL of mild interest (a sketch of a software development methodology with what sounds like military inspiration.)

    For now though, my half-baked ideas:

    Some random comments on the half-baked ideas ;-)

    Bypass points of resistance

    Not quite sure I understand what you're getting at here. Would this be an instance of what you're talking about?

    <anecdote>

    I was once worked on a project that was hitting severe problems because the customer's project goals and the DBA's working practices were badly matched.

    Basically the customer was asking us to develop something quickly to deal with a short term problem. The DBAs wanted everything to integrate seamlessly with the existing company wide Oracle infrastructure. We (the developers) were stuck in the middle trying to explain to the DBA why the customer's project was different, and explain to the customer why we couldn't do something one way because of the existing company database.

    This lead to everybody shouting at us, and little progress.

    The solution: redefine the DBA group as part of the customer group. They were both dealing with business-level decisions after all. They could batter each other to death sorting out their business level priorities and then speak with one voice to the development team.

    </anecdote>

    Have an SOP

    The dark side of an SOP is when the situation changes and the previous standard procedure becomes counter productive. Spotting when this happens can be hard. Good advice on how to deal with this would be a useful thing.

    Lead, follow, or get out of the way

    Is this this another way of looking at the demarcation of roles?

    For example one of the things I like about agile methods like XP and Scrum is the clear demarcation between Customer and Developer. The Customer owns all business level decisions. The Developer owns all code level decisions. Of course both parties talk to each other, but the Developer doesn't lead the business, and the Customer does not lead the coding.

    Act, Don't think

    Is this another way of saying that feedback is often more efficient than advanced planning?

    You never get good intel

    Amen. Embrace change and all that. I cannot recall a single project that I've worked on where the requirements haven't changed, often radically, during the project's lifetime. Development methods that pretend otherwise are doomed to failure.

    Sometimes life sucks... ...and you still have to do the job

    Do you? Would surrender sometimes be the right action?

    I re-read Yourdon's Death March a few months back. After working on a couple of nasty projects fairly recently even more of its content sunk home the second time around.

    I've walked away from one or two projects because they were badly thought out, badly run and doomed to failure. Nothing I could do or say would change the situation since nobody was prepared to listen. Staying and pretending otherwise would have been dishonest and a pointless sacrifice.

    Another point is that if life sucks then it's probably worth while taking some time to figure out why it sucks, and hopefully prevent it sucking next time :-)

    Learn other jobs

    The more people know the better. As well as making communication easier it makes the team more flexible.

    Train as you fight

    Possible examples...

    The Creed of the Non-commissioned officer

    I have to admit that I'm having problems seeing how the metaphor applies here. Maybe that I misunderstand what NCOs really do, but I don't see that role in the projects that I've worked on.

    Unless someone is shooting at you...

    Indeed. I still find it odd the number of people I've come across who have sacrificed their personal lives, their relationships or their health to what is, after all, just a computer program.

Re: Programming is combat
by Ambidangerous (Scribe) on Jul 09, 2004 at 11:39 UTC

    Our platoon had been in directory for six months. We got orders from the kernel to proceed to the ../combatzone. We went into the code jungle. Corporal Lint was walking point, but we had air support from the 111th ddd division.

    Suddenly, the bugs were all around us--they'd been hiding in a thick growth of inodes, wearing special dot-camoflauge so they looked like "." and ".." Private A. Out took the first hit, a segmentation fault that, as is so often the case, proved immediately fatal. Our group started losing morale, and we started to retreat, but ahead we saw the sign:

    use warnings; 1 km

    use strict; 1.1 km

    Lieutanant Perl took command, and led us to safety through the binary jungle. Soon, we had our casualties safely under the care of the Perldoc, and were busy splaining the problems we'd encountered in the operation. Because of his quick thinking, the lieutenant was promoted to 6.0

    $jPxu=q?@jPxu?;$jPxu^=q?Whats?^q?UpDoc?;print$jPxu;
Re: Programming is combat
by tilly (Archbishop) on Jul 09, 2004 at 18:56 UTC
    To some extent there are bound to be parallels because programming and the military both have to do with how people work.

    That said, to me the most interesting organizational issues around programming are ways in which programming should differ from what you see in hierarchical institutions, like the military stereotypically is. (In reality the military varies, but the stereotype...)

    An example of such an issue is the inevitable element of CYA. When you have a lot of hierarchy, inevitably when something goes wrong, someone tends to get blamed and take the fall. When people worry about that, you get a whole series of communication barriers. People in positions of power do not wish to hear bad news, subordinates do not want to present bad news, and nobody wants to admit to mistakes because they don't want to possibly take the fall when things go wrong. But if you don't admit to mistakes, then you can't get feedback and learn. If bad news doesn't move up the hierarchy while good news does, then there is always a serious reality disconnect at the top of the hierarchy.

    One result of this effect was documented back in The Mythical Man-Month. In a project that ultimately comes in ahead of schedule, through the project the estimate of when it will finish keeps on moving forwards. By contrast a project that will come in late has a schedule that does not budge until 2 weeks before the due date - and then it stays "just 2 weeks away" until it is done. Even if it ultimately takes double or more what it was originally scheduled to do. Which is part of why deathmarches turn into such grueling and long sprints - people started thinking that they only had to push for 2 weeks and then it dragged on.

    This phenomena is why it is so important to do project planning with 100% milestones - things that cannot be miscommunicated up and down the hierarchy. It is also why the best leaders (as documented in Good to Great and elsewhere) actively seek out bad news because they know that it won't rise to the top naturally.

    For a memorable reminder of this phenomena, just remember how shit happens:

    In the beginning was the plan.
    And then came the assumptions.
    And the plan was without substance.
    And the assumptions were without form.
    And darkness was upon the face of the workers.
    And they spoke among themselves saying "It is a crock of shit, and it stinks".
    And the workers went unto their Supervisors and said "It is a pail of dung, and none may abide the odour thereof".
    And the supervisors went unto their Managers, saying, "it is a container of excrement, and it is very strong, such that none may abide by it".
    And the managers went to their Directors, saying "It is a vessel of fertilizer, and none may abide by its strength".
    And the Directors spoke among themselves saying to one another, "it contains that which aids plant growth, and it is very strong".
    And the directors went to the vice presidents saying unto them, "it promotes growth, and is very powerful".
    The vice presidents went unto the president, saying unto him, "this new plan will actively promote the growth and vigour of the company, with powerful effects".
    And the president looked upon the plan and saw that it was good.
    And the plan became policy.
    And that is how shit happens.
    It is funny because it is true. It is true because of how information is systemically distorted moving up a hierarchy.
      It is funny because it is true. It is true because of how information is systemically distorted moving up a hierarchy.

      Up, down, or sideways, GIGO works in all directions, even with non-managers. World views that differ from the information source tend to add garbage into the information stream.

      I suppose it's just most noticable since managers' world views tend to differ radically from most sane people (e.g. distrust bad results; go non-linear if it really turns out to be bad). Where I work I see a lot of distempered stuff come down from high above, which I suppose had some rational intent at the beginning. Lukily, by the time it gets to my level it is so badly distorted there is nothing left to implement...

Re: Programming is combat
by pfaut (Priest) on Jul 08, 2004 at 14:14 UTC

    My take on 'Train as you fight'...

    I worked in a place where the managers would always complain about being too busy to send people to training. They failed to realize that pulling someone out of the fire for a week to get them trained on something could bring them back refreshed from the break and more capable of attacking the problems with their newfound knowledge and skills. They never had time to learn to do it right but always found time to do it over (and over...) again when the first attempt came up broken. I got tired of going to meetings there because they would just devolve into discussions of why things couldn't be done rather than how they could.

    90% of every Perl application is already written.
    dragonchild
Re: Programming is combat
by bluto (Curate) on Jul 08, 2004 at 15:22 UTC
    I worked on a large programming project for a few years which was distributed over various locations on the internet. I've since moved on since it devolved into bickering factions without any real leadership. It could have used a lot of the points you brought up here (esp "Lead, Follow, ..." and "Learn other jobs").

    The best thing about the work was: The golden rule (i.e. mentoring, debugging, etc. when others needed it the most). Nothing beats a cooperative team environment. The worst: Infighting over, or just plain usurpation of new development work while leaving the scraps (i.e. user documentation, integration/system/regression testing, etc) to others. It's been noticed a million times before, but things just seem to work better when there are small teams which are located together. (I'm assuming this is true in the military as well).

    Update: Hit "Create" too soon and needed to edit a little.

Programming is ...a polar expedition??
by runrig (Abbot) on Jul 09, 2004 at 06:48 UTC
    Most of this dreck has to do with leading a group of people...

    I'm not sure I can apply it to programming, but I was browsing a book on leadership that used Shackleton as an example (I think it was "Shackleton's Way: Leadership Lessons from the Great Antarctic Explorer", though it looks like you get a deal from Amazon if you buy it along with another 'leadership by way of Shackleton' book :). Not exactly military/combat, but definitely leadership under extraordinary circumstances. Maybe one lesson is 'you can accomplish an awful lot even if you're not entirely successful' (and I find it truly amazing that they got through it without losing a single person) :-)

Re: Programming is combat
by chris_nava (Acolyte) on Jul 09, 2004 at 07:55 UTC
    "Train as you fight" eq "Don't cut corners when it appears not to matter." All your "one off" scripts should be well written, commented, indented, use strict, etc. This practice "trains" both your physical and mental "muscle memory" to follow good practices when it does count.
Re: Programming is combat
by greenFox (Vicar) on Jul 09, 2004 at 08:13 UTC

    I personally find the fashion for military metaphors disturbing, I don't think there is any healthy context for it. Programming as art or Programming as poetry are books I would much rather read.

    --
    Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

      The military metaphors can also get a company into legal trouble, even in the US. There is one well-publicized case where company strategies with cool names like 'Death Star' are paving the way to realtime in club fed.

      I suspect that many executives are shocked, I mean *shocked* to hear that the strategies they got from a management book that they found at Borders, a book with stylish references to Sun Tzu, this book has strategies that are downright illegal! I'm shocked, your honor, it should be illegal to print such things.

      I agree, greenFox, as programmers we don't need to think or work in the military context, and we would be better off to use a different metaphor.

      Make love not war!

      Update Hmm.. I tried responding to the node below maybe I screwed up or perhaps it was reaped. Anyway, the idea is that when you get in trouble for something, such as Enron did after they stole billions of dollars from California, it turns out that your state of mind when you did the crime makes a big difference. When you use cool names like 'Death Star' for your strategy (which was used in California and Oregon, not offshore), it is more difficult to claim that you didn't mean any harm. It is the difference between a simple misunderstanding, fraud, and racketeering.

      Some energy lobbyists still claim that the 'Death Star' strategy is legal, but they never refer to it by the 'Death Star' name, because it would be a poor legal strategy to do so.

      There are numerous articles that you can find on yahoo that explain the strategies and the legal arguments in this case.

      I suppose that if you aren't concerned that anything that you ever do will be questioned legally, you don't need to worry about what you call things. As a book author, you would be in good shape.

      It should work perfectly the first time! - toma
        Which company are you talking about? I know that Enron used a lot of Star Wars references for their offshore activities, but it wasn't the names that got them into trouble. If you are talking about something else, please supply the specifics.
        --
        brian d foy <bdfoy@cpan.org>
        I still haven't found anything that supports your claims. No article I ran across said anything about Enron getting in trouble because of their choice of names (which also included "Ping Pong" and "Get Shorty").

        Their name was a poor choice, but as far as I can tell they haven't been indicted for naming a business strategy. If you have specific links to actual articles, please post them.

        You told me privately that the "illegal" activities you refer to are really just things that violate your own companies policy. That hardly makes those activities crinimal. That a corporate lawyer told you not to do something doesn't affect the legality of the action: they just don't want you anywhere near trouble so they draw the line further back.

        Several non-governmental organizations use a military metaphor without legal incident. The Salvation Army even put s it right in their name. Southwest Airline pilots wear bomber jackets. Private security companies are para-militaries. Mall security guards dress like they expect gun battles. US citizens can wear most of our military's uniforms (without identifying insignia) without even getting a second look from a cop. It is simply not illegal.

        --
        brian d foy <bdfoy@cpan.org>
Re: Programming is combat
by artist (Parson) on Jul 09, 2004 at 14:07 UTC
    Unrelated to programming and still related as the topic. Here is what Kasparov (The great chess player) has to say about politics.
I like it; you should write it
by Your Mother (Archbishop) on Jul 10, 2004 at 04:49 UTC
    Be prepared for supply chain interruptions.
    Time, money, disk space, desk space, clock time, necessary ergonomic gear, permitted work hours...
    The Brass have eyes bigger than their stomachs.
    You will absolutely be ordered into conflicts and situations that your superiors grossly underestimated...
Re: Programming is combat
by bsb (Priest) on Jul 12, 2004 at 01:14 UTC
    Most of this dreck has to do with leading a group of people...

    I reckon it's the personnel management aspect that has the most to gain from a combat metaphor. Since in programming you're not (usually) in conflict with another intelligent being. Strategy is difficult because the confusing, inconsistent jumble of human thought is involved. In large scale military strategy, many minds are involved and often acting under severe stress. There's so many variables, so many unknowns, that it's intractable.

    Programming problems are simple, predictable and usually much more easily grasped in comparison. I often find it more difficult negotiating with other staff about pragmatic design choices than actually coding solutions because the people are smart and complex while the solutions I code are necessarily limited by my own understanding.

    ... I wonder if quantum computing will do for programming what nuclear weaponry did for strategy? Damian Strangelove and the Doomsday Module

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://372693]
Front-paged by mojotoad
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (5)
As of 2024-03-19 11:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found