does a software architect need UML skills?

  • Thread starter Thread starter not_a_commie
  • Start date Start date
N

not_a_commie

If you were going to hire a software architect / functional lead for
your project (written exclusively in C# including WPF, WCF) would you
require that they have UML skills?

Is being able to draw the standard UML diagrams in a notebook
sufficient, or would you require that they have some experience with
some UML program or another? Which program?
 
I certainly would not require it. Having direct UML skills implies that you
understand process models and object oriented methodology etc, but one can
have expert knowledge in these and not have UML skills.

Experience and a proven track record in the things you deem important for
your project are crucial, not UML skills.
 
not_a_commie said:
If you were going to hire a software architect / functional lead for
your project (written exclusively in C# including WPF, WCF) would you
require that they have UML skills?
Click to expand...

Unless the job has some specific requirement to work with UML as the
basic architectural paradigm (for example, the team already depends
heavily on UML), I would not consider it at all. Even with such a
requirement, I would keep in mind that it's much more important to hire
a smart, adaptable person who can learn UML or other techniques as
needed than to focus on specific skill sets.

Obviously there has to be some fundamental basic skills, but those
aren't going to involve specific design techniques, or even specific
languages for that matter. I would much rather hire a smart guy who has
never seen C#, Java or C++ than to hire a dumb guy who claims to know
all three.

Of course, I may be a little biased, given that I think I have a clue
when it comes to software architecture, but had to Google UML to find
out what the heck you're talking about. :)

Pete
 
If a candidate is smart enough to consider hiring, he/she is certainly
smart enough to pick up UML quickly.
 
If you were going to hire a software architect / functional lead for
your project (written exclusively in C# including WPF, WCF) would you
require that they have UML skills?
Click to expand...

yes, and he should also be skilled in XML, BS and WTF...
 
not_a_commie said:
If you were going to hire a software architect / functional lead for
your project (written exclusively in C# including WPF, WCF) would you
require that they have UML skills?
Click to expand...

Yes. Unless standards don't mean anything in your organization.

UML is the standard for diagrams in the industry.

He/she may not like UML. He/she may not want to use UML for
this project. But he/she should know UML.

You would not hire a C# programmer that had never heard
about for loops no matter how smart he/she appeared to be.
Is being able to draw the standard UML diagrams in a notebook
sufficient, or would you require that they have some experience with
some UML program or another? Which program?
Click to expand...

Tools does not matter much.

There are plenty of them. And if he knows 3 tools, then your
are probably using tool #4.

Arne
 
Yes. Unless standards don't mean anything in your organization.

UML is the standard for diagrams in the industry.
Click to expand...

That doesn't mean it's the only - or even the most effective - way to
communicate.

Personally, I've never been a fan of UML. I use it where it's
absolutely required, but I wouldn't claim to know it well at all. The
important thing is that whether I'm using UML or not, with a diagram
and some explanatory words I can make myself understood.

I'd rather be able to whip up a quick picture on a whiteboard which
just has blocks showing what's going on, without worrying about
getting all the UML symbols etc correct, and talk someone through the
picture (or use written text if necessary) than spend hours on a UML
diagram.

Just MHO. And yes, I've been to job interviews where people have been
surprised and disappointed in a lack of UML. That doesn't mean they're
right though ;)

Jon
 
Jon said:
That doesn't mean it's the only - or even the most effective - way to
communicate.

Personally, I've never been a fan of UML.
Click to expand...

What you did not quote was:

#He/she may not like UML. He/she may not want to use UML for
#this project. But he/she should know UML.

UML is the standard.

There may be reasons not to use the standard.

But now knowing the standard is a very poor reason.

Arne
 
Arne Vajhøj said:
What you did not quote was:

#He/she may not like UML. He/she may not want to use UML for
#this project. But he/she should know UML.

UML is the standard.
Click to expand...

As Radek says, according to who? It's widely used, but that's not quite
the same thing.
There may be reasons not to use the standard.

But now knowing the standard is a very poor reason.
Click to expand...

If your organization happens to use UML extensively, that *might* be a
reason - although it's simple enough to learn UML when necessary.

If your organization doesn't use UML, or doesn't use it very much, why
should it be a job requirement?
 
As Radek says, according to who? It's widely used, but that's not quite
the same thing.



If your organization happens to use UML extensively, that *might* be a
reason - although it's simple enough to learn UML when necessary.

If your organization doesn't use UML, or doesn't use it very much, why
should it be a job requirement?
Click to expand...

I guess if part of your responsiblity was to move the company forward
in regards to documentation then UML might be skill worth having.
Then again, I'm with you. While there are some useful UML diagrams
I'm still not a heavy user either.
 
I would go out on a limb here and say, "Hell Yes!".

There's no way you could read a current software design book without coming
across many UML diagrams. You need to be able to read these diagrams easily.
Any suh book that doesn't have these diagrams is probably a pretty lousy
book.

If you want to document your designs, you need to be able to include
diagrams that show deployment models, packages, sequences, flows, and entity
relationships. I suppose you could come up with your own unique way of doing
this, but it would be pretty stupid. Even then, the people who read your
paper would then need to learn your custom language.

Every profession has it's own set of languages for communication between
people. The standard, shared, termonology is key - and being able to
communicate that on paper is very important. If you're an architect or a
builder, you better be able to read a blueprint. If you're an EE you better
know how to read circuit diagrams. The software profession is no different.

As for a tool - who cares. Often a Whiteboard is sufficient for
brainstorming sessions. When writing design documents, I tend to use Visio
only because it's already installed on my machine and i know it pretty well.
If I were reading a document, I don't care if the diagrams were authored in
Rational, Visio, Alova, Magic Draw, or any of the other dozens of suitable
tools.
 
That doesn't mean it's the only - or even the most effective - way to
communicate.
Click to expand...

Certainly true. But for the same reason I'm unlikey to write this message
out in Hmong, I'm unlikey to go with a Software Diagraming language nobody
has ever heard of.

The reason we write is (often) to be understood by as wide a range of people
as possible. If we each created a new diagraming language for each problem
we came across, the results would be a complete lack of ability to
communicate with each other.

Every professional field has a set of language tools they use to communicate
with each other. In some professions, these languages and tools have evolved
over a very long people of time and are very mature. Civil Engineers, for
example, can reasonably expect to read a set of plans put together by just
about any other Civil Engineer the world over. Electrical Engineers and
Architects as well can expect this.

In Software Engineering this is now possible through UML. This langauge
allows engineers well versed in Java, C++, .Net, Basic, and other langauges
to communicate with each other.
 
In Software Engineering this is now possible through UML. This langauge
allows engineers well versed in Java, C++, .Net, Basic, and other langauges
to communicate with each other.
Click to expand...

I find that UML on its own is rarely good enough to communicate
effectively - whereas a diagram and suitable explanation is good enough
*whether or not the diagram is in proper "formal" UML*.

Usually the system architecture shouldn't be on the level of "this
class and this interface" - just drawing deployment boxes is good
enough. When I *do* want to look at the class level design, I can
understand non-UML boxes with description perfectly easily - or looking
at the source itself.
 
Jon said:
As Radek says, according to who? It's widely used, but that's not quite
the same thing.
Click to expand...

It is called a defacto standard.
If your organization happens to use UML extensively, that *might* be a
reason - although it's simple enough to learn UML when necessary.

If your organization doesn't use UML, or doesn't use it very much, why
should it be a job requirement?
Click to expand...

Because an architect that does not know UML is complete out of
touch what is going on in the industry.

And that is a pretty bad characteristic for an architect.

Arne
 
Jon said:
I find that UML on its own is rarely good enough to communicate
effectively - whereas a diagram and suitable explanation is good enough
*whether or not the diagram is in proper "formal" UML*.

Usually the system architecture shouldn't be on the level of "this
class and this interface" - just drawing deployment boxes is good
enough. When I *do* want to look at the class level design, I can
understand non-UML boxes with description perfectly easily - or looking
at the source itself.
Click to expand...

Hmm.

Are you talking about UML in general or specifically about UML
class diagrams ?

UML has a deployment diagram !

Arne

PS: The usefulness of class diagrams if often higher if they only
show what is important not everything.
 
Arne Vajhøj said:
Hmm.

Are you talking about UML in general or specifically about UML
class diagrams ?

UML has a deployment diagram !
Click to expand...

But what advantage does UML have in deployment terms over ad hoc
diagrams? Yes, I'll use the appropriate symbol for a database etc - but
very few of my diagrams are strictly UML conformant, and I don't think
it hurts communication at all.
PS: The usefulness of class diagrams if often higher if they only
show what is important not everything.
Click to expand...

And again, that's just as easy to do (IMO) in an ad hoc manner as with
fully UML-compliant diagrams.
 
Arne Vajhøj said:
It is called a defacto standard.
Click to expand...

I wouldn't say it's *sufficiently* commonly used to count as a de facto
standard. In particular, I think it's *talked about* more than it's
actually used.

In my experience, a lot of companies will say they use UML for all
their documentation - but don't really do so, and to little harm.
Because an architect that does not know UML is complete out of
touch what is going on in the industry.

And that is a pretty bad characteristic for an architect.
Click to expand...

I wouldn't claim to "know" UML. I know enough to understand other
people's diagrams, and I'm perfectly capable of communicating with
other people through ad hoc diagrams with enough UML-ness where
necessary.

Am I completely out of touch with the industry? Would you throw my CV
out because it doesn't list UML as one of my core skills?

Personally, I think it's most important that architects are able to
come up with appropriate solutions and communicate them effectively to
their teams and managers. The nature of that communications is
relatively unimportant, IMO.
 
Back
Top