From: Scott Sauyet on
Andrew Poulos wrote:
> On 10/05/2010 1:17 PM, Scott Sauyet wrote:
>> Andrew Poulos wrote:
>>> On 10/05/2010 12:15 PM, Scott Sauyet wrote:
>>>> David Mark wrote:
>>>>> Garrett Smith wrote:
>>>>>> David Mark wrote:
>>>>>>> Why?  Everyone already knows [Google's] developers are incompetent
>>>>>> Many, if not most non-developers tend to disagree.
>>>>> And on what basis could a non-developer judge the competence of a
>>>>> developer.
>>>> On what basis can a non-designer judge the competence of a designer?
>>> That it seems many people slavishly follow whatever the current trend
>>> might be is indicative of a lack of understanding of design and hence to
>>> know good design when they encounter it.
>> Are you a professional designer, then?  Or on what basis are you
>> making that claim?
> It seems that you're claiming that I need to competent in an area to
> make a judgement.

It seems that you've forgotten which side of the argument you're
trying to defend.

:-)

--
Scott
From: Scott Sauyet on
David Mark wrote:
> Scott Sauyet wrote:
>> David Mark wrote:

>>> So who would you ask?

>> In the end, the people paying the bills.  And I'm afraid that the Joe
>> Browsers of the world are much more strongly represented among those
>> people than are the Richard Cornfords.

> You would ask the man on the street to judge the relative competence of
> Web developers?  It doesn't make sense.

No, I would ask the users of their products. It's their views that
are probably the most relevant. As I said, I personally might
disagree with them on technical grounds, but if you think technical
arguments win most decisions in software development, you're living in
a very different world than I.

--
Scott
From: David Mark on
Scott Sauyet wrote:
> David Mark wrote:
>> Scott Sauyet wrote:
>>> David Mark wrote:
>
>>>> So who would you ask?
>
>>> In the end, the people paying the bills. And I'm afraid that the Joe
>>> Browsers of the world are much more strongly represented among those
>>> people than are the Richard Cornfords.
>
>> You would ask the man on the street to judge the relative competence of
>> Web developers? It doesn't make sense.
>
> No, I would ask the users of their products. It's their views that
> are probably the most relevant.

No. You switched arguments. We are talking about judging the
_competence_ of developers, which is not done in user focus groups.

> As I said, I personally might
> disagree with them on technical grounds, but if you think technical
> arguments win most decisions in software development, you're living in
> a very different world than I.
>

Not the "real world" argument. :( Yes, software development is a
technical business. You may be confusing UI design with development.
The line may be blurry in some cases, but it is still there.
From: Scott Sauyet on
David Mark wrote:
> Scott Sauyet wrote:
>> David Mark wrote:
>>> Scott Sauyet wrote:
>>>> David Mark wrote:
>
>>>>> So who would you ask?
>>>> In the end, the people paying the bills.  And I'm afraid that the Joe
>>>> Browsers of the world are much more strongly represented among those
>>>> people than are the Richard Cornfords.
>>> You would ask the man on the street to judge the relative competence of
>>> Web developers?  It doesn't make sense.
>> No, I would ask the users of their products.  It's their views that
>> are probably the most relevant.
> No.  You switched arguments.  We are talking about judging the
> _competence_ of developers, which is not done in user focus groups.

I've occasionally -- not too often, I'm glad to say -- been in the
position of managing other developers. What I realized eventually is
that technical expertise is, sadly, only a small part of what makes
for a successful member of a development team. For one-person shows,
technical prowess is essential, and even for large teams I won't hire
people without clearly demonstrated technical skills. But for these
larger projects, a hugely important skill is thinking like a user of
the product under development. That skill is in many ways more
important than the technical ability. I would rather clean up after
someone who's left a technical mess but pleases the users than try to
upgrade a wonderfully designed and beautifully implemented system that
fails to meet the users' expectations.

I'm in that boat right now. I'm finding code like this:

function splitString(aString, spliter) {
var temp = new Array();
temp = aString.split(spliter);
return temp;
}

// ...

domainID = splitString(ids, '|')[1];
serverID = splitString(ids, '|')[2];
portID = splitString(ids, '|')[3];
formatID = splitString(ids, '|')[4];

This is clearly nonsense, and was written by someone who missed a lot
of the fundamentals of Javascript. But the users are very happy with
the results. It does what they need. They don't notice the
performance issues, and don't care about the architectural or
implementation decisions.

--
Scott
From: Garrett Smith on
Scott Sauyet wrote:
> David Mark wrote:
>> Scott Sauyet wrote:
>>> David Mark wrote:
>>>> Scott Sauyet wrote:
>>>>> David Mark wrote:
>>>>>> So who would you ask?
>>>>> In the end, the people paying the bills. And I'm afraid that the Joe
>>>>> Browsers of the world are much more strongly represented among those
>>>>> people than are the Richard Cornfords.
>>>> You would ask the man on the street to judge the relative competence of
>>>> Web developers? It doesn't make sense.
>>> No, I would ask the users of their products. It's their views that
>>> are probably the most relevant.
>> No. You switched arguments. We are talking about judging the
>> _competence_ of developers, which is not done in user focus groups.
>
[...]

> This is clearly nonsense, and was written by someone who missed a lot
> of the fundamentals of Javascript. But the users are very happy with
> the results. It does what they need. They don't notice the
> performance issues, and don't care about the architectural or
> implementation decisions.
>

That problem is very basic in nature and supported natively by
ECMAScript, as revealed in line two of the body of the function.

That basic problem is addressed by five lines of code, four of which are
clutter. That's 80% of clutter. Its easy to see what is going on, as you
point out.

The water wings are working. He's over his head but he's not going to be
succumbed by a riptide.

Consider a Scheduler for a CMS now. Not a basic problem at all. This is
a larger problem that will require a much broader and much deeper
understanding of several technologies -- not just javascript strings and
arrays -- but will involve the DOM, Events, HTML, CSS, and server
communication. A good solution will also need more sophisticated
abstractions and code organization strategies.

Good abstractions deal with the problems at a level that they can be
understood. Good javascript abstractions also address the additional
constraint of dynamic deployment environment. By that, I mean browsers,
configurations, screen sizes, cache sizes, CPU, forwards and backwards
compatibility.

Had that developer been assigned to a complicated task like that, the
result would be at best, nipped in the bud at early stage, second to
that, a complete and total waste that got trashed, and at worst,
something that the manager tries to have everybody maintain when it
really needs rewriting. Unfortunately, that worst possible outcome is
the most common.

It could get nipped or transferred if the manager realizes that the
progress is not being made soon enough. If he has been working on the
problem for a month or so, stopping him at that point will be more
painful. The effort spent may be perceived as being greater than the
amount of effort required to get it done and so the manager says that:
"get it done!"

The five lines above, while senseless, would be nothing compared to a
wretched mess of unmaintainable two thousand lines. Shipped late, with
bugs.

It's all about the water.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/