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.

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.

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?

*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).