|Perl Monk, Perl Meditation|
Re: Programming is combatby adrianh (Chancellor)
|on Jul 08, 2004 at 23:18 UTC||Need Help??|
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?
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
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.