Ideal Software-Engineers? Was: RE: Mind the Gap!

3 Feb 2004 - 10:44am
10 years ago
4 replies
371 reads
Andrei Sedelnikov
2004

>> "Software engineers live in their own world. With few exceptions,
>> they only focus on computers and themselves. A problem is seen
>> as solved as soon as the algorithm is correct and the compiler
> >does not come back with any syntax errors."
>
> That might be how it's done in undergraduate programming classes. But
> in the real-world software teams I've been on, this isn't true at all.
> Engineers balance many different factors as they work: correctness,
> understandability of code, making code adaptable to later changes
> (often by other people), speed of development, likelihood of
> introducing new bugs, runtime resource usage, decoupling of subsystems,
> testability, conformance to specs and coding standards, etc. In other
> words, a LOT of what engineers think about are, in fact, human factors
> issues! (For other engineers, not for users; but that's the nature of
> the role.) Good code craftsmanship means writing for humans, not just
> writing for the computer.

I have to strongly disagree: It has nothing to do with human factors.
Even if it would, the person who does everything you have described above
well can be called "an ideal software-engineer". I admit there can be few
people with such charachteristics but it is rather an exception.

> Does the stereotype suggest that all software engineers are arrogant
> and myopic?

No. Of course not. Not _all_ engineers. But _the most of them_.
Do you see the difference?

regards,
Andrei Sedelnikov
http://usabilist.de

Disclaimer: I'm working in a large organization with thousends of so called
"software-engineers",
and I observe the evidences of what the Cooper says everyday.

Comments

3 Feb 2004 - 11:46am
Jenifer Tidwell
2003

On Tue, 3 Feb 2004, Andrei Sedelnikov wrote:

> > Engineers balance many different factors as they work: correctness,
> > understandability of code, making code adaptable to later changes
> > (often by other people), speed of development, likelihood of
> > introducing new bugs, runtime resource usage, decoupling of subsystems,
> > testability, conformance to specs and coding standards, etc. In other
> > words, a LOT of what engineers think about are, in fact, human factors
> > issues! (For other engineers, not for users; but that's the nature of
> > the role.) Good code craftsmanship means writing for humans, not just
> > writing for the computer.
>
> I have to strongly disagree: It has nothing to do with human factors.

Really? Designing something so that it can be read, understood,
and improved by others has "nothing to do with human factors"?

> Even if it would, the person who does everything you have described above
> well can be called "an ideal software-engineer". I admit there can be few
> people with such charachteristics but it is rather an exception.
> ...
> Disclaimer: I'm working in a large organization with thousends of so
> called "software-engineers", and I observe the evidences of what the
> Cooper says everyday.

Our experiences are very different, then. In twelve years of
working in software organizations, I've seen almost all engineers
be concerned about the issues I listed above -- and most strive to
be better at them. Yes, I described an ideal. But many come very
close to that ideal.

(If that's not so in your organization, then I pity its customers,
because these things must be taken into account if one wants to
build good software.)

> > Does the stereotype suggest that all software engineers are arrogant
> > and myopic?
>
> No. Of course not. Not _all_ engineers. But _the most of them_.
> Do you see the difference?

Certainly. And it's still insulting to software engineers.

I beg of you all -- please consider the negative effects of
stereotyping. Will it really help you establish an effective
design and utesting presence in your organization (assuming
that's what you're striving for)? Or would you be better off
working cooperatively and empathetically with the engineers
who will build your designs?

- Jenifer

--------------------------------------------
Jenifer Tidwell
w: jtidwell at mathworks.com
h: jtidwell at alum.mit.edu
http://jtidwell.net/

3 Feb 2004 - 12:12pm
Andrei Sedelnikov
2004

> > I have to strongly disagree: It has nothing to do with human factors.
>
> Really? Designing something so that it can be read, understood,
> and improved by others has "nothing to do with human factors"?

I meant how does it concern the usability of the end-user product?

>From my observations, the software-engineers will be trying to provide
something readable and understandable for their collegues only if they
will be forced by the management to do so. Left alone, each
software-developer
will only try to please himself. :(

> Our experiences are very different, then. In twelve years of
> working in software organizations, I've seen almost all engineers
> be concerned about the issues I listed above -- and most strive to
> be better at them. Yes, I described an ideal. But many come very
> close to that ideal.

> (If that's not so in your organization, then I pity its customers,
> because these things must be taken into account if one wants to
> build good software.)

That's a corner stone! How do the customers can determine
the quality of the software product execept counting the number of features?
They [usually] don#t have a single cue how to do it!
That's why the management personal of the software company
do not care about such things.

> And it's still insulting to software engineers.

[Ironically] Ah! Poor children!

> I beg of you all -- please consider the negative effects of stereotyping.

For several years the "steering wheel" was in the hands of
software-developers
because noone could understand what they are doing. But the times are
changing. That "stereotyping" is just a way to show other people and
to explain what really happens.

> Will it really help you establish an effective
> design and utesting presence in your organization
> Or would you be better off
> working cooperatively and empathetically with the engineers
> who will build your designs?

Personally I always try to keep good relations to software
engineers. And the knowledge of their nature only helps and
does not disturb.

regards,
Andrei Sedelnikov
http://usabilist.de

3 Feb 2004 - 12:47pm
Elizabeth Buie
2004

I don't think Jenifer is saying that *all* software engineers "get it" in
terms of usability for end users, but that (1) we shouldn't paint them all
with the same brush and (2) most of them do care, even the ones who aren't
very knowledgeable about end-user usability.

I agree with Jenifer on these items.

In my 22 years in HCI, I have found that, by and large, the developers who
are the most receptive to usability (and knowledgeable about it) tend also
to be the ones who are the most skilled at their craft. This isn't a
perfect correlation (I've known some good programmers who couldn't care
less about usability), but a general theme.

Elizabeth

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

3 Feb 2004 - 2:13pm
Andrei Herasimchuk
2004

On Feb 3, 2004, at 9:47 AM, Elizabeth Buie wrote:

> In my 22 years in HCI, I have found that, by and large, the developers
> who
> are the most receptive to usability (and knowledgeable about it) tend
> also
> to be the ones who are the most skilled at their craft. This isn't a
> perfect correlation (I've known some good programmers who couldn't care
> less about usability), but a general theme.

I'm in complete agreement, and I've had the luck and opportunity to
work with some the smartest engineering talent on this planet, at least
in the top 10% of the talent worldwide. In every working relationship
I've had with engineers, the best ones in this top 10% were always
acutely aware of every aspect of a product, and did everything they
knew to make the best product they could. That always included trying
to understand the user and how the user works with their products as
much as possible, and coding it to the user's needs. The rest often
listened a lot and did great work, collaborating and contributing like
we all do to make successful products.

Matthias, let me just say you make some rash generalizations in the
blurb you pointed us to. To be part of the solution usually requires in
large part to also not be part of the problem while finding a solution.
Making rash generalizations is usually being part of the problem in my
experience, and these sorts of stereotypes do nothing but foster a
culture of disconnectedness and confrontation when applied in a working
environment. I'm not sure if you are summarizing the book, just believe
what it is saying, or making an interpretation, but I find many
problems with the point of view expressed on that page. A dubious start
out of the gate to say the very least.

I also completely agree with what Robert said. As usual, Robert is far
more eloquent and precise than I am so I'll not attempt to add anything
to his contribution.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

Syndicate content Get the feed