The programmer is the last link in the chain of a software project. Everyone higher up the organization chart can leave out details, but the programmer cannot. Anything left unspecified will be decided by the programmer. He cannot pass the buck because he has to make something work. Programmers make good decisions, bad decisions, and many arbitrary but neutral decisions.
When you see software with a silly interface, odds are the interface details were not specified and the programmer chose the path of least effort. Why should I press # after entering my five-digit zip code on a phone? It’s logically possible to determine what my zip code is as soon as I enter the fifth digit, but it makes life easier for some phone system programmer if the pound sign is a universal end-of-input signal. Or why should I select an account at the ATM if I only have one account? Again, I’m sure this made life easier for some programmer.
Some programmers are lazy. But some are unsung heroes. They understand gritty details of their company that no one else knows about. They have to: they have to specify these details to dumb machines. Most people don’t want to solve problems down to the final detail and programmers — for better and for worse — are the ones who fill in the gaps.
Some of the details that programmers fill in regard what to do when things go wrong. A client says a program is supposed to collect the user’s Social Security number (SSN). Fine. But what if the user doesn’t have an SSN? What if they enter an invalid SSN? (Is there a way to know whether an SSN is valid?) After a few questions like that, the client will throw up his hands and leave it up to the developer. But the developer cannot throw up his hands. He has to decide something, even if he passively decides to let the software crash in case of unexpected input.
Update: Changed “analyst” to “client” above. See discussion below. “Client” more accurately reflects what I meant.