Datasheet

13
Chapter 1: Defi ning the Language Environment
The human resources for your project are further affected by biases, preference for particular tools,
and the desire to make their mark on the project. The following sections provide an overview of the
resources you need to consider as part of the language environment. The remainder of the book pro-
vides additional details on this topic as appropriate.
Inventorying Team Language Resources
Anyone with a four-year computer science degree will have experience in more than one language. The
experience may not be enough to write an application, but the fact that users have experienced the lan-
guage means that they have learned something about it. The experience reduces the learning curve for
the language and makes it possible that the team member could potentially use that language as part
of your project. The only problem with colleges and universities is that they seem to have differing lan-
guage plans — one school may emphasize Java while another emphasizes Visual Basic.NET. You can’t
determine that someone has a certain set of skills based solely on the person’s degree.
Self-taught individuals also have a wealth of experience with languages. Someone who starts with Visual
Basic for Applications (VBA) as part of working with Offi ce may move on to Visual Basic, and from there
on to Transact Structured Query Language (T-SQL). After spending a lot of time on the Web, this team
member may have also learned JavaScript and other languages in order to set up a personal Web site.
Unfortunately, you won’t discover any of these skills until you conduct an inventory. Just because a team
member is currently working with C# doesn’t mean this person lacks other programming language skills.
In order to create the best design for your application, you must also know that a particular team mem-
ber worked extensively with C++ at one time and specialized in creating DLLs for another organization.
Considering Team Skills
It’s nice that you know a particular team member knows C#, C++, and Visual Basic with a smattering of
T-SQL thrown in for good measure. However, most languages are extremely complex, so it’s possible for
someone to become profi cient in one aspect of a language, such as database design, and not in others.
Consequently, knowing that the team member wrote code that accessed SQL Server databases is better
than simply knowing that this member knows how to write in C#. Every application development expe-
rience that team members have improves their skill. However, skills always focus on a particular need,
so you also need to know about the need that the application answered.
Skills are also transient. A team member’s skill fades as time passes without exercising that skill. In
addition to determining that the team member has written code to access SQL Server, you also need
to know how much time has passed since the team member engaged in that activity. A team member
who wrote SQL Server code eight years ago will offer far less profi ciency than someone who performed
the same task two weeks ago. It’s important to remember, though, that people can polish their skills
quickly. Even eight-year-old experience is better than no experience at all.
The fi nal skill consideration is learning environment. A VBA programming skill developed using
Offi ce 95 is less useful for today’s application needs than a skill developed using Offi ce 2007. The same
concern holds true for any skill. The skill is usually matched to a particular product version, which
means you must consider what has changed since the team member developed the skill. For example,
in the case of Offi ce 2007, the Microsoft Offi ce Fluent User Interface (RibbonX) signifi cantly reduces the
usefulness of a skill developed using Offi ce 95 because many of the older techniques no longer work.
15962c01.indd 1315962c01.indd 13 1/23/09 5:45:00 AM1/23/09 5:45:00 AM