ABSTRACT
Programmers think in very concrete ways. Many times, some-thing that looks like it’s broken to you will actually be functioning as intended by the programmer. They are usually ready to admit and accept that something is broken. They will be eager to get in and fix any bugs. (If they have time at that point. Schedules can be tight, but programmers are usually very conscientious about providing bug-free code.)
It can be more difficult to convey to programmers that something they made technically bug free is still “not working” for the overall project. If they respond to feedback by saying that this feature is “functioning as intended” that means they think the problem is with the specifications for what they were asked to build (or with frequently changing specifications), rather than the problem being with the actual thing they built. This may feel like pointless blameshifting, but for programmers it’s personal. They spend just as much time trying to read other people’s minds as artists do, but instead of vague artistic descriptions like “happy and fun,” they will get incomplete specification lists and vague design documents.
