Prev: Booch's book feels too philosophical rather than practical?
Next: hello to everyone
From: Dmitry A. Kazakov on 28 Jan 2007 04:59
On Sun, 28 Jan 2007 00:58:31 GMT, JXStern wrote:

> 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.

Yes, another essential feature of a guild is political influence, to
enforce its exclusivity by law.

For example, somebody outside the guild who tried to develop and sell
software should be thrown into the bay with led boots put on his feet...

(kind of DMCA (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: topmind on 28 Jan 2007 15:36

AndyW wrote:
> 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.

But if you get away from such specifics, then *objectivity* is hard to
come by. That was my original point several levels back. It is much
easier to test if specific languages are used. Concepts are more
difficult to test *without* specific notations and conventions. And
measuring "good design" is even more of a step in subjectivity land.
There are agreed-upon factors to consider, but the weight people give
to each of these factors is all over the map.


>
> 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.

Theory? They are not based on solid theory. CMM is highly criticized
by some as penalizing experimentation. Without experimentation, we
would be stuck in the 1970's

>
> Andy

-T-

From: John Carter on 28 Jan 2007 22:01
On Sun, 21 Jan 2007 07:59:59 -0600, Robert Martin wrote:

> On 2007-01-20 11:03:08 -0600, "Daniel T." <daniel_t(a)earthlink.net> said:
>
>>> Do we need some kind of professional organization, or guild to
>>> differentiate the professionals from the non-professionals?

> The examination should probably involve a written test of significant
> depth. Something akin to the "Bar" exam, or the board exam for doctors.
> It should also include review of code created during the internships.

I find the ACM's position quite sensible.

http://www.acm.org/serving/se_policy/selep_main.html

(For the attention limited, the answer is No.)

--


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter(a)tait.co.nz
New Zealand


From: AndyW on 28 Jan 2007 23:42
On 28 Jan 2007 12:36:02 -0800, "topmind" <topmind(a)technologist.com>
wrote:

>
>AndyW wrote:
>> 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.
>
>But if you get away from such specifics, then *objectivity* is hard to
>come by. That was my original point several levels back. It is much
>easier to test if specific languages are used. Concepts are more
>difficult to test *without* specific notations and conventions. And
>measuring "good design" is even more of a step in subjectivity land.
>There are agreed-upon factors to consider, but the weight people give
>to each of these factors is all over the map.
>
>
>>
>> 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.
>
>Theory? They are not based on solid theory. CMM is highly criticized
>by some as penalizing experimentation. Without experimentation, we
>would be stuck in the 1970's
>
>>
>> Andy
>
>-T-
no-one is trying to stifle inovation and experiementation at all.
People are just trying to put a stick in the ground to give us a ball
park to work in.

I would suggest lots of things are criticized by many people. I've
however, found that if one discounts the theorists and goes by proven
fact and expereince, a lot of that criticizing dissapears.

There are many organisations that do things successfully, one needs to
just look at how they do it and mirror the good bits. I've already
mentioned the PMI, another good organisation is the OMG, especially
in its earlier days. Things were only adopted that were based on
already commercial and working ideas and their process of voting on
things and issuing rfp's seems to work quite well.

From my understanding of large groups of people I would suggest
starting off with something generic and improving it over time is a
much better solution that trying to get all the detail working
perfectly first time out.

If there is to be a certification exam (based on experience and
knowledge) then I would also suggest that a refresher be required
every couple of years or so. That way, if the rules do change then its
picked up in the examination next time round.

But I would really suggest not going down the weel invention path and
simply adopt a successful solution and modify it.

Andy


From: topmind on 29 Jan 2007 00:55

AndyW wrote:
> On 28 Jan 2007 12:36:02 -0800, "topmind" <topmind(a)technologist.com>
> wrote:

>
> But I would really suggest not going down the weel invention path and
> simply adopt a successful solution and modify it.

I mean from the perspecttive of a specific shop and the domain, not
from cutting edge "packaged" technologies. To automate and add better
abstractions for a given domain or company takes experimentation.

>
> Andy

-T-

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