Comments on: The buck stops with the programmer http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/ The blog of John D. Cook Sat, 11 Feb 2012 22:42:11 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: Bob http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-79682 Bob Thu, 05 May 2011 18:48:18 +0000 http://www.johndcook.com/blog/?p=1815#comment-79682 You press "#" after the zip code so that you have an opportunity to cancel if you made an error on the fifth digit. You press “#” after the zip code so that you have an opportunity to cancel if you made an error on the fifth digit.

]]> By: Jonathan Mugan http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-79646 Jonathan Mugan Thu, 05 May 2011 14:11:06 +0000 http://www.johndcook.com/blog/?p=1815#comment-79646 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. 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.

]]> By: Eric T http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-79631 Eric T Thu, 05 May 2011 12:52:55 +0000 http://www.johndcook.com/blog/?p=1815#comment-79631 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. 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.

]]> By: The bipolar Internet — The Endeavour http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-57613 The bipolar Internet — The Endeavour Tue, 28 Dec 2010 16:55:39 +0000 http://www.johndcook.com/blog/?p=1815#comment-57613 [...] The buck stops with the programmer Underwhelmed with progress ? X [...] [...] The buck stops with the programmer Underwhelmed with progress ? X [...]

]]> By: ekzept http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-16385 ekzept Thu, 23 Apr 2009 22:27:01 +0000 http://www.johndcook.com/blog/?p=1815#comment-16385 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. 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.

]]> By: Ole Laursen http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-14993 Ole Laursen Thu, 26 Mar 2009 17:00:24 +0000 http://www.johndcook.com/blog/?p=1815#comment-14993 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. 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.

]]> By: John http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-14838 John Mon, 23 Mar 2009 19:39:01 +0000 http://www.johndcook.com/blog/?p=1815#comment-14838 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. 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.

]]> By: Corwin http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-14836 Corwin Mon, 23 Mar 2009 18:53:21 +0000 http://www.johndcook.com/blog/?p=1815#comment-14836 A number of points: 1. In terms of user interfaces, most programmers are not well trained on writing UIs. There is a lot of work involved in writing good interfaces where the computer only asks what it absolutely cannot figure out for itself and every possible "bad" kind of input is accounted for. This kind of work is hard to do, blurs into QA, and takes a lot of time. Also, much of it is invisible - the # sign you don't ask for, skipping the prompt to ask for which bank account, the system that doesn't crash when an impossible input is given. Like QA since the results are often not visible and outside of many programmers core expertise this kind of interface refinement is often skimped on or skipped. Also, companies have time or money deadlines so it is all too easy to ship rough UIs. 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. A number of points:
1. In terms of user interfaces, most programmers are not well trained on writing UIs. There is a lot of work involved in writing good interfaces where the computer only asks what it absolutely cannot figure out for itself and every possible “bad” kind of input is accounted for. This kind of work is hard to do, blurs into QA, and takes a lot of time. Also, much of it is invisible – the # sign you don’t ask for, skipping the prompt to ask for which bank account, the system that doesn’t crash when an impossible input is given. Like QA since the results are often not visible and outside of many programmers core expertise this kind of interface refinement is often skimped on or skipped. Also, companies have time or money deadlines so it is all too easy to ship rough UIs.

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.

]]> By: John http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-14719 John Fri, 20 Mar 2009 01:04:44 +0000 http://www.johndcook.com/blog/?p=1815#comment-14719 Steve, I did s/analyst/client/ above per our discussion. Thanks for the feedback. Steve, I did s/analyst/client/ above per our discussion. Thanks for the feedback.

]]> By: Steve Diamond http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-14716 Steve Diamond Fri, 20 Mar 2009 00:20:00 +0000 http://www.johndcook.com/blog/?p=1815#comment-14716 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. 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.

]]> By: John http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-14715 John Fri, 20 Mar 2009 00:03:48 +0000 http://www.johndcook.com/blog/?p=1815#comment-14715 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. 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.

]]> By: Steve Diamond http://www.johndcook.com/blog/2009/03/19/the-buck-stops-with-the-programmer/comment-page-1/#comment-14714 Steve Diamond Thu, 19 Mar 2009 23:53:29 +0000 http://www.johndcook.com/blog/?p=1815#comment-14714 "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 <a href="http://stevediamondconsulting.com/blog/how-business-automation-projects-fail-part-1.html" title="How Business Automation Projects Fail" rel="nofollow">How Business Automation Projects Fail</a>. “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.

]]>