Prev: Booch's book feels too philosophical rather than practical?
Next: hello to everyone
From: Frans Bouma on 27 Jan 2007 04:32
Robert Martin wrote:

> On 2007-01-26 01:09:23 -0600, "topmind" <topmind(a)technologist.com>
> said:
>
> >
> >
> >On Jan 25, 7:02 pm, Don Roby <d...(a)acm.org> wrote:
> > > topmind wrote:
> > >
> > > > But software is not as clear-cut as say law or medical. The
> > > > human body is mostly "fixed". There will not be 10 new body
> > > > plans to choose from every few years (unless maybe arthropods
> > > > and echinoderms grow intelligent). Software suffers from the
> > > > "god problem".
> > >
> > > If you find legal and medical work to be so simple and clear-cut,
> > > perhaps you should change profession and make a bundle.
> >
> > Well, let's try it then. What would you put on the software
> > engineering exam?
>
> Exams are about knowledge. An exam for entry into a software guild
> would test knowledge that any good software engineer should have.
> Knowledge of languages, data structures, algorithms, databases,
> paradigms, methods, practices, etc.

And here you go wrong. Algorithms, ok, though not everyone knows
language X or language Y and still can be a great software engineer.
For example, not everyone practises TDD/Agile methodologies, and even
so, there are a great number of people who THINK they practise TDD or
agile methodologies however are not doing any of that.

Besides, knowledge != wisdom.

> The exam should also involve
> some significant problems to solve by writing software that solves
> them.
>
> Architects used to do this by asking candidates to create blueprints
> of buildings from a spec. Then a group of Juror architects would
> evaluate the blueprints and grade them.

And here you have a great point. :) I think this is the only real way
to judge if a candidate is good. Theoretic blabla about 'do you know
how quicksort works internally?' is perhaps great for coffeetable
conversations, but really not that important for a person to be in a
guild as nowadays people USE quicksort, not implement it and if they
have to, they open sedgewick's book and type in the few lines. Theory
exams might sound OK, but what if a person had his/her education 10,
15 maybe even 20 years ago? I graduated from uni 13 years ago in an era
where OO wasn't widely accepted for example, and the specialization one
took after graduation is of more importancy than the real education:
the education provides the raw tools, the framework, but what you are
able to do with it is learned afterwards, so I think theoretic exams
are bad in this case but a set of problems to solve and where the
solutions are examined by a jury is an excellent way to test a
candidate IMHO.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
From: JXStern on 27 Jan 2007 19:58
On 27 Jan 2007 09:32:47 GMT, "Frans Bouma"
<perseus.usenet.NOSPAM.(a)xs4all.nl> wrote:
>> > Well, let's try it then. What would you put on the software
>> > engineering exam?
>>
>> Exams are about knowledge. An exam for entry into a software guild
>> would test knowledge that any good software engineer should have.
>> Knowledge of languages, data structures, algorithms, databases,
>> paradigms, methods, practices, etc.

Maybe, but guilds are about basic competence, exclusivity, and
balancing the demands of the customers.

The elite may opt out of the guild more often than not with the
guild's happy agreement, as the star is as likely to make the others
look bad as to shine in his/her reflected light.


> And here you go wrong. Algorithms, ok, though not everyone knows
>language X or language Y and still can be a great software engineer.
>For example, not everyone practises TDD/Agile methodologies, and even
>so, there are a great number of people who THINK they practise TDD or
>agile methodologies however are not doing any of that.
>
> Besides, knowledge != wisdom.

If wisdom were a requirement, doctors would be truly rare, and don't
even think about applying that to lawyers!


>> Architects used to do this by asking candidates to create blueprints
>> of buildings from a spec. Then a group of Juror architects would
>> evaluate the blueprints and grade them.
>
> And here you have a great point. :) I think this is the only real way
>to judge if a candidate is good.

Yeah, but the classic guild involves an apprenticeship to a master who
teaches, and basically sponsors the newbie for full status. It's not
the AMA or ABA who licenses their members, nor vouches for them.

I'd love a guild, but I can't see ever establishing the exclusivity
bit, which pretty much kills the idea.

J.


From: topmind on 27 Jan 2007 23:49


On Jan 26, 7:13 pm, Robert Martin <uncle...(a)objectmentor.com> wrote:
> On 2007-01-26 01:09:23 -0600, "topmind" <topm...(a)technologist.com> said:
>
>
>
> > On Jan 25, 7:02 pm, Don Roby <d...(a)acm.org> wrote:
> >> topmind wrote:
>
> >>> But software is not as clear-cut as say law or medical. The human body
> >>> is mostly "fixed". There will not be 10 new body plans to choose from
> >>> every few years (unless maybe arthropods and echinoderms grow
> >>> intelligent). Software suffers from the "god problem".
>
> >> If you find legal and medical work to be so simple and clear-cut,
> >> perhaps you should change profession and make a bundle.
>
> > Well, let's try it then. What would *you* put on the software
> > engineering exam?Exams are about knowledge. An exam for entry into a software guild
> would test knowledge that any good software engineer should have.
> Knowledge of languages, data structures, algorithms, databases,
> paradigms, methods, practices, etc. The exam should also involve some
> significant problems to solve by writing software that solves them.
>
> Architects used to do this by asking candidates to create blueprints of
> buildings from a spec. Then a group of Juror architects would evaluate
> the blueprints and grade them.

But this would get into the issue of which language to use in the
test, where to find judges proficient in the chosen language(s), which
paradigms are used, which methodologies should be tested, etc.

In my opinion, you have to work with somebody for a few months to
really know if they are any good at real-world issues. Exams don't cut
it. At best, exams may weed out the worse, but beyond that are of
limited value.

>
> > --Robert C. Martin (Uncle Bob) | email: uncle...(a)objectmentor.com

-T-

From: AndyW on 28 Jan 2007 01:15
On Fri, 26 Jan 2007 21:13:04 -0600, Robert Martin
<unclebob(a)objectmentor.com> wrote:

>On 2007-01-26 01:09:23 -0600, "topmind" <topmind(a)technologist.com> said:
>
>>
>>
>> On Jan 25, 7:02 pm, Don Roby <d...(a)acm.org> wrote:
>>> topmind wrote:
>>>
>>>> But software is not as clear-cut as say law or medical. The human body
>>>> is mostly "fixed". There will not be 10 new body plans to choose from
>>>> every few years (unless maybe arthropods and echinoderms grow
>>>> intelligent). Software suffers from the "god problem".
>>>
>>> If you find legal and medical work to be so simple and clear-cut,
>>> perhaps you should change profession and make a bundle.
>>
>> Well, let's try it then. What would *you* put on the software
>> engineering exam?
>
>Exams are about knowledge. An exam for entry into a software guild
>would test knowledge that any good software engineer should have.
>Knowledge of languages, data structures, algorithms, databases,
>paradigms, methods, practices, etc. The exam should also involve some
>significant problems to solve by writing software that solves them.

I would suggest to you that it should be just about technical stuff.
I would perfer the three P's to be examined, these are People,
Process, and Product.

In my mind people skills are just as important on a software project
as technical skills. Process is the process of developing software,
the diffrerent techniques taught by each method out there. Product
(i'm modifying the meaning here) is the technical stuff.

Andy

From: AndyW on 28 Jan 2007 01:27
On 27 Jan 2007 20:49:58 -0800, "topmind" <topmind(a)technologist.com>
wrote:

>
>
>On Jan 26, 7:13 pm, Robert Martin <uncle...(a)objectmentor.com> wrote:
>> On 2007-01-26 01:09:23 -0600, "topmind" <topm...(a)technologist.com> said:
>>
>>
>>
>> > On Jan 25, 7:02 pm, Don Roby <d...(a)acm.org> wrote:
>> >> topmind wrote:
>>
>> >>> But software is not as clear-cut as say law or medical. The human body
>> >>> is mostly "fixed". There will not be 10 new body plans to choose from
>> >>> every few years (unless maybe arthropods and echinoderms grow
>> >>> intelligent). Software suffers from the "god problem".
>>
>> >> If you find legal and medical work to be so simple and clear-cut,
>> >> perhaps you should change profession and make a bundle.
>>
>> > Well, let's try it then. What would *you* put on the software
>> > engineering exam?Exams are about knowledge. An exam for entry into a software guild
>> would test knowledge that any good software engineer should have.
>> Knowledge of languages, data structures, algorithms, databases,
>> paradigms, methods, practices, etc. The exam should also involve some
>> significant problems to solve by writing software that solves them.
>>
>> Architects used to do this by asking candidates to create blueprints of
>> buildings from a spec. Then a group of Juror architects would evaluate
>> the blueprints and grade them.
>
>But this would get into the issue of which language to use in the
>test, where to find judges proficient in the chosen language(s), which
>paradigms are used, which methodologies should be tested, etc.

In my mind technical people have this problem where they sweat the
detail too much. I dont think a software development organisation
should examine things such as knowledge of programming languages as
believe it or not, at the end of the day its just keyboard bashing and
to me, makes up only about 10% of the effort invovled. Things like
knowledge of a programming language are at the end of the day, covered
in the job interview process. Also, if one is only allowed to join
said guild/organisation when one has a proveable amount of experience,
it could also be said that ability to cut code is going to be a given.
I would also suggest that examining a person on all the areas
surrounding cutting code, may to some degree ensure that they are
aware of the issues that lead to producing bad code.

I think focusing on the wrong things is why the software industry
needs uniting in a governing body to give it direction.

Also, I think that it isnt a good idea to focus on only one process
area. I think its important to be inclusive of all of the development
practices rather than focus on what is likely to be end up being a
vested interest. I would much rather examine somone on the theory
behind the CMM or PSP than on how well they know a programming
language.

Andy

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Booch's book feels too philosophical rather than practical?
Next: hello to everyone