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.
12 thoughts on “The buck stops with the programmer”
“After a few questions like that, the analyst will throw up their hands and leave it up to the developer.”
Boy, I sure hope not! In the first place, any analyst worth his or her salt will already have specified, in exhaustive detail, what the system should do in the case of each conceivable exception. Second, an analyst who isn’t willing to go back and do this kind of work when a gap is exposed isn’t an analyst who ought to be working on any important application for any self-respecting company.
So while it’s true that the buck stops with the programmer, I would emphasize the abysmal failure of the analyst(s) who wrote the specification in these cases.
And before I get off my soapbox, let me add that more often than not the analysts are the unsung heroes of successful automation projects and the unsuspected culprits of unsuccessful ones.
Your readers may be interested in a closely related blog series I’ve recently started on How Business Automation Projects Fail.
Maybe I’m being unfair to business analysts. Take out “business analyst” and substitute “client” and this is a pattern I’ve seen over and over.
John, subsitute “client” and I agree absolutely. The trouble is that clients aren’t trained in analysis, and no one ever told them that they ought to be hiring a programmer PLUS an analyst. They believe that they can communicate directly with the developer, and 9 times out of 10 the communication is woefully incomplete. The developer isn’t trained in business-speak and the client isn’t trained in creating specifications.
That’s why I keep evangelizing for the analysts. My clients are savvy enough to know that they need someone like me in addition to a good developer. Sadly, many small and medium business owners and execs don’t know it.
Steve, I did s/analyst/client/ above per our discussion. Thanks for the feedback.
A number of points:
2. I’m not a big fan of exhaustive business process specification for a number of reasons:
a. It is very hard to think of everything in advance. Pieces get left out or code may have interactions with other parts of a system that are just not anticipated by the programmer. Also, the particular way a feature is coded may have a huge impact on how it interacts with the rest of the system For this reason I think a simple spec followed by design or code reviews is more effective.
b. The truth is that programmers ignore complex specs. If you put too much in there and don’t break it down and educate them on why it is needed, huge parts of the spec will get ignored. So you will get partly implemented specs or code that is out of sync with changing specs. Here the literate programming approach has it right. Make the code as clear as possible and have it reflect the spec so they don’t get out of sync.
Corwin, I agree with both your points.
1. I imagine most products with a good UI were developed by a rare programmer who does understand UIs. I doubt many had “user experience experts” who were not programmers but told the programmers what to do.
2. I’m not arguing for exhaustive specifications but rather increased respect for programmers. I don’t think enough people realize the business research and the decision making that goes into developing software.
True. I often wonder whether some of the bad interfaces I see everyday are a result of organisations that demotivate the responsibility of their developers (for instance by placing an analyst between them and the client :), or just lack of thought, i.e. everyone was so focused on something else that it just slipped.
Well, it doesn’t just happen in software — Think of the gaffes over the years which have been made by U.S. auto manufacturers, including one (Ford?) which had spark plugs scattered all over the engine block, including one on the underside, and the several problems of cabin design.
One of the major features of Japanese makers, including Toyota, was that it was clear from being IN the passenger cabin that someone actually THOUGHT about what it would be like to USE the thing.
My hunch in the U.S. automotive case was that portions of the vehicle were delegated to different teams who had different measures on them, including cost, and they relied upon some general interface specs to put the parts of vehicles together. And probably the usability and operability portion of the design was skipped because, well, the waterfall diagram said that if they did it, they wouldn’t finish on schedule.
Nice post. The last paragraph sum it up nicely.
I would suggest you replace the he with a less specific gender. Using the programmer or developer instead should make every gender happy.
I didn’t know the title of analyst existed anymore. That takes me back to my 7th grade introduction to computers class in the 1980’s. From what I’ve seen, these days there are just developers and managers. But maybe that’s part of the problem that Steve is pointing to, and maybe that’s why so many decisions have to be made by the programmer.
You press “#” after the zip code so that you have an opportunity to cancel if you made an error on the fifth digit.
This is also mostly invisible when done well. No one notices that the interface works properly and as expected when it functions smoothly, as it “is obviously what’s expected”, but it’s very hard to quantify the value these decisions add (in most companies). E.g: credit card entry boxes which are unusable on phones which have led to users abandoning the site, etc.