Thanks to "Uncle Bob's" recent pontifications on Hanselminutes and the Stackoverflow podcasts, as well as Jeff and Joel's appropriate disrespect of the "SOLID" principles, I've given a lot of thought to questions like "How perfect does a program really have to be?"; "How closely does it need to follow standards and 'best practice' templates?"; "Does it matter how the software gets to the result as long as it gets to the right result?"; "Is writing software really an engineering endeavor or something else?" It's the last question I want to focus on here.
As programmers, the vast majority of us are employed to deliver operational efficiency for a for-profit business. We automate the processing of business rules, allowing an organization to do more with less, at maximum speed and at the lowest cost. We are driven primarily by the needs of business, and as most MBAs will tell you: Business is War. If business is war, and my position in the organization exists to help us win the battles of this war, then professionally I have more in common with a warrior than an engineer. As such, quotes like Patton's "A good plan executed today is better than a perfect plan executed at some indefinite point in the future" should be on our motivational posters rather than the tedious theories of abstract principles. Only if your company has been fabulously successful with a product that is merely "good enough to get the job done" (hey Microsoft -- I'm talking about Windows 3.x, 95 and NT!) will you ever have the luxury of going back and engineering a perfect solution.
So to form this into a question: What are programmers: Engineers? Warriors? Something else?