I know some programmers are going to bristle at this. For some, it's because there are reasonable exceptions. For others, it's simply because they'll disagree (I get the latter quite a bit). So for your amusement, here's "Business rule #1 for programmers":
If you're not making or saving your employer money, you probably shouldn't be employed.
For many of us who are quite fond of paying the bills, this is a no-brainer. It's as useful as saying "don't try to remove ear wax with a razorblade."
While one can definitely argue that there are exceptions to this rule, for the vast majority of us, these exceptions do not apply. Yes, you want your code to be elegant and beautiful but if you're about to lose a $100K contract because you won't deliver on time, it's OK to cut corners. When customers are calling and screaming left and right about how they "can't connect", that is not the time to imperiously announce that you'll refactor the entire system to keep this from happening again.
Unfortunately, this is a failing I see in many programmers. They want "purity". Me? I want paychecks. I've been homeless. It ain't fun.
That's not to say that I scoff at purity, either. Anyone who's read my posts about grepping through a code base to remove misapplied "if/else", "ref", or "UNIVERSAL::" code knows that. The problem is being willing to do the wrong design thing now in order to do the right business thing now. It's getting back and fixing the design issues later which is the hard part.
In answer to your straw man who "imperiously announces that he'll refactor the entire system to keep this from happening again," I would tell him that's not his decision to make. Nor is it his decision to make NOT to refactor the system! Programmers that under-engineer to "save time" are just as bad as the ones that over-engineer in the face of pressing business needs. Either call could spell disaster without a proper understanding of the business situation and what kind of programmer has that?
-sam
Re:Do you really want programmers making the call?
Ovid on 2006-03-09T22:44:37
I think you and I are mostly on the same page. I never said that programmers should make this call. I see a lot of programmers railing against managemers who say "we need this done now" when, in fact, it really does need to be done now. When programmers get a better knowledge of the business side, they can better understand the business decisions (and that goes for the business folks knowing the tech side) and make more reasonable recommendations.
It reminds me of when I used to manage coffee carts while in college. Some employees would complain that we'd sell 30 cents worth of product for two dollars. They thought we were ripping people off. I then sat them down and showed them how we could sell that 30 cents for two bucks all day long and go out of business. For someone to focus on just the one little thing they do and not try to appreciate the things others do is a recipe for disaster. Many programmers, managers, secretaries, QA people, etc., are guilty of this.
Re:Do you really want programmers making the call?
samtregar on 2006-03-09T22:54:13
Sure, I've been there, getting the wrong answers from the boss. Some business people just aren't good at making informed decisions even when you've patiently explained all the tradeoffs and benefits. I think we, as programmers, need to be sure we're holding up our end of the bargain - delivering all the data the business-people need to make good decisions. When they make bad ones anyway then it may be time to find a new job. Until then it's our job to follow orders, and to make the best use of the time we're given.My objection to your "#1 rule" is that it implies that a programmer should know whether their actions are making money or not. I think that's a dangerous idea because I doubt many programmers are capable of knowing this most of the time. Certainly you don't want them guessing!
-sam
Re:Do you really want programmers making the call?
Ovid on 2006-03-09T23:03:00
True, but I see too many new programmers agonize and complain over "perfect" code, failing to realize that perfect is the enemy of the good. Of course, "perfect" is also highly subjective and changes over time. Companies are rarely hiring us for pure research. They're hiring us to get things done and either make or save money. I really do feel that one of the worst mistakes programmers make is forgetting that they're working for a business and not turning in homework.
Re:Balance
Ovid on 2006-03-09T22:52:00
It's our moral obligation to deliver quality even if our customers specifically state that they do not need it. If they refuse to pay for it, then it is our responsibility to say "no".Really? Define "quality" in such an unambiguous way that everyone will agree on it.
When I'm asked about this in interviews, the thing I make clear is that if I'm told to make a button pink and have it purr like a kitten when clicked, I'll do it (even though I might ask 'em why). However, if I'm told to do something illegal I'll refuse. Unethical? I'll probably refuse (I say "probably refuse" because I might be mistaken about the unethical nature of something). Insecure? I'll balk like mad but, if they insist and it's clear that they voluntarily bear the substantial burden of the risk, I'll agree (in other words, if I put unsuspecting customers at risk, I won't agree).
Re:Balance
Juerd on 2006-03-10T11:53:37
Defining quality is impossible because a definition cannot have the required balance, as that differs per institution, per situation.
As for your second paragraph, that's more or less what I do too. (Although most of the time, it is my *job* to avoid pink buttons.)Re:Balance
Aristotle on 2006-03-13T00:49:39
See The Crooked Timber Of Software Development and the awesome response Tye wrote at PerlMonks when I posted that link.
Re:Balance
btilly on 2006-03-17T06:54:22
I'd love to read that link. Your recommends are usually good.Unfortunately I can't because the site has an internal error.
Furthermore the internal error shows me that they present a full stack backtrace on internal errors. Which you shouldn't do in production because it allows people to debug their attacks against your site.
If they're recommending shortchanging program quality for business considerations, the current state of the site suggests that they may wish to re-prioritize...
Re:Balance
Aristotle on 2006-03-17T07:53:21
It’s still available from the Google cache, thankfully. I also have a local copy in my aggregator, should that too fail.
If you're not making or saving your employer money, you probably shouldn't be employed.
I agree entirely your statement should be obvious. I also agree that in many organisations it's not the programmer's role to know the best way for them to generate value; that's what managers are for.
However if one wants that pay-cheque to be bigger, it's worth finding out what's really important to your business. It's rare for developers to work in a vacuum, and knowing where the real priorities lay is often easier than one may think. If you do work in a vacuum, then have a chat with your manager. Say that you want to do a better job, and are interested in learning more about business priorities so you can do so. Managers love this sort of thing.
But how does taking an active interest in your employer's business improve your own salary? Well, it's simple.
Employees generate value (either revenue or savings) for a business. In most circumstances the business pays a fixed annual salary for this privilege, and pockets the rest. If you generate more value, then the business has a higher capacity to pay you. Most importantly, the business stands to lose significantly if you leave, so you can effectively negotiate that higher pay.
Taking an interest in effective value generation is also extremely valuable when switching jobs, or even striking out on one's own as a consultant.
It's worth noting that this has nothing to do with software development. In almost every job one can maximise one's personal gains by maximisng the gains of others.
